Software development lifecycle processes can sometimes be seen as impediments or tedious tasks. But it is worth reminding everyone that the smart work up front will save you headaches later. In my experience, well-written software requirements serve two main purposes: it orients all project participants and helps get buy-in about what you’re trying to do (since you’re articulating what you’re trying to accomplish), and it makes sure that everyone (from the project sponsor(s) down to the technologist and back up to the end user) can say that the project is done to expectations.
The trick is how to write a good requirement, for any number of situations. Part of the answer is to follow this convention:
The [your words here: system, actor, function, dependency, etc.]
must [your words here: do, process, store, etc.]
to [your words here: accomplish a goal, serve a purpose, etc.].
and to focus on the “what” (substance) of the need as opposed to the “how” (design) of the need. In addition, there are 8 key criteria that each requirement should satisfy to be considered well written.
