ICS 125: Practical Requirements Techniques
Requirements Techniques that You will Use
- User stories in user-needs.html
- Use cases in use-cases.html
- Feature specifications in features.html. And, as needed:
- Mathematical forumlas, first-order predicate logic
- Regular expressions
- State machines
- Algebraic specifications
- Decision trees, decision tables
- Feature mockups
- Mockups for your system
What Makes Good Requirements?
- The 4-C's of requirements:
- Clear: understandable so that all stakeholders can participate
in validation and all developers know what to build and test
- Concise: Short requirements are more understandable and
maintainable. And, they can often be more precise when you use
formalisms.
- Correct: Incorrect requirements will lead to reduced revenue,
or major rework.
- Complete: Incomplete requirements also leads to major rework
and last-minute schedule changes.
- Good Requirements are "Safe Progress":
- They align the team members' understanding of the problem and approach
- They uncover mistakes or misunderstandings early to prevent later rework
- The lay a foundation for design, and for testing
- They can be easily maintained: reviewed, changed, distributed to stakeholders
Requirements tips
- Half the challenge of requirements is understanding, and half is
technical communication. Even with formalisms, there will still be
significant textual descriptions, so careful writing skills do make
a difference.
- Sometimes it is easier to express a requirement in a semi-formal
notation than it is to express it in English
- It is often useful to express the same requirement in English,
and in a semi-formal or formal notation
- Don't specify everything in extreme detail, specify the critical
aspects in the most detail. E.g., safety properties. Also, use
formalism where it is easy to use. E.g., regular expressions to
define valid inputs.
- More detail is needed when people are added to the project
later, or if you will return to the project after a long time
away
- Requirements should guide and speed development, not take an
adversarial approach
sample use cases templateexample software testing plan templateProject plan template