Requirement Analysis - Part 1: Types of Requirements
Krishna Krishnan
Product Owner | MBA, Backlog Management, Process Improvement, Product roadmap Management, Product development, Agile, Requirement Engineering
We have earlier had a look at methods of requirement elicitation. Once these requirements are gathered, it is time to understand and analyse these requirements leading to further drill down and basic documentations for consensus. BABOK divides requirements into basically four types.
- Business requirements
- Stakeholder Requirements
- Transitional Requirements
- Solution Requirements
- Functional Requirements
- Non- Functional Requirements
This article is going to go through these types of requirements and the basic differences between them.
Business requirements are the very high level statements of what the business intends to achieve, its goals and objectives at the organization level. The main characteristics of this type of requirements are
- They explain WHAT the business wants to achieve.
- They explain WHY the business wants a project to be undertaken or implemented.
- The define the metrics that will measure the output or success of the project
- These are very high level requirements at organization level and do not provide any clarity on the requirements at screen level or even as a solution to a particular group of stakeholders.
Example of a business requirement could be "We would like to improve our customer relationship management process so that we could improve customer response by 50% over the next 1 year."
Stakeholder Requirements define what is demanded by the stakeholders to solve their problems. Sometimes the stakeholders have a particular solution in mind which might or might not work when it groups with the thoughts of other stakeholders. Hence, it is important to understand the various problems of stakeholders before devising a solution and not to get corrupted by their thought patterns. Often the actual solution will have to be proposed on a common ground.
These requirements have a clear traceability to the business requirements and not so much to the solution, though they provide hints in this direction. Some characteristics of this requirement are:
- They define what stakeholders need or require from a solution
- Identify use cases of a solution
- They are the bridge between the business requirements and solution requirements.
Example of a stakeholder requirement could be "We would like a mechanism to monitor the response time from various customers. We would also like a better CRM system since the current CRM leads to problems when managing customers reducing employee efficiency."
Solution Requirements: This is the type of requirements that most developers and business analysts are most comfortable with. Just as multiple stakeholder requirements could satisfy a business requirement, similarly multiple solution requirements could satisfy a stakeholder requirement. Hence, these should be traced back to the stakeholder requirement. Some important criteria of these requirements are
Solution requirements what criteria the solution will support.
This would define how the solution would satisfy various stakeholder requirements. These can be further divided into
- Functional requirements: In case of a system, these define the features and functions of the system which are mandatory for the system to be called complete or working. Example of this feature could include quick insertion of leads who contact through contact-us page of bank into CRM.
- Non functional requirements; These are often not explicitly mentioned by the stakeholders but these are as important as the functional requirements, if not more. They define the various qualities of the system based on which the system would remain effective or usable. Example of such requirements could include the load time for a page, the number of concurrent users supported, multi language support, accessibility from multiple systems. security, availability, etc.
Transition requirements: These requirements are features that a solution must have during the development stage and can be removed at the end. These requirements are temporary and are necessary for change management. They might not be explicitly mentioned by the client.
Example of a transition requirement could be "User should be able to use the system effectively.".
Please feel free to let me know if you have any further specific questions that you would like answered and I will try to address them in one of my upcoming articles.