Your Customer Has Rights…. And Responsabilities

Let’s talk about what the customer has a right to expect from us. The customer can expect that analysts will speak the customer’s language and that we will learn about their business. This means we don’t throw a bunch of technical and design requirements at them and ask if this is what they want. Developers will explain their solution and will treat the customer with respect. Developers will NOT tell the customer how they should be using the system. And developers will not become defensive if the customer doesn’t think the proposed solution will meet their needs. The customer can expect that they will be provided opportunities to adjust the requirements as needed, within the defined process. They can expect that we will provide them with good faith estimates for the work. And, above all, they can expect a system that meets their functional and quality needs.

We are often focused on the customer rights, and so is the customer. But sometimes we forget to discuss with them their responsibilities. Often we assume they understand our process and know what their responsibilities are. As a result we don’t bother to tell them what we expect from them. Sometimes we skirt around the issue because we don’t want to “upset” them by telling that we have expectations about what we will receive from them. Sometimes we just don’t even think about it. So what are the customer responsibilities? Well, let’s be clear about what we expect from them.

If we are going to learn about their business they have to teach us. We expect customers to be precise when providing information and to make timely decisions when necessary. We expect customers to prioritize requirements and not just assume all requirements are a “high priority”. We expect customers to review documents that we give them and provide us with real feedback regarding the accuracy of our problem statement (user requirements). We expect customers to communicate changes as soon as possible and not wait until the last minute to provide them to us. Lastly, we expect customers to respect our requirements process. If we expect them to respect our process then we need to make sure we all know what that process is, including the change request process. If we cannot explain our requirements process, then how do we expect customers to understand out process? Being able to help customers understand the process is a critical piece of getting customers on board with our processes.

By communicating this information during the project kick-off meeting we are ensuring that we all understand our responsibilities to each other. It’s not just a one way street. Customers who tell us once what they want and then never communicate again will be the ones who say “I told you what I want, why didn’t you build it?” Analysts who document the requirements and never discuss them with the customer are the ones who say “We built what you told us, you didn’t know what you wanted.” Let’s remember there are responsibilities on both sides. And let’s make sure this is made clear to everyone on the project team. Think about your customers. Do they understand and respect your requirements process?

BY: Marcia Stinson

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

Trick or Treat – A Technique for Gathering Requirements?

As Halloween approaches I watch the children getting excited about their costumes and their favorite activity for gathering loads of candy. I remember teaching my little ones to say “Trick or Treat” when they go to the door. We spent weeks selecting just the right costume; we rehearsed going to the door and saying “Trick or Treat” and then “thank you’. We planned our route for Halloween night. You could call this the “Trick or Treat” process.

The result is a bag of candy – all kinds of candy that you can imagine. One of the first things we would do when we got home was to go through the bag of goodies and sort it – a pile for gum, a pile for chocolate, a pile for fruit flavored candy, and so on. Once the candy was sorted the little ones would then organize it by the favorites – so they could make sure and get their favorites first, since they weren’t allowed to eat the entire bag that night.

You’re probably reading this and thinking cute story, but what on earth does this have to do with requirements? So I will make a couple of points here.

First, if you are interviewing users and basically say “Trick or Treat – give me some good requirements” guess what you will get? You will get a hodgepodge of things that the users would like to see. Some will be important to you and some will not. You will have to sort through all of those needs and sort them into categories. We usually call those categories features. Some of those features will be pertinent to the project and some will not. So if you are beginning to gather requirements why not be more focused in the questions that you ask? Do some research and look at any information available that is pertinent to the system. Identify end users (you don’t have to trick or treat in the entire subdivision, focus on a couple streets where the really good treats are given) and set up meetings with them.

Identify processes that are affected by the project – which ones are changing, which ones are new, are any no longer needed? Ask the users what processes are working well for them? Work to understand how they are doing their job today.

Second, once you have sorted the requirements into features, you will need to prioritize those features. What are the customer “favorites” for getting done first? Sometimes we fail to really prioritize and end up working on the easy parts of the system first, instead of focusing on parts of the system that are high risk or not well understood.

At the end of the project, revisit what happened. We might ask if we went on the right streets, if we followed the process or deviated for some reason, did we get as much candy as we expected? What worked well? What changes could be made to improve the process? Did we get the expected end results? Were the users satisfied with the product?

So even though this is written with a little Halloween humor, hopefully the points made here will hit home when thinking about gathering requirements! Happy Halloween!

By: Marcia Stinson