Requirements Management in an agile world

Since a couple of years agile development is a mega-trend. One of the most famous processes in the agile world is Scrum. In theory, Scrum does not need any software tools for managing “epics”, “user stories”, “product backlogs” or “sprints”. Simply speaking you just need a whiteboard and lots of post-it^®. But what if your Scrum team is distributed? Or if you want to benefit from the work done in the past? Then it would be useful to have the data stored somewhere…

Why not using a flexible requirements management solution which is capable to enforce any kind of process. Let’s take the following process as an example for an implementation of a Scrum process:

The Product Owner will describe “epics” and “user stories” derived from them (traceability!) where “user stories” will automatically be included in the “product backlog” getting some product backlog specific attributes (e.g. delivery date, priority, assigned team). Each Scrum team can easily find the “user stories” assigned to their team and decide which stories they want to deliver in the next sprint. As soon as the story is assigned to a dedicated sprint (but not before) the scrum team is allowed to derive individual “tasks” which are assigned to certain team members. Each “task” will also have a status (to do à in progress à done).

Using a professional requirements management solution will allow:

• the product Owner to see which "user stories" is/was implemented in which sprint:
  

• the Product Owner to see the current status of the tasks derived from the "user stories" for a particular sprint:

• The Scrum team member to focus on his tasks:

Professional requirements management solutions allow to define role-based views on the data which improve efficiency tremendously.

Furthermore generation of various reports (e.g. burndown chart) from the actual data is just a single click – if not done in batch mode. Those reports might be in HTML format to include them in the intranet.

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

Non-Functional Requirements – they can bring a project to its knees

Often during system development we become very focused on making sure we meet all of the functional requirements for a system. Although functional requirements are indeed very important, they are not the only way a system will be evaluated by end users and business owners. If a user can indeed retrieve a credit card statement, but it takes five minutes to do so, the user will likely not be happy with the product.

Consider this example. In a book called “Angle of Attack” by Mike Gray he discusses the impact of requirements on the development effort to send the first man to the moon. He mentions two non-functional requirements that came from President John F. Kennedy. First, was that the astronauts were returned safely. (Seems reasonable to me. Who would volunteer to go if that weren’t a requirement?) Second, that the project would be completed within the current decade. Reading this book made me realize how a simple requirement like “during this decade” can change the entire scope and focus of the development effort. In this case, instead of going through normal system engineering practices and performing risk analysis, all of the development efforts were focused on finding a solution quickly through rapid trial and error. The entire process changed based on that single requirement. The requirement to bring the astronauts back safely resulted in a whole new project which involved getting the astronauts off the moon and back into the spaceship to return home.


I have my own example of the impact of non-functional requirements. When working on a weapon control system we had a reliability requirement. When we began looking at the reliability we needed to achieve we found the only way to achieve the required reliability was to add a second processor as a backup. It seemed like a reasonable thing to do. In the end it became a nightmare. The effort involved in backing up data and processes, and keeping track of the exact state at the time the processes and data were offloaded was very tricky. Testing this was a whole different problem. There were so many possible permutations of the situation that it was impossible to test them all. The effort required to support this single requirement was much more than any of us anticipated.

The more non-functional requirements there are in a system, the more expensive to both develop and test and the higher the risk. In particular the requirements that affect the entire system have the biggest impact on schedule and cost.

So what do we do with all of those non-functional requirements? It just isn’t feasible to just throw them out, of course. The best we can do is look at each non-functional requirement carefully. When users specify non-functional requirements ask them why this is important. Verify that the requirement is really necessary by understanding its importance to the end users. Verify that the pass/fail criteria are valid. In some cases users will say something like the system must be available 100% of the time without thinking about what they are saying so ask if this is a hard number or what the user would like to see.

When users state non-functional requirements like “user friendly” don’t just let that little requirement slide into your document without understanding what this means to the user. Ask how the user will test the system to determine it is user friendly. With the user, create criteria that can be used to determine if the requirement is met. Documenting these criteria up front with users will make sure everyone understands the intent of the requirement.

In short, make sure you know why the non-functional requirement is important to the user and how success will be measured. Getting this information up front will help you create a better solution.

By: Marcia Stinson