Our Articles

A Monthly Article from our Speakers

Current Article of the month

Articles of 2017

Articles of 2016

Articles of 2015

Articles of 2014

Articles of 2013

Articles of 2012

Articles of 2011

Articles of 2010

Articles of 2009

Articles of 2008

Articles of 2007

Articles of 2006

Articles of 2005

Articles of 2004

Articles of 2003

Articles of 2002

Suzanne RobertsonRequirements 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:

Requirements Deliverable Measurables Decision Making Input
Stakeholder Analysis Number of stakeholders, roles and knowledge expectations Input to sociological complexity estimate and knowledge gap analysis
Project Goals Purpose and expected Business Advantage of doing the project and Measure of target state Input to value analysis, prioritisation decisions and change management choices.
Investigation Scope Number of inputs and outputs bounding the investigation Input to first-cut estimate of functional complexity
Business Event List Number of bounded functional chunks Input to task design and allocation, to risk analysis and to estimate of time/resources needed for discovering requirements for each event
Product Scope – ability to do this depends on whether the product constraints have been defined First cut estimate of the number of interfaces between the planned product and users and other products Input to planning early prototypes and simulations

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.

Upcoming events by this speaker