How to Write Your First Requirement
People always complain about the poor quality of requirements, but usually that all they do say: requirements are a mess. What would really be useful is they say what’s wrong with them, why they don’t like then, what to improve, what cannot be implemented or tested; generally, where they need to be able to do their work.
There are of course some recommendations and rules to writing requirements.
Good practice and a complete document nevertheless come following an optimal combination between experience, product knowledge, industry know-how and a solid and clear systematic approach.
There are requirements format rules, and document structural guidelines/checklists that a requirement set for any product should follow.
Writing clear and unique requirements
Requirements unicity may be expressed in a complementary fashion:
- each thing /requirement must be described just once, in one place (avoid redundancy and support consistency),
- one requirement must specify a single thing (add clarity and easy understanding).
Consequently, we can identify the following elements in a requirement’s construct:
- A subject. One must nominate which is the actor the requirement is about.
- An action. Must be active voice. This states the behavior, action/reaction, embodies the very reason of the requirement creation.
- A condition. Could be implicit. This tag / part is coming to limit the event happening. It could explicitly tell when or if the action will happen.
- Additional information. Could be missing or mandatory to appear. This part is specifying all aditional info necessary to have a complete image, to have the requirement complete, understandable and clear.
The objective is to avoid vague specification, as well as avoid ambiguous or exasperatedly academical wording too rarely used (even if they give a sense of authority or seriosity, veridicity ..). I my oppinion, a requirement must be writen as for simle people, one passing-by the company entrance in the street must understand there’s something to do, by whom, when and upon whom. We are engineers, after all. In this way, we can assure:
- common understanding along project members (developers, testers …)
- avoid misunderstandings, the requirement has a single sense and cannot be interpreted, right?
- speed up development and testing times
- decreasing the workload of the architect, as he will have to clarify less items, less open points
- increasing the ramp-up speed of new people coming to work on the project, as the language is clear, easy and not specific.
That may be a little “poetically” exaggerated example, still, it illustrates concept described above. Now, we know who is doing what, upon whom and when.
Next time, we will talk about how to link requirements together, to consistently define a product’s necessary characteristics.