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).

Requirements’ format

Consequently, we can identify the following elements in a requirement’s construct:

  1. A subject. One must nominate which is the actor the requirement is about.
  2. An action. Must be active voice. This states the behavior, action/reaction, embodies the very reason of the requirement creation.
  3. 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.
  4. Additional information. Could be missing or mandatory to appear. This part is specifying all additional 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 opinion, a requirement must be writen as for simple 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 ensure:

  • 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.

Example:


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.

Comments

New comments are not allowed.

Popular posts from this blog

My Action Dashboard so Things Get Done!

Image
We all know the feeling of being overwhelmed by the sheer amount of tasks that land on our desks each day. It can be difficult to keep track of what's most important and to stay on top of everything. That's why I wanted to share with you my experience with Microsoft ToDo. At first, I was hesitant to use ToDo because of its simplicity. But thanks to its integration with Outlook and its ease of use, it quickly became my go-to tool for planning my day and staying on track. I struggled with finding a system that would help me prioritize my tasks and keep my work and personal tasks separate, while still having them in a single view. That's when I discovered the MS ToDo integration with Outlook. With ToDo, I can easily share a list with any user and keep my work and personal tasks separate. Every morning, I review my tasks backlog and choose the most important ones for the day, adding them to 'My Day'. Then, using Outlook's 'Boards' view, I can load my 'M...
Read more

The Power of Good Enough: Why 90% is Perfect

Image
It's easy to fall into the trap of perfectionism in the pursuit of excellence. We set impossible standards for ourselves and try to achieve flawlessness in everything we do. However, the truth is that perfection is an unattainable goal, and even if we try our hardest, there will always be room for improvement. That's where the Pareto principle, also known as the 80/20 rule, comes in. This principle states that roughly 80% of effects come from 20% of causes. In other words, for any given task or project, 80% of the results can be achieved with just 20% of the effort. But what about the remaining 20%? That's where the principle of "good enough" comes in. In most applications, achieving 90% of the desired outcome is sufficient. In fact, striving for more than that can be counterproductive and lead to diminishing returns. For any practical purpose, 90% is perfect! Think about it: If you spend 80% of your time and energy trying to achieve that last 10%, you're only...
Read more

Why Am I Doing This Thinking Online

Image
In the last couple of days, I had some debate with my wife on why writing everything down. This can be an annoying habit sometimes, I admit. Though, there is a long way towards I could say I’m exaggerating. Only trying to get out the best of me, and the situation at hand. Then I took some time for really thinking about it. All my lofty ideas' implementation followed through to completion and all accomplishments came like this. Cause what good is a god given strike of genius that only happens into your head, when it dies being forgotten the second day, never having the chance of being transmuted into reality? This crystallized my vision on approaching problems, and realized all is well confirmed by my previous experiences in life, both by successes and missed opportunities. At the same time, this clarifies (to me for first) my activity here, on this site. Opportunity is missed by most people because it is dressed in overalls and looks like work. – Thomas A. Edison  1. I have an inte...
Read more