According to the BABOK® Guide, a requirement1 is:
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2).
1 Based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.
As the definition implies, a requirement may be directly stated or unstated, or it may be derived or assumed from other requirements. At the very least, it must be transparent and understood by each member of the project team and all stakeholders. And it must be comprehended in the broadest way possible for the project to be a success. That’s where you come in.
When it comes to requirements management, you will be called on to manage possible and actual conflicts and issues between the project team and stakeholders. You will be responsible for how requirements are communicated to stakeholders and how the knowledge you acquire will be used in the future.
Requirements may include business capabilities and its rules, policies, and organizational structure. The past, current, or future state of a company’s information systems may also be a requirement. Product owners’ and stakeholders’ goals may also be requirements.
Remember, we are talking in broad terms here. It’s easy to be detailed and specific with requirements, such as when describing a new software program. However, if you can broaden your outlook, you’ll see requirements more clearly. You may decide at which level or type the requirements fall into.
The BABOK® Guide describes the various types of requirements:
- Business requirements are high-level statements of the goals and needs of the business. They describe the who, what, where, why, when, and how reasons of a project. The business requirements are a broad overview of the business itself.
- Stakeholder requirements communicate the needs of one particular stakeholder or class of stakeholders. They describe how the stakeholder’s needs will be met with a solution.
- Solution requirements describe which aspects of a solution meet stakeholder and business requirements and stakeholder requirements.
- Functional requirements describe the functional capabilities of the system in managing behavior and information.
- Non-functional, or supplementary, requirements describe the environmental conditions under which the solution must remain effective. They may include requirements related to speed, capacity, availability, security, and architecture of the user interface.
- Transition requirements are temporary and describe how the solution will transition the company from its current state to its desired state. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation.
How do you use requirements in your BA practice?