Requirement: A usable representation of a need. The focus is on the understanding of what kind of value could be delivered if the requirement is fulfilled. All requirements should be verifiable.
Representation: requirements in a document (or) items in a tool with a unique id for traceability
Business requirements:
They are statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.
Example: “The system shall enable customers to track their order status in real-time through a secure online portal, to improve customer satisfaction by 20% within the first six months of implementation.”
Stakeholder requirements:
They are the needs of stakeholders that must be met in order to achieve the business requirements. They serve as a bridge between business and solution requirements. User is one of the important stakeholders.
Example: “The system shall allow users to reset their password through a self-service portal by answering three security questions and receiving a reset link via email within 2 minutes.”
Solution requirements:
They are the capabilities and qualities of a solution that meets the stakeholder requirements. Their level of detail allows the development and implementation of the solution. There are two types of solution requirements. They are:
- Functional requirements: the capabilities that a solution must have in terms of the behavior and information that the solution will manage
- Non-functional requirements or quality of service requirements: do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.
Examples:
Functional Requirement: “If the pressure exceeds 40.0 psi, the high-pressure warning light should come on.”
Non-Functional Requirement: “The PIN code has six digits, without a space.” (Data/Format)
Transition Requirements
These are the capabilities that the solution must have and the conditions the solution must meet to facilitate the transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirement types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity.
Alternative summary view of the types of requirements
Categories of Non-Functional Requirements
It is to be noted, that Non-Functional Requirements are the most difficult to elicit. The non-functional requirements can be grouped into several categories as shown below. Every requirement should be verifiable – including Non-Functional Requirements
• Availability: degree to which the solution is operable and accessible when required for use, often expressed in terms of percent of time the solution is available.
• Performance Efficiency: degree to which a solution or component performs its designated functions with minimum consumption of resources (includes Speed, Throughput, I/O, Capacity, Power)
• Reliability: ability of a solution or component to perform its required functions under stated conditions for a specified period, such as mean time to failure of a device.
• Scalability: degree with which a solution can grow or evolve to handle increased amounts of work.
• Security: aspects of a solution that protect solution content or solution components from accidental or malicious access. what is required to block unauthorized access to certain system functions, how to prevent information loss, how to ensure that the system is protected from virus infection, and how to protect the privacy and safety of data entered into the system.
• Usability: ease with which a user can learn to use the solution
• Robustness: degree to which a system functions normally when presented with invalid inputs.
• Localization: requirements dealing with local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context.
• Certification: constraints on the solution that are necessary to meet certain standards or industry conventions.
• Compliance: regulatory, financial, or legal constraints which can vary based on the context or jurisdiction.
• Maintainability: ease with which a solution or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment.
• Extensibility: the ability of a solution to incorporate new functionality. (also referred as Flexibility)
• Portability: ease with which a solution or component can be transferred from one environment to another.
• Compatibility: degree to which the solution operates effectively with other components in its environment, such as one process with another.
• Interoperability – defines the ease with which the system can exchange data or services with other systems
• Testability: the ease with which system components or the integrated product can be tested for defects.
• Reusability: the ease with which system components can be reused across applications/solutions. Saves cost for business
Sample List of Non-Functional Requirements
For an illustrative list of non-functional requirements click here
Impact of Non-Functional Requirements on each other
“−” indicates that increasing the attribute in that row adversely affects the attribute in the column.
https://www.sciencedirect.com/topics/engineering/nonfunctional-requirement
Relationship across types of Requirements
Solid arrows mean “are stored in”;
Dotted arrows mean “are the origin of” or “influence.”
In practice, instead of a top-down flow, you should expect cycles and iterations..
Source: Wiegers, K., & Beatty, J. (2013). Software requirements. Pearson Education.
References
•BABoK-Business Analysis Body of knowledge, IIBA
•Business Analysis Standard V2.0 (IIBA(R))
•Wiegers, K., & Beatty, J. (2013). Software requirements. Microsoft Press
Dr. Selvaraj Vadivelu 