If there is one area which I feel I’ve become stronger in over the last two years it is requirements and requirements capture.Yet paradoxically I feel it is the least well handled in my experience.
Concepts are often quite clear, and usually about as coherent as may be expected for any given system. Logical architectures have all sorts of standards. But requirements seem to be more about controlling risk than delivering good engineering value.
So, what then is the correct way to handle it? I understand good requirements as serving two stakeholders:
- The Senior Responsible Owner for the project
- The team responsible for the system’s logical architecture
These stakeholders have many needs, but two salient requirements for …er… for their requirements.
- The SRO must be able to negotiate, and this means doing trade-offs between requirements.
- The logical architecture team want to turn the requirements into a model of objects, procedures, and people, and the relationships between them. The more the requirements reflect these types of data the easier the job gets.