Can your users read your requirements?
Organizations often struggle with getting good requirements. Some organizations invest in their business analysts and develop standards, templates and maybe even training on how to create requirements.
With Process MeNtOR we provide a very powerful approach to developing requirements. Users who implement the approach see much better requirements being produced. But then a new problem becomes visible: the various audiences of these documents (business users, designers and testers) start having problems making full use of these documents. When analysing this issue further we saw that it was not so much of the documentation being faulty or too complex. What was missing was that most people do not really have an understanding how a concise and consistent requirements model can be structured and how it needs to be applied for their domain.
For instance
- A subject matter expert needs to be able to find those parts that are relevant to them to validate the requirements represent what is needed.
- A requirements tester needs to be able to cross reference the documentation to ensure consistency and correctness is preserved
- A sponsor or major stakeholder on the business side needs to be able to see the requirements summary and be able to determine that the scope matches to what their business case says
- A project manager needs to understand size, complexity and risk expressed in the requirements model
- An architect needs to be able to find the fundamental business stories and expectations to respond with an appropriate solution model
- A designer needs to be able to understand the use cases and their operational context to develop an appropriate system design
- A tester needs to be able to identify functional areas that can be mapped into test cases
All these users will read he same material selectively or with varying focus and look at different aspects. Writing different documents for each audience is not feasible for anything but the most trivial requirements documents.
With Process MeNtOR, we developed several strategies to address this situation. For a large project we developed document maps ("You are here"diagrams) and improved document introductions to guide the readers to the points of their interests.
But the best response we got was to develop a series of short courses called "Reading Requirements". Customized for the different audiences these courses focus on what the reader "needs to get out of" the requirements model. For a business user this may mean a session on effective reviewing of the requirements for sign-off. For a designer it focuses on how to translate Use Cases into system scenarios to derive component responsibilities which, in turn, result into a component design model.
The result of these courses has been positive because it breaks down barriers of having to deal with a new and not understood set of documentation. Requirements for any non-trivial system are inherently complex and the project risks are typically in those bits that are not obvious. Giving the readers of the requirements model the ability to find what they need to know improves the value of the requirements and reduces the overall risk of the project.