Skip to content


  • Add this article to your LinkedIn page
  • Add this article to your Twitter feed
  • Add this article to your Facebook page
  • Email this article
  • View or print a PDF of this page
  • Share further
  • Add this article to your Pinterest board
  • Add this article to your Google page
  • Share this article on Reddit
  • Share this article on StumbleUpon
  • Bookmark this page

Finding the right path through the Requirements’ labyrinth

By Simon Duke and Peter Durant, PA business analysts and technologists

Simon Duke and Peter Durant from PA Consulting Group, are experienced business analysts and technologists. From their collective experience developing products, defining business strategies and supporting complex procurement activities they have developed a set of best practice guidelines which should be considered throughout the lifecycle of a project’s requirements.

Without clearly defined requirements, it’s difficult to know whether a process, service or product – whether it’s being developed or procured – will meet your customer’s needs. Developing requirements is a complex process because it involves managing the demands of multiple stakeholders and aligning objectives that may conflict.  In the attempt to achieve these goals it can be all too easy to create complexity and to set expectations that cannot be met – which may make it impossible to fulfill your customers’ requirements without spending too much on development or procurement.

To avoid creating complexity and inflating expectations, you need to generate effective requirements that are trusted by all interested parties, and then encourage all parties to live by the requirements through to the end of delivery. 

The following practices have been learned through years of experience in developing tens of thousands of requirements on difficult and challenging assignments, and we recommend that you consider them as you embark on your requirements definition.

Continuously engage with all of your stakeholders

From ‘why are we doing this?’ to ‘why didn’t you ask me earlier?’ you can expect to face questions as you work to define the requirements for your project. However, by ensuring all parties are engaged and on-side from the outset, you will pave the way for a much smoother journey.  Start with the following preparations:

  • Set expectations about the extent to which people will need to engage in the development of the requirements. How much time will be needed for interviews? Who will be expected to review requirements as they develop? Plan early and make sure people stick to the agreed dates and time commitments.
  • You may not know who all your stakeholders are at the beginning. Reach out to people who are not directly engaged or giving you requirements, as this will provide new insights and different views that will help your requirements to be accepted more widely within the organisation.
  • Listen carefully to people’s opinions and understand their position as this usually diffuses any potential tensions and dispels the concerns they may have. 
  • Provide regular information-sharing sessions and updates on progress. Without these, requirements can be mysterious to many people, and the value of what is often an extensive piece of work can be unclear to them – and that in turn may lead them to question the necessity of the work, or their need to be involved. 

Taking these steps will help you to improve stakeholder buy-in, which in turn will help to ensure that your requirements are signed off quickly and not delayed by conflicting expectations.

Get the source information right

When you’re seeking requirements sign-off, the sources of information for each requirement are likely to come under close scrutiny. You need to know how to show that you have obtained the right information and present the trail in the best format for your audience. Here are a few guidelines:

  • Agree with your stakeholders the sources of information that will inform the requirements, whether these are existing documents, customer focus groups, service blueprints, etc. If necessary, agree up front how potential sources will be identified, and how you will decide which sources will be used and which won’t.  This will help to prevent surprises and re-work later.
  • You should also agree with your stakeholders how you will go about extracting requirements from sources (eg verbatim, or adapted in some way). Be especially careful if you are starting with previously constructed requirements: these will need to be carefully validated.
  • Keep a formal traceability log of all source references for each requirement and decision (eg meetings, people, documents – including detailed reference information such as title, version number, page and paragraph numbers within source documents). You’ll be grateful months later, when you need to trace where that one ‘problem’ requirement originated from.

Getting the source information right benefits your programme by creating proper and thorough traceability – you can then spend your time increasing the quality of your requirements, not debating whether they came from appropriate sources.

Use the right tools and formats for the job

To save time and increase agreement, it is crucial to find a presentation format that your early reviewers like working with.  Formats do matter: technical and business reviewers may prefer different presentation formats, and this can cause problems if not resolved early.  Re-work to change from one format to another is frustrating and time consuming, and manually maintaining up-to-date requirements in multiple formats is not practical. We recommend:

  • Consider the tool you will use to capture and present your requirements, and how it can help manage both traceability and cross-referencing as the number of requirements and sources grows.  This could be a dedicated requirements software tool such as Cradle, Doors, Artisan or Jama; or it could be as simple as a custom-built spreadsheet. 
  • Be pedantic about use of consistent language and terminology and make the requirements unambiguous, specific, measurable, and relevant to the customer’s objectives.  Accept that requirements will change and maintain scrupulous version control when they do.
  • Order the requirements so they tell a story, or take the reader through in a logical way. This will help suppliers understand the needs and position them to respond more effectively.
  • Don’t use requirements to define what the systems’ goals are or how it is to be implemented.   Avoid specifying solutions as you write the requirements. 
  • Keep each requirement discrete and testable: don’t amalgamate multiple requirements into one large requirement. This will enable you to create requirements so that they support verification and validation later in the programme (for example, if a systems engineering approach is used).

Using the right tools and formats will make requirements analysis easier, support your work with reviewers, and save you time and effort down the line. It’s not an exciting aspect, but one that you should seek to get right from the outset.

Bring requirements to life throughout the project

With supportive stakeholders and approved requirements, success will be within your grasp. At the analysis stage of your project, however, requirements risk becoming ‘that thing you did at the start of the project because you had to’ and your stakeholders can easily forget the broader aim that requirements support.

To avoid losing the value created so far, requirements should come to life as the project continues. Taking some simple steps can help you to achieve this:

  • Trial your approach and test its acceptance. It’s worth piloting the approach you have in mind, for example in a smaller area of functionality and using different potential tools, to fine-tune how you go about requirements analysis before committing to the whole piece of work. Doing so will give you precious feedback from stakeholders, and help them get – and stay – involved.
  • Consider repeating your trial if there are changes in scope, influential stakeholders, or available tools. 
  • As the project moves on, some of the sources that provided requirements might change, and these in turn may impact your requirements; so you need to have a way of keeping track of such changes and ensuring your requirements are considered and updated accordingly. This can be time-consuming if relying on multiple sources across the business, so consider in advance – when you first use a source – how you can do that.
  • Aim to deliver a usable set of requirements. It’s better to start with a small area, and prioritise expanding to others, than to try to do everything at once.

The benefits of ‘living requirements’ are often felt well into the lifetime of a project: less rework, faster delivery and easier change control. You will benefit considerably from the effort you put into bringing requirements to life.

In summary, requirements development demands outstanding stakeholder management and networking skills, combined with an ability to manage and track a myriad of details; but at the same time you cannot afford to lose sight of overall goals and strategic needs.  We hope that the lessons we have learned over the years, and set out in this short paper, will give those of you relatively new to this type of work some useful tips, and will be a helpful reminder to readers who are more experienced.

If you would like further information or would like to discuss any of the points raised, please contact us now.