What is a requirement?

Whatever kind of system, software, product or service you would like to offer to the market all your efforts are based on requirements to be fulfilled. Indeed, this is not new. Most of us are writing requirements since decades. But do we really know what a requirement is?

There are almost as many definitions out there as books available about Requirements Engineering. But do these definitions really help in our daily work?

A couple of weeks ago I had the pleasure to participate in a workshop about requirements methodology. At the beginning we did a small exercise. We got the following text frament – taken from a real-life example (!) - and we were asked to count the requirements regardless whether they are “good” or “bad”:

Sounds like a simple question. But: although most of the participants had several years of experience working with requirements we got an interesting result (the constructor wrote down the answers of the individual participants):

Why that?

Of course, each participant has its own experiences and knowledge about the system to be build which highly influences the way they read the document. So, you cannot expect to get a single answer…

Then we started to analyze the given text sentence by sentence trying to formulate requirements with better quality based on two of the most important characteristics for a “good” requirement:

• You must be able to implement the requirement
• You must be able to verify that the implementation fulfils the requirement

Using these quite simple rules we came to the following improvement (which still may not be perfect):

From this example you can see one of the major drawbacks when using word processing tools for requirements: Authors tend to provide justifications for certain requirements in subordinate clauses (e.g. 3 is the justification for 2). Then it may happen that they introduce redundancy (e.g. requirements 2 and 5 in the example above) which makes it difficult to maintain these documents. Apart from the implicit relations the author has “created” using subordinate clauses there are of course more relations between the different requirements we identified above. If you try to represent these relations in a more structured way you may get the following [please do not use a word processing tool for this… = ) ]

So, finally we identified requirements from four different abstraction levels within the first three sentences of the original document!

Think about it…

By: Andreas Plette

Practice Makes Perfect – Requirements Engineering Training

When I was young my mother decided I should take piano lessons. I was five years old and barely knew my ABC’s. My teacher was an older woman who sat down my first lesson and played Beethoven’s Moonlight Sonata for me. I was so impressed. I wanted to play that piece right away. An impossible goal, of course.

There was so much I had to learn before I could play that piece. I started with one hand (one hand, are you kidding????) and learned three notes on my first lesson. Then three notes on the left hand. Then five notes. I remember thinking this would take forever. And so on. It was many years of learning and practice before I was able to play Beethoven’s Sonata.

There were some key things I had to learn to do. First, I had to learn how to hold my hands properly. Then I had to learn to read music – a few notes at a time. Then I had to learn how to read the music and then play it. And, above all, I had to practice. I practiced at least an hour every day, more in the summer. And still it took five years for me to play that piece. My teacher was instrumental in that process. She taught me techniques. She corrected me when I made a mistake. I could not have learned to play the piano without her.

So let’s tie this to Requirements Definition and Management. Asking someone who’s never written or managed requirements to follow a robust and complex requirements process is like asking that five-year-old to play Beethoven’s Moonlight Sonata. And since we often don’t provide any training or mentoring, let’s ask them to learn to play that piece on their own. That’s what we are doing when we throw our analysts into a complex requirements process.

I suggest we consider training our analysts. Let’s stop thinking we all just “know how to do our job”. It isn’t true. We can learn to play that piece on our own. I would suggest instead of taking five years, it would have taken me ten years on my own. And so it is with our requirements engineers and analysts. We can let them learn on their own. Or we can give them some training, mentoring, and time to practice.

Of course, key to making this work (no pun intended) is having some kind of process defined that we use to train our analysts. I used to hate that “process” word, but it is important. Here are some suggestions for turning your new requirements analysts into expert requirements analysts quickly.

1. Provide training for your analysts around your specific process, using your requirements and deliverables, so the training is more real.Generic classes around requirements definition and management are great, but they must be in line with the processes you are following in your organization.If you are working with an outside consultant, expect that there will some effort in customizing the training for you.But it will be worth the investment.
2. Assign a mentor to your new analysts.Let someone who has “been there done that” and has the wounds and scars to prove it help the new analyst and show them the ropes.This will help eliminate that “tribal knowledge” thinking.Let them assist in elicitation sessions, review requirements documents with the analyst, and be a resource for them.
3. Let the analyst practice. That may not seem too practical. But don’t start a new analyst on a project that is critical to the company. Or one that has so much history and controversy around it that it will be difficult to move forward. Let them “practice” on a simple and well understood project to get their feet wet.

I believe the following statement is true.

“Good analysts are grown, no trained.”

Let’s grow some good analysts.

By: Marcia Stinson