IEEE’s definition of a requirement, paraphrased:
“A compulsory condition / capability that: -
- Solves stakeholder problem, or
- Achieves stakeholder objective, or
- Satisfies contract, standard, specification, or other formally imposed documents, or
- Documentation that represents the above."
Common Categories of Requirements, by use sequence:
- Business requirements:- The Why or purpose of the product defined as tangible or strategic value to the business.
- Business rules:- Constraints on the how of the product to be appropriate/ successful; usually regulatory, policies, budgets, image considerations.
- User requirements:- Core functionality for users. Formats include: use cases, user stories, user flow, storyboards, context scenarios.
- Functional requirements:- Inputs, outputs and behavior processed by product. Formats include: resources, deliverables, data flow diagrams.
- Non-functional requirements:- Performance quality. Commonly accuracy, dependability, security, usability, efficiency, performance, and maintainability.
- External interfaces:- Relationships with external entities, commonly media, protocols, formats, and levels of compatibility.
- Development constraints:- For creation of the product, i.e. platforms, computing power.
- Transitional constraints:- Occurs during transition of the product.
Use Case Common Items:
- Participating Actors - Description on roles of engagers
- Goal - Intended objectives
- Trigger - Events that prompt use case to begin
- Pre-condition - Conditions for the use case to occur
- Post-condition - Conditions that are true after use case completes
- Basic flow - Step by step description of what occurs in a sunny-day scenario
- Alternate flow - Description of alternative scenarios outside sunny-day
- Exceptions - Scenarios where the use case will not work/ apply
- Qualities - Performance quality aspects. See non-functional requirements
