Requirements Management Process Analyzed

This article answers basic questions about the process of managing requirements.
Published in ITWorx Insite Magazine, January 2008

Many software methodologies are available for organizations to choose from and employ in their software projects development lifecycles. Smart organizations approach each project with a fresh perspective, picking the methodology that best fits the project conditions. Project’s size, complexity, timeframe, client’s style are all examples of the factors that contribute in the decision of which methodology to adopt.

Some projects go down the path of traditional methodologies such as Waterfall or Spiral; while other ones set on the path of more unconventional methodologies, namely Agile or XP.

Methodologies impact the way requirements are handled in projects, particularly by determining the timing of executing certain requirements-related tasks and the thoroughness of the related artifacts at different times throughout the project lifecycle. But incorporating the principles of managing requirements in the overall project management activities will undeniably remain a critical necessity for the success of any project, regardless of how heavyweight or lightweight the adopted methodology is.

Whether requirements are being developed in consecutive, incremental, or parallel fashion; and whether they are communicated in documents, repositories, or Wikis; the rules and exercises of managing the requirements process can be abstracted to two states: Awareness and Preparedness. So long as these two states are alive in the project, the bits and pieces of application can vary without affecting the end result.

By adapting the fundamental principles of the Requirements Management Process to the varied used methodologies, we would be in fact “Managing the Requirements Process” in any shape it takes following the adopted methodology.

This article attempts at summarizing the requirements management exercises that should be honored in any project – regardless of its running style – as they relate to the two previously mentioned states: Awareness and Preparedness.

Stakeholders Analysis: Who are we doing it for?

Profiling those who will benefit (or not) from the project is the first healthy step to prepare for the trip. You need to be aware of those who will be sailing through the project with you. Who has the information you need? Who can validate it? Who needs to approve decisions? Who will authorize payments? Who will constantly work with your solution? The two essential groups you can not afford to overlook in this profiling exercise are the decision makers and business users. These are the “never-miss” groups. Each group is likely to need a distinctive communication strategy. Recognizing such need ahead will save you surprises down the road.

Hence, planning the requirements-related activities

Activities Planning: What shall we do?

Activities related to requirements constitute an essential component of software projects; and they are not a one-size-fit-all type of work. Not all activities will make sense at all times for all projects. For example, how many times have you found yourself wondering “will the users understand the SRS?” or “will the CEO have the span to read through the system use cases?” Your concerns are valid. Different audiences present different categories of stakeholders; and each category has its own way of relating to the world, and to the project. That is why you may end up producing multiple artifacts with more or less the same information but in different styles of presentation to ensure everybody is happy and, more importantly, aligned. Sure developers will appreciate a detailed system requirements specification document (SRS); whereas the not-so-computer-savvy business users might appreciate prototypes or use cases; the executives, on another hand, will do with an impressive 20-minutes presentation.

Defining the activities needed to develop, maintain, validate, and communicate requirements ahead in a plan is like sketching a high-level map of the roads that the team needs to follow to get to the destination. It helps avoid surprises down the road that could affect the project schedule and budget. Although defining the activities may not be possible until you collect some information about the project and the people involved, it is wise to think about them as early as the situation allows.

Roles Assignment: Who shall do it?

Nothing frustrates a team and inhibits its freedom to take initiative and innovate as much as not knowing what exactly is the role of each of its members, or having fuzzy borders between responsibilities. I am yet to meet a team who appreciates crossing and stepping on each other’s toes while carrying out work tasks.

Clearly defining the role of each member, and communicating these roles to all involved guarantees synchronization; prevents frustration; and ensures the project’s time, budget, and resources are efficiently utilized. The possibility of having more than one person unnecessarily performing the same activity, or the possibility of missing an important task because no one picked it up, is an overhead and a waste of time and money that can dramatically damage the project.

Prioritization: What is important? I mean what is really important? Well, how about what is more important?!

No one seems to think requirements prioritization is even possible; clients feel – more frequently than not – equally attached to all their requirements. Of course, they are! They wouldn’t have asked for them to begin with if they weren’t. While BAs and PMs seem to be the only ones who appreciate the beauty and value of prioritizing requirements, the whole matter is out of their control; it is in the client’s hands. Clients resist letting go of requirements or delaying their delivery either for genuine valid reasons or out of pure emotional attachment. If you are able to differentiate the reasons, you are in a better position to negotiate the ones that their postponement would not dramatically affect the client’s business. By involving the right people and building a good valid case, you can still negotiate a fair deal. Remember that it is totally legitimate to reprioritize whenever new factors that necessitate change emerge!

Managing Scope: Wait a minute; is this in or out of scope?

Assuming that you were prepared and have carefully outlined the original project scope, scope creeps that take place later should not be very dangerous. After all, an extra piece here or there will not kill the project.

For more on scoping software projects, read my other article “Starting IT Projects on the Right Foot”: http://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/StartingItProjects.pdf 

However, there are times when requirements must be revisited and the project re-scoped due to events outside the control of the involved parties. As long as you are aware of that, both parties can cooperate to reach a satisfactory solution, such as: Expanding the scope – provided that the additional cost and time are accepted and the vendor has the capacity to accommodate the expansion, trading off some of the original requirements (that have not yet been developed) with new ones, or waiting for next releases.

Change: I see it coming, are you ready?

If your final product still looked on its deployment date the same way it did when the first set of requirements were handed to you, let me tell you that you are one of the few extremely lucky ones in this world who lived to see such phenomenon when software reality matched the dream on papers!

An up and running system rarely looks similar to the original sets of requirements; this is because visions have their own way of evolving and changing form on their way to becoming reality.

Requirements change for all sorts of reasons: A change in business, market, or investment environment; users develop new needs; developers discover new possibilities or constraints, or recognize misunderstandings in the original requirements. We all know that change is a fact of life that we have no ability to stop. Preparedness and adaptation are the only practical tricks we can employ to stay in command and sail through the lifecycle of the project smoothly and pleasantly as much as our authority and position allow us.

Changes are not that bad in themselves, on the opposite, they can improve the product quality; but uncontrolled changes can be a perfect recipe for failing a project. So unless you want the project to fail, you must keep a state of awareness and readiness to handle changes.

The first you should look for in your checklist of Change-Avert enabling items is “Have you got a more or less clear roughly-measurable scope?” Do you know who gave you the requirements and why they were required? Do you have a baseline – a version of requirements that everybody is working on? Most importantly, are you honoring this baseline and carefully tracking who changes it, when, how, and why? Are the requirements structured in a straightforward way at a good level of modularity and granularity; and are the traceability trees kept up to date – beginning from the source and reasoning behind the requirements down to the system components and test cases?

Tim Moore, a Senior Consultant in Experimentus skillfully details the process of change management in his article “Ensuring Change Control Procedures are in Place”: http://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/Ensuring_Change_Control_Procedures_are_in_place.pdf 

Risks Management: Can’t afford to loose it? Then don’t risk it!

While some risks are benign by nature and do not impose great threats to a project (what if your stakeholders are located in different locations? The project can still survive with careful communication), other ones have got the potential to greatly damage the project (what if those who will place the green or red mark on your deliverable to authorize payments are not involved in the major decisions taken along the way?).

Are you maintaining a good level of awareness about the requirements-related risks and their seriousness? Awareness means that you are keeping your eyes on the risks, routinely calculating the odds of their turning into real issues, doing what is needed to keep them in check, detecting when they are about to cause problems, and having some idea about the way to react in the unfortunate event of the risks materializing and turning into real problems.

To conclude, we now know well enough that managing a project is more than managing its budget, time, and resources; it is also about managing the client’s needs, which form the pillars on which the building stands. Requirements are – and will always be – the backbone of any software project. Not managing them by being prepared and aware is risking more than we can afford to loose.