This does not necessarily imply that a requirement which fails to satisfy all these criteria is irrelevant. It just means that it can sometimes be more challenging to work with afterwards. The aspect of “traceability” is a little hidden, but nevertheless very important. As shown above, its purpose is to determine why this requirement makes sense or where it comes from. This is crucial as the reason for a requirement is sometimes forgotten over the course of a project. When this happens, it could be argued that the requirement itself is irrelevant, but that is often a fallacy. For example, if new members join the project team, they may need to familiarize themselves with the requirements.
Where to Get Your Requirements From?
We already came up with some initial requirements in the AND-OR tree of our model project, even if they do not yet meet all of the criteria. Our stakeholders were the main source of these requirements. Other sources include a variety of standards and laws as well as competing, previous and legacy systems. In our model project, they would sometimes be incentive events organized by other teams or previous events within the same team.
The simplest cases involve interviewing the stakeholders and reviewing documents to determine the requirements and their priorities. Besides that, there are various other techniques that will not be addressed in more detail in this series, such as observation or creative techniques.
Notation of Requirements
I have had good experience with the use of sentence templates to note requirements. The structure is always the same and the content is (completely) detached from technical implementation. The sentence template I use – like many other people probably do as well – looks like this: