Communication and Validation
Good requirements can be identified because they succeed in communicating the intent to the relevant stakeholders.
However, it is important to realise that this in turn means that relevant parties need to be able to independently evaluate whether or not the requirements have in fact been sufficiently communicated — that is, can the results be validated?
Additionally, it is important to realise that the stakeholders, by definition, can include the full range of disciplines in the software engineering effort. That is, they would include business owners, architects, software engineers, process engineers, testers etc.
As such, requirements enable us to close the loop between various parties and the efforts involved:
- business owners should be able to review the requirements and evaluate the definitions to ensure that any implementation will in fact solve a business objective.
- software engineers need to be able to review the requirements and be confident that they can create a software system that embodies the automation required to support the requirements.
- testers need to be able to review the requirements and be sure that they can evaluate the outcome and demonstrate adherence to the requirements.
However, one quickly realises that requirements analysis and gathering can be an in depth, and potentially lengthy, exercise.
When working on projects and with software engineering teams, I will guide them towards “pipelining” the requirements gathering process and using suitable representations depending on the audience.
In this way it often becomes appropriate to have a progressive increase in the fidelity of the requirements:
- stories - written to capture the main players that will interact with the system and to highlight broad aspects regarding the dynamics of the system. These are often usefully supported by some structural diagrams.
- design documents - written with more detail and a greater focus on enumerating “business rules.”
- process models - coded forms that define, in more precise terms, the data flows between and across core subsystems.
- system models - coded forms that dig into the details of how the moving parts of the final system will interact.
The important point is to see that this forms a cascade of increasing detail in the representation of the requirements. At each stage the requirements themselves can be evaluated and refined, before expending the effort on the next level of detail.
Additionally, this process of incremental analysis of the problem space can work in both directions. For example, if certain interactions are not apparent at the level of a story, it is perfectly reasonable if this comes to light later on, and is then pushed back up into the higher level documents. This, in fact, becomes a valuable way for ensuring continued alignment between the work carried out in the project and the ongoing, and potentially changing, needs of the business.
It should also be apparent that not all problems will benefit from the same level of detail in the requirements gathering and communication process. If a few sentences are enough for everyone to work together then there is no need for the additional detail.
Therefore, by casting analysis and requirements gathering as a communication and validation problem, we can look for opportunities to short-circuit the process.
We keep ongoing communication flowing while delivering early, and evaluating the outcomes of our experiments. In this way, the focus is on delivering software systems that are aligned with the business needs.