Requirements are a Project Management Tool

by Suzanne Robertson

August 2005

Listening to music, travelling to work, making a cup of tea – these are familiar activities. In fact they are so familiar that we can carry them out automatically without having to decide how to do them. Our experiences have helped us to develop inbuilt patterns that we use over and over again. Now suppose you are listening to Rachmaninoff and the music suddenly becomes much too loud; or there are road works blocking your usual route to work; or there isn’t enough assam tea left in the tin to make your pot of tea. What do you do when the reality does not fit your pattern? You make some adjustments to tune the situation. You turn the volume down; you stop and have a look at a map to find an alternative route, you decide to risk mixing the remaining assam tea with some orange pekoe. We know how to tune situations in our everyday lives because we have patterns containing consistent variables that we understand and know how to adjust to. When managing a project we do something very similar.

An experienced project manager monitors the project’s actual behaviour against the expected pattern. When there is a variation then the manager tunes the project by observing one or more variables, analysing them and making adjustments to things like workload, task assignment, version content. The most useful variables for tuning a project are those that are:

• identifiable early in the project
• traceable throughout the life of the product
• reflect the real work that has been done

This is where requirements come in.

I am starting with the premise that your project is using a disciplined, consistent approach to defining requirements, both at summary and atomic level. Provided that this is true, then the project manager can use the requirements themselves as a tuning and decision making tool.

Early in your project

The requirements engineers do their first iteration by skimming across the top of the whole project. They are looking around at project’s landscape and identifying the boundaries and necessary depth of the investigation. This provides a number of requirements-related deliverables that the project manager can use:

With these quantified starting points a project manager has objective input for recognising changes and making change management decisions. For example, if you started with 30 business events and your team discovers 3 more then you need to adjust the project plan to cope with the 3 extra chunks of work.

During the iterations

Each of the above deliverables provides the starting point for doing iterative detailed requirements discovery and definition. As your team progresses into defining atomic requirements of various types (functional, non-functional, constraint and technological) the results of their work provide more input to your management decisions. Provided you have an agreed definition for what you mean by atomic requirement (this points back to the earlier point about consistency) then the project manager can use the deliverables to make project steering decisions without needing to ask endless questions about progress.

A suggested set of attributes for an Atomic Requirement are:

• Unique Identifier
• Requirement Type (Functional, Non-Functional, Constraint, Technological
• Connection to one or more Product Use Cases
• Description
• Rationale
• Source
• Fit Criterion (precise measure of the meaning of the requirement, used to quantify the requirement, as input to writing tests and to negotiating solutions)
• Customer Satisfaction and Customer Dissatisfaction (input to prioritisation decisions)
• Dependencies with other requirements
• Conflicts with other requirements
• History (creation, review status and any other indicators that you use in tracking where the requirement is in your own process)
• Supporting Materials

By looking at the state of the atomic requirements you can get answers to questions that help you to make steering decisions. For example you can ask specific questions like:
How many atomic requirements have been defined? How many of those requirements have precise measurements and have been though your business review process? How long did it take to get to this stage? Are there functionally related requirements (connected to the same product use case) that could be taken further towards implementation whilst other groups are still waiting for answers to requirements questions?
You can answer all these questions – and more – by looking at the requirements deliverables that your team has produced.
Of course you do not want to do this “looking” manually, and that’s where automated tools do the donkey work.

Traceability after the honeymoon

To achieve lifetime traceability you need a formally defined model of the knowledge that you are intending to trace. You can think of this as your requirements for managing your requirements. It serves as a specification for what you would like your requirements management tool to keep track of. This model should reflect the life of a requirement from the time it is discovered to the time that it is implemented in a released product. Hence your knowledge model needs input from all the stakeholders (business analysts, systems analysts, systems architects, designers, programmers, testers, marketers….to name a few) who are responsible for any of the transformations or packaging of the requirements.

Here’s an example of a generic knowledge model that is based on experience of many different projects. You can use this as the starting point for building your own model. Your own model will contain additional classes and associations especially in the marketing and implementation related parts of the model.

Once you have a model that reflects your traceability intentions, then you need the discipline – practised by the whole team – of maintaining the requirements knowledge as defined by your knowledge model. If your requirements are defined in this way then you have some major advantages: you have the basis for making decisions that are supported by precise measurements of the work that has been done, and the team has a model that guides their work by defining deliverables. Hence they are not enveloped in a procedural straightjacket and are able to respond to changes.