Requirements define the needs of the project to provide best of its utility and benefits. If they aren’t clear or analysis is not done properly, it might lead to failure of the project no matter how good the concept and design is.
Just as a system is composed of various functionalities, requirements too are identified in various forms. This categorization of requirements makes analysis process much simpler and clear for all the involved stakeholders. As per BABOK, the requirements are primarily categorized as:
- Business Requirements
- Stakeholder Requirements
- Solution Requirements - Functional and Non-Functional Requirements
- Transition Requirements
With so many requirements to identify it is very easy to get confused with how to identify these requirements?
A simple approach is to visualize the complete process and start step by step
To do that, let’s look at cooking for an example:
When you plan to cook a meal, you first take in account for whom you are cooking. Is it for yourself or for your family or the kids? These define your Business Requirements. Once you decide this, you figured that you will sip wine along with the food and the kids won’t eat spicy food (stakeholder’s requirements). Next, you get all your ingredients for the meal (functional requirements) and you might also take in consideration the time you require to prepare the meal and preparation required for serving the food (Non-functional requirements). Finally, you prepare a delicious penne arrabbiata pasta topped with oregano and basil leaves (technical requirements).
Now, let’s understand each of these requirements with a technical example, Implement Log-in functionality.
Business Requirements: These are high-level business objectives or goals or needs of an organization. The business requirements document (BRD) usually includes what features would be there in the product, what market the business will expand or enter, risk assessment, success measures from the business point of view, etc.
Example: There shall be a Login screen through which Users will log into the system.
Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.
Stakeholder (User) Requirements: These are what every stakeholder needs/expects from the solution and how they will interact with the solution. Often the stakeholders can explain the entire system in detail from their perspective only. Each stakeholder sees the problem from unique perspective. Therefore, you must understand all the needs to understand the complete system. All these requirements must be analyzed in such a manner that it doesn’t conflict with each other.
Example:
As a customer, the user shall be redirected to Dashboard on successful login. (Stakeholder - Customer).
As an admin, the user shall be redirected to the Administrator’s landing page on successful login. (Stakeholder - Administrator).
Tip to identify:
Similar to business requirements, but from user's perspective. Words or phrases that describes what, such as “we need to be able to”, “we need to solve this” and “we need a way to”.
Solution Requirements: These specify the detailed conditions and the capabilities that the solution must have to meet the business and stakeholder requirements. Software Requirements Specification (SRS) is created to capture both functional and non-functional requirements. These are categorized into two:
a. Functional Requirements: These define specific behaviors, responses, information, rules for the solution primarily addressing the following:
- The features the system will support (Functional capabilities)
- Data validation rules and how they will be managed (Business Rules)
- Interaction between different stakeholders (users) within the system (Use cases)
These include a complete description of ‘how’ the system will be built.
Example:
- Registered users shall be able to login with valid username and password
- On successful login, user shall be redirected to a landing page in the system
- On failure, for not registered username prompt "Username not registered" message and for invalid credentials prompt "Invalid credentials"
- New users shall be able to register with the system by clicking on the "Sign-Up" link
- Users shall be able to recover password by clicking on "Forgot Password" link
b. Non-functional Requirements (Quality-of-service): These define the environment in which the solution will operate. The qualities a solution must have or constraints within which it must operate smoothly. They define standards for Usability, Reliability, Security, Accessibility, Performance, Information Architecture, Portability, Extensibility, Internationalization, Integrity or anything that would help the success of the system in real-world.
Example:
- Performance: On successful login, user shall be redirected to the landing page within 10 seconds (max)
- Maintainability: Proper logs stating the operation result with timestamp shall be added on every login/signup/forgot password click
- Platform: The login functionality shall behave same on different platforms (Windows/Linux)
Tip to identify:
To easily identify between these, functional requirements can be considered as “verbs” and non-functional requirements as “adjectives” on these “verbs”.
Transition (Implementation) Requirements: These define conditions or capabilities only required to enable transition of the solution from development to real-word business use. It describes what must be done with the process, technology, education, training, enhancements before getting from the as-is into the to-be.
Example: Not valid in this example but for explanatory purpose: The login system shall behave same once "Single Sign-On" functionality is implemented
Tip to identify:
Look for temporary requirements such as “migrate from old system to new system”.
There are many other types of requirements that are used across diverse types of systems based on the scope such as:
Technical Requirements: Once the solution requirements are clear, the best way to start with the development frequently involves technology. It is a way to communicate between analyst and engineers (programmers, architects, designers) and is often written by the technical engineers. These requirements specify design and architecture for the solution components to be developed and implemented. They define how the solution will be programmed, store data and display data.
Example:
- Browser support: Current and recent versions of Firefox, Edge, Chrome, Internet Explorer, Safari, Opera
- Requires browser to have JavaScript enabled
Technical jargon's are used such as “password encryption algorithm” and “database schema” etc.
User Interface Requirements: These define the user interface design for the functionalities (derived from solution requirements). The placement of user input controls, buttons, links etc. on screen to allow the working of the functionality. Generally represented with wireframes.
Example:
- Textboxes for username and password shall be placed below the respective labels for Username and Password
- Login and Cancel buttons shall be present in center of the screen
- Sign-Up link shall be present below the Login button
- Forgot password link shall be present above the Login button
Requirement analysis is all about understanding, identifying and categorizing these requirements. With categorized requirements, it becomes much simpler for the team to understand and follow the system details.
#requirements