- Jack Be Nimble
- Wicked Problems and Gordian Knots
- Jack Be Quick
- Jack and Jacqueline Jump over the Candlestick
- Agile Business Analysis and Iterative Development Cycles
- And Jill Came Tumbling After
- Knowledge Artifacts
- Jack Sprat Could Eat No Fat
- Traditional Business Analysis
- The Requirements Document
- They Have Licked the Platter Clean
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Requirements Document
The requirements document, sometimes known a requirement specification, is a document that has caused heated discussion within our industry. It has been blamed for practically every problem with solution delivery that does not involve natural disasters. And it is true that there have been many examples of appalling requirements documents that were badly written, too big, too late, or overflowing with extraneous and irrelevant information.
There is no law that demands that requirements documents are heavy handed and unwieldy. They can be lean and useful.
We have written a book, Mastering the Requirements Process, that covers in detail how you produce this document. It needs more space to describe than remains here, so we will confine ourselves to giving you a brief outline of the contents of a good requirements specification.
The first thing about writing requirements documents is that they must be kept as minimal as possible. There is always a temptation to write more than is needed in the hope that doing so makes the document more authoritative. It doesn’t.
The requirements document must be structured so that your readers can find whatever they are looking for as conveniently as possible. Your requirements need to be traceable, so they should be identified in a way that allows you to trace the requirement through development and testing. When making changes to requirements, it is necessary to be able to identify the impact of that change throughout the rest of the specification. Consistent naming makes this possible, and considerably easier.
Consider the partitioning that you have been using throughout your analysis. Have you, for example, been doing your analysis one or two customer segments for each iteration? If so, does it make sense to present your requirements grouped by customer segment? If you have used business events to partition things, you might consider writing the requirements document event by event.
There are various ways of writing a requirements document, and you can find examples and samples on the web and in textbooks. We’ll briefly touch on our own Volere Requirements Specification Template, which is a guide to writing a requirements document. It works and has been downloaded thousands of times by organizations and business analysts around the world.
The Volere specification begins with the constraints imposed on the solution. Constraints here are the factors that restrict the way in which the solution can be designed, and the scope of the solution. These constraints can be environmental constraints, design constraints, and so on.
Then come the functional requirements. The functional requirements specify the part of the solution that does something—calculating, manipulating, forecasting, and so on. These are described with requirements that begin, “The product shall …” and then a verb indicating the required action.
Functionality is only useful if it is done in a way that fits with its audience and its environment. The next section of the template presents the nonfunctional requirements. We have also referred to these as quality needs in earlier parts of this book.
We wrote about these nonfunctional requirements in the previous chapter, so we won’t do more here than repeat the list of types:
Look & Feel Requirements—Appearance, style, and so on.
Usability—Ease of use, personalization, internationalization, learning, understandability, politeness, accessibility, convenience.
Performance—Speed and latency, safety, precision and accuracy, reliability and availability, robustness, fault-tolerance, capacity, scalability or extensibility, longevity.
Operational and Environmental—Expected physical environment, wider environment, requirements for interfacing with other systems, release, backward compatibility.
Maintainability and Support—Maintenance, supportability, adaptability.
Security—Access, integrity, privacy, audit, immunity.
Cultural—Aspects relating to human reactions.
Compliance—Legal standards.
The nonfunctional requirements are written as a series of statements starting “The product shall” and then the appropriate adjective. This statement sometimes can be a little vague, so you follow it with a rationale that states the reason for the need. Then comes the fit criterion, which measures the requirement and makes it testable.
Description—The product shall be attractive and attention-getting.
Rationale—The product is used as a demonstration product at trade fairs. If visitors do not make some use of the product, the exhibitor forgoes potential customers.
Fit criterion—70% of visitors begin using the product within 4 seconds of first seeing and having access to it.
You can see more of the Volere Requirements Specification Template at www.volere.org.
Keep in mind that requirements specifications are almost never written wholesale. Business analysts write them iteratively, adding to the document as information becomes known.
And, before we leave it, most analysts find it convenient to include a project lexicon so that all readers of the document are aware of the terms being used and their meaning.