Thursday, August 8, 2013

Requirement Types Defined

Do you ever find yourself struggling to understand the difference between different requirement types, business vs. functional vs. user requirements?  You’re not alone - many analysts struggle with this as well.  In fact, the very term “requirement” is often used in various ways, even within the same organization.  In some instances the term “requirement” refers to high-level business (corporate) objectives, while in others it refers to any requirement or need from the business side.  The International Institute of Business Analysis (IIBA) defines a requirement as:

1)  A condition or capability needed by a stakeholder to solve a problem or achieve an objective.

2)  A condition or capability that must be met of possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.

3)  A document representation of a condition or capability as in 1) or 2).

There are actually four types of requirements business analysts should be aware of: business, stakeholder, solution, and transition requirements.  Solution requirements break down even further into functional and non-functional requirements.  Let’s explore how each requirement is different.

A business requirement is any requirement that originates from the business side.  The IIBA’s BABOK v2.0 (Business Analysis Body of Knowledge, 2009) defines a business requirement as “A higher level business rationale that, when addressed, will permit the organization to increase revenue, avoid or decrease costs, improve service, or meet regulatory requirements.”  In short, business requirements describe why an organization is undertaking a project, what the expected benefits to the organization or its customers will be as a result of undertaking the project.  Business requirements can be documented in a number of ways such as in a project charter, in a business case, or in a project vision and scope statement. Business requirements serve an important purpose in that they help get the project owner, stakeholders and project team(s) on the same page.  But you can’t build the next killer software application from such high-level information - you need to dive a little deeper to get to more meaningful, or detailed, requirements.   In general, a business requirement describes what is required, or what the business wants to do.  An example of a business requirement would be for an organization to have the capability to conduct online transactions with the condition that the solution complies with a set of regulations.

Stakeholder Requirements, also known as User Requirements, describe the needs of a particular set of stakeholders in regard to a proposed solution.  They may be used to describe how a particular set of users of a solution will interact with it or how a product will meet the needs of different customer groups.  Stakeholder or user requirements describe what users will actually do with the system, such as the activities that they must be able to perform. This is an important but difficult step because users often are unable to communicate the entirety of their needs and wants, and the information they provide may be incomplete, inaccurate and self-conflicting.  This is why user requirements are generally considered separate from the solution or system requirements (next).  User requirements are generally documented using narrative text, use cases, scenarios, user stories, or event-response tables.  The responsibility of completely understanding what the customer wants to do falls on the shoulders of the business analyst.  He/she must carefully analyze the business and user requirements and construct high quality system requirements ensuring that that the requirements meet certain quality characteristics.

Solution (System) Requirements are what the developers use to build the system. These are the traditional "shall" statements that describe what the system "shall do” – they describe how the work the business wants to do will get done. System requirements are classified as either functional or nonfunctional requirements.  A functional requirement specifies something that the developer needs to build to deliver the solution.  For example, a system may be required to enter and print cost estimates; this is a functional requirement.

Nonfunctional requirements stipulate all the remaining requirements not covered by functional requirements. Nonfunctional requirements are sometimes called supplemental requirements, quality of service requirements, or service level requirements. There are many types of nonfunctional requirements. Some common nonfunctional requirement types are:

  • Availability
  • Business continuity
  • Compliance
  • Interoperability
  • Maintainability
  • Performance
  • Usability

The system design document will detail the plan for implementing functional requirements.  The system architecture document will detail the plan for implementing supplemental or nonfunctional requirements.