Requirements express what a system should and should not do and constitute the system boundary.
Functional Requirements describe the actions that can be performed on a system by a user. Non-functional Requirements describe observable properties
In theory: - Requirements describe what a system should do. - The design describes how the system should do it. - Requirements should be specified independently of design.
In practice: - This makes the feasibility of requirements difficult to determine. - Pre-existing infrastructure often constrains what can be done
Maintaining requirements as a project evolves is important.
- Focus of on-going discussion with the customer
- Drives acceptance testing
Lots of different requirements specification notations.
- Formal specifications
- View frames
- UML use case and activity diagrams
- Pseudo code
- Natural language
- …
User Stories are commonly used in agile projects.
Requirements Scope
In theory, every action on a system should be a user story, but this means:
- The scope would be unbounded
- Many user stories would be duplicated across multiple systems
- Effort would be wasted on acceptance testing of underlying framework(s)/dependencies
Instead, focus on the business logic that is particular to the application under development Treat framework features as assumptions about user roles, e.g.: Instead of:
- As a user
- I want to login
- So that I can access privileged features
Use:
- As an account owner
- I want to review a summary of my bank balances
- So that I can monitor my cash flow
Functional Requirements
Non-functional Requirements
Can also be expressed as user stories
- As a buyer.
- I want my search of properties to return in less than 5 seconds.
- So that I don’t waste time