ICS 125: Practical Requirements Techniques

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

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