Skip to content

Can your users read your requirements?

September 22, 2010

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.

Methodologies such as Process MeNtOR provides a very powerful approach to developing requirements. Users who implement such an 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.

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: