Requirements

Help Text

A good design is always created using requirements and principles. Requirements are discussed and approved within an requirement process.

Requirements can be documented as use-cases (see other template). But trying to create use-cases for technical or quality constrains does not always make sense. It is important to prioritize requirements.

Use MoSCoW for prioritization. This stands for: M – MUST: have this. S – SHOULD: have this if at all possible. C – COULD: have this if it does not effect anything else. W - WON’T: have this not now, but would like this in the future.

Requirements marked as “Won’t” are potentially as important as the “Must” category. Classifying something as “Won’t” acknowledges that it is important, but can be left for a future release. In fact a great deal of time might be spent in trying to produce a good “Won’t” list. This has three important advantages: Stakeholders/Users do not have to fight to get something onto a requirements list. Thinking about what will be required later, affects what is asked for now. The designers seeing the future trend can produce solutions that can accommodate these requirements in a future release.

For very large projects collecting requirements in a special tools can work. But often using excel or a text processor is also fine. The most important aspects is that all relevant stakeholders have direct access to the requirements document and can read requirements when using an architecture deliverable. If needed attach the requirements to a specific architecture deliverable. Having requirements in an open format (csv, json or plain text, wiki) means requirements are alive and part of a life-cycle management process. Putting requirements in an tool is never a solution for not having an requirement process.

Requirements

RequirementID | Requirement Description | Type | Priority —————|————-|————-|——|————- 10 | Encryption keys must be secured. | Business | MUST