Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

Requirements Gathering 101

~ By Duncan Haughey

Manager passing a document to a colleague

Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. Requirements gathering sounds like common sense, but surprisingly, it's an area that is given far too little attention.

Many projects start with the barest headline list of requirements, only to find later the customer's needs have not been adequately understood.

One way to avoid this problem is by producing a statement of requirements. This document is a guide to the main requirements of the project. It provides:

  • A succinct requirement specification for management purposes.
  • A statement of key objectives - a "cardinal points" specification.
  • A description of the environment in which the system will work.
  • Background information and references to other relevant material.
  • Information on the primary design constraints.

The contents of the statement of requirements should be stable or change relatively slowly.

Once you have created your statement of requirements, ensure the customer and all other stakeholders sign-up to it and understand that this, and only this, is being delivered.

Finally, ensure you have cross-referenced the requirements in the statement of requirements with those in the project definition report to ensure there is no mismatch.

10 Rules for Successful Requirements Gathering

To be successful in requirements gathering and to give your project an increased likelihood of success, follow these rules:

  1. Don't assume you know what the customer wants - always ask.
  2. Involve the users from the start.
  3. Define and agree on the scope of the project.
  4. Make sure requirements are SMART - specific, measurable, agreed upon, realistic and time-based.
  5. Gain clarity if there is any doubt.
  6. Create a clear, concise and thorough requirements document and share it with the customer.
  7. Confirm your understanding of the requirements alongside the customer (play them back).
  8. Avoid talking technology or solutions until the requirements are fully understood.
  9. Get the requirements agreed with the stakeholders before the project starts.
  10. Create a prototype, if necessary, to confirm or refine the customer's requirements.

Common Mistakes

Be careful to avoid making these mistakes:

  • Basing a solution on complex or cutting-edge technology and then discovering that it cannot easily be rolled out in the 'real world'.
  • Not prioritising the requirements, for example, 'must have', 'should have', 'could have' and 'would have' - known as the MoSCoW principle.
  • Insufficient consultation with real users and practitioners.
  • Solving the 'problem' before you know what the problem is.
  • Lacking a clear understanding and making assumptions rather than asking.

Requirements gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide what the customer wants.

Download our free Website Requirements Specification

Comments (4)

Topic: Requirements Gathering 101
5/5 (4)
Full StarFull StarFull StarFull StarEmpty Star
24th July 2014 6:29pm
Stephen (London) says...
Great article, couple of questions though.

I downloaded your Website Requirements Specification document, but I wasn't sure about the difference between a few of the spec's groups i.e. the difference between Editing, Updates and Admin vs Editor Interface (CMS) vs Content Management.

It would be great if you explain the differences.

Full StarFull StarFull StarFull StarEmpty Star
24th July 2014 7:40pm
Duncan (London) says...
Hi Stephen,

Here is a brief explanation for each section:
  1. Visitor Interaction: what will visitors be able to do on this website? List all the activities they will complete while visiting.
  2. Editing, Updates and Administration: how will the website be updated? Define the process for adding new content and making editorial changes.
  3. Sitemap and Navigation: what is the structure of the website? List the sections and content categories of the website.
  4. Content Management: how will content be managed on a day-to-day basis? Is there a need for a Web Content Management System?
  5. Tracking: what are the reporting needs of the website? Define a list of Key Performance Indicators that stakeholders and other interested people need.
  6. Search Engine Optimisation: how will the website be 'promoted' in organic search results? List the items and activities to enable this, such as, a unique title and description tag on every page.
  7. Editor Interface: how will editors update website content? Define the editor environment and everything required to allow editors to do their job.
  8. Accessibility: how will people with special needs use the website? List the requirements to allow access by screen-readers etc.
  9. Styling and Design: what is the look, feel and brand of the website? Identify the broad styling and design considerations.
  10. Security: what will be in place to make sure the website is secure and safe for visitors to use? List all security considerations.
  11. Hosting: how will the website be hosted? Identify the type of hosting (cloud or physical servers) and the site (own hosting or third-party).
  12. Maintenance and Support: what are the requirements for supporting the website? Define the time periods and level of support needed, including disaster recovery and service continuity.
  13. Other Requirements: list anything not covered in other sections of the document.
  14. Exclusions: anything that will not be delivered as part of this project.
  15. Considerations: list anything that needs accounting for as part of this work and any constraints that may exist.
  16. Assumptions: list any assumptions made about the proposed website.
Hope this helps.

Full StarFull StarFull StarFull StarFull Star
26th May 2014 5:42pm
Dalex says...
A nice description of requirements gathering. At the same time, the statement of requirements is not enough to ensure success of the project.

Stakeholders need to be taken thru a set of requirements starting from the product capabilities, quality and the ability to be embedded into the existing enterprise infrastructure. As for baselining of the gathered requirements, well, the only high-level requirements are stable, more granular requirements will become stable after having the product design completed. Here it is possible to get the full support of stakeholders and their sign-off.

And a question to Duncan: how does the statement align with the PR2 context?
Full StarFull StarFull StarFull StarFull Star
26th May 2014 10:50pm
Duncan Haughey (London) says...
PRINCE2 doesn't provide any guidance for requirements gathering. Requirement gathering is part of Business Analysis and goes through the following stages:
  • Requirements Gathering
  • Requirements Elicitation
  • Requirements Management Plan
  • Requirements Analysis
  • Requirements Traceability
  • Change Control
Within the PRINCE2 framework, your requirements approach and requirements will be defined during the initiation phase with the following pm artefacts feeding into it:
  • Project Approach
  • Business Case
  • Communications Plan
The requirements feed into the following pm artefacts used during the execution phase:
  • Work Packages
  • Configuration Items
  • Product Description
  • Product Flow Diagram
The requirements analysis might be carried out by the Project Manager or for larger projects a Business Analyst.

Add a comment

(never displayed)

Enter the word radio backwards.
Notify me of new comments via email.
Remember my form inputs on this computer.

Writing the Project Statement of Work

White note reading Statement of Work

The Statement of Work, or SOW, is the bible for the work your project must produce. So how do you go about writing one for your project?

The Role of a Business Analyst

A young businessman is sitting at a polished table attentively reading a document

This article examines the multifaceted role of the Business Analyst and gives a depiction of the duties and skills required to embark on such a career.

Reduce Project Risk in the Requirements Process

Business people gathered around a table for a brainstorming meeting

Gathering and managing requirements are important challenges in project management. Projects succeed or fail due to poor requirements at any time throughout the project lifecycle.

The Elements of a Good Feasibility Study

Red feasibility study stamp on a white background

This article discusses the fundamental components of a Feasibility Study from project scope to final review.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.

Latest Comments

Allana commented on…
12 Tips for Being a Good Manager
- Tue 5 January 8:30pm

George Bockius commented on…
Better Coaching Using the GROW Model
- Thu 24 December 3:55pm

Al commented on…
Better Coaching Using the GROW Model
- Tue 22 December 10:07pm

Latest tweets

General Project Management • Query on PMP Numericals about 5 days ago

General Project Management • Problems With Project Planning about 5 days ago

General Project Management • IT project management phrases - 10 terms you need to know about 12 days ago