What Are Requirements?
Updated: Sep 25, 2020
Requirements are one of the foundational elements of business analysis and are fundamental to any change initiative. A requirement is a usable representation of a need or want in a specific context. Through business analysis, requirements are elicited, analyzed and specified for the purposes of designing, building and implementing solutions that provide value to stakeholders. Requirements are typically expressed at higher levels of abstraction early on and are progressively elaborated on throughout their life cycle.
The Business Analysis Body of Knowledge (BABOK), a best practice document published by the International Institute of Business Analysis, describes requirements through its “Requirements Classification Schema”. The requirements classification schema is simply a taxonomy that classifies requirements into different categories. Business analysis practitioners ought to be familiar with the different categories when working to elicit, analyze and specify requirements to ensure that they have captured all requirements necessary to support a change. An easy way to understand the requirements classification schema, is to think of it as a hierarchy of requirements each at different levels of detail and abstraction. To illustrate this concept further, refer to the illustration below.
Let’s review each category in more detail.
What are Business Requirements?
Business requirements are high level goals or objectives that need to be satisfied through a change and typically represent the reason why a project or effort has been undertaken. Business requirements may consist of problems that need to be solved or opportunities that need to be realized to provide value. Business requirements sit at the top of the hierarchy as they are usually the starting point for a change and typically originate from a stakeholder with the authority to commit financial or human resources to an initiative. Business requirements may come from organizational, functional leadership or even external stakeholders including customers. To help illustrate the different types of requirements, consider the following example scenario:
The owner of a shoe store is experiencing problems that are increasing the difficulty of operating the store and that are ultimately impacting the stores profitability. One issue is that the shoe store owner is struggling with finding reliable sales staff to work at his store and sometimes must close early when his staff call in sick. The shoe store’s sales also suffer during the winter months as fewer people to tend visit the store. The shoe store owner, needs to identify and implement one or more solutions to remediate these issues and restore profitability.
In the example above, the business requirement is that the store owner is facing several issues that are challenging the operation of his store and impacting profitability. As a result, the owner needs to implement one or more solution to address these issues. In doing so, the owner would be afforded more flexibility to sell his products at anytime of day and would not be subject to interruptions due to poor weather or staff calling in sick. Once business requirements have been analyzed and are well understood, a practitioner will turn their attention to the next type of requirement; stakeholder requirements.
What are Stakeholder Requirements?
Stakeholder Requirements represent the needs of stakeholders implicated in a change that must be met in order to achieve the overarching business requirements. Stakeholder Requirements seek to expand on and add more detail to the business requirements such that the scope of potential solutions can start to be defined. In keeping with the example above, the shoe store owner has an inventory clerk and an accounting clerk who work for him. Consider the following stakeholder requirements which are documented as user stories:
As the owner of the shoe store, I would like to build a website so that I can sell my products online at any time of day with minimal disruption.
As an inventory clerk, I need to be notified every time an order is placed so that I can fulfill the order in a timely manner
As an inventory clerk, I need to be able to view order details to fulfill the order correctly
As an inventory clerk, I need to know when a product is out-of-stock so that I can reorder the product
As an accounting clerk, I need to be able to view monthly sales details so that I can prepare financial reports
Once stakeholder requirements have been specified to some degree, a practitioner can begin to focus on eliciting and specifying more detailed solution requirements that will start to describe how the business & stakeholder requirements can be satisfied through the solution to be delivered.
What are Solution Requirements?
Unlike business and stakeholder requirements which focus on the need, solution requirements start to describe the characteristics of the solution that will be delivered to satisfy the need. These characteristics form the basis of a design, which is a representation of a solution. Solution requirements represent a parent category of the two child categories, functional and non-functional requirements.
What are Functional Requirements?
Functional requirements describe the features, functions, and characteristics that a solution ought to have to satisfy stakeholder requirements. Functional requirements describe what a solution is intended to do, how it must behave, and what type of information it should record and manage. Functional requirements may describe how a solution should response to a certain type of user input for example. Considering the shoe store scenario above, let’s look at some examples:
The website must prompt customers to create a profile before they are able to place an order
The customer profile must include first name, last name, address, city, state or province and postal code
The website must send an order confirmation email to customers when an order is placed including the order number, product number, description, quantity, order sub-total and total
The website must record product inventory including product name, picture, number, description, quantity-on-hand, and price
The website must email order fulfillment when an order is place with the order and customer details
The website must have a login for order fulfillment to update the order status once it has been fulfilled
When an order is placed, it should be assigned pending status
The website must send reports on monthly sales totals by product to the accounting clerk
What are Non-Functional Requirements?
Non-functional requirements do not describe behavioral elements of a solution but rather represent quality characteristics that a solution must have. Sometimes referred to as quality of service requirements or constraints, non-functional requirements tend to describe the conditions under which a solution must remain effective. They form the basis for assessing and evaluating the operation and efficacy of a solution. The following is a list of some common categories of non-functional requirements:
Availability: The degree to which a solution is operational and accessible for use. This is a common requirement of software solutions, where availability is expressed as a percentage of time referred to as “uptime”.
Compatibility: The degree to which a solution can operate effectively with other elements in its environment. For example, whether a software solution is compatible with multiple operating systems.
Performance: Sometimes referred to as efficiency, performance requirements may impose constraints on the resources that a solution consumes in order to perform its designated functions.
Scalability: The degree to which a solution can grow to handle more work such as processing more transactions per second or handling more concurrent users.
Latency: Latency requirements refer to the amount of time that is deemed acceptable for a solution to perform its designated function. For example, a web page must not take longer than 0.5 seconds to load.
Considering the shoe store scenario from above, let’s look at some example non-functional requirements:
The order confirmation email must be sent within 5 minutes of an ordered being placed
The website must have 99.9% uptime (i.e. must not be down more than 43 minutes and 50 seconds in a year)
The user login process must not exceed 3 seconds to complete
What are Transition Requirements?
Transition requirements represent temporary elements in terms of features that a solution must have or conditions that it must meet for it to be fully implemented. Often described as the temporary requirements needed to move you from the current state where the solution does not exist, to the future state where it has been fully implemented. Common examples of transition requirements include temporary resources to support the implementation of a solution, training, short post go-live supports and data conversion. Consider the following examples of transition requirements in the context of the shoe store scenario:
Shoe store staff must be provided with 10-hour training on how to use the website to perform their functions
24/7 technical support must be provided for 6 months after the website launches
8 hours of on-site technical support will be required for launch day
Requirement Categories Are a Tool, Not A Requirement
A practical note for business analysts, the requirement classification schema (or requirement categories) was designed to help practitioners think about all of the different types of requirements that will need to be specified on a change initiative. It is not a mandatory way or means for practitioners to document, abstract or communicate requirements to stakeholders. I have witnessed never ending debates about whether a requirement is a functional or non-functional one. In the broader context of the change initiative, this really doesn’t matter. It is less important whether a requirement is categorized correctly and more important that no requirements be missed.