A column of boxes with ticks in them showing good project requirements
Project managementRequirements Management

How to help your project succeed with good requirements

Psoda blog author avatar
4 December 2018

Capturing project requirements is what I call a swan task. On the surface it looks really easy and not much effort but underneath is a heck of a lot of work. It’s also one of those jobs that if it isn’t done properly it will have a significant negative impact on your project. Normally by the time it’s discovered it’s too late to do anything about it without major time and cost impacts.
Before we get start, it’s important to understand what a requirement is and the differences between types of requirements.

What is a requirement?

A requirement is a single documented physical or functional need that a particular design, product or process must be able to perform. Note the emphasis of single; I’ve lost count of the number of requirement documents that have multiple needs listed as one requirement. If you have multiple needs in one requirement it makes it almost impossible to ensure that all the requirements are met in the final product. Whether it is a piece of software, a bridge or a power station.
Requirements are normally categorised into two distinct types – functional and non-functional.

So what’s the difference?

Functional requirements describe what the product should do while non-functional requirements describe success criteria.
For example:
A functional requirement for a software system might be that if a person registers for an account, the system will automatically send an email to the creator.  A functional requirement for a power station might be the level of power that it can generate at a given time.
A non-functional requirement for a software system might be that it has to have an up time of 97%.

How to capture good project requirements

The process I’m about to outline looks like a lot of work, but it can be tailored to meet any size and type of project. Also, each step can be as detailed or as high level as you need. The objective is to ensure that you get as detailed and accurate a set of requirements as possible. This will minimise pain later on in the process. This process can be used with both agile and waterfall methodologies. The only thing that changes is the level of detail at each step.

Identify your stakeholders

This list of people should be more than just the users and developers of the solution. It should include representatives from all areas of the business that are likely to be impacted by the potential solution. It can also be useful to get senior management involved at this stage.

Gather requirements

Requirements can be captured in any number of ways and there is no right or wrong way to do this. Your particular project methodology will determine the level of detail required. For example, a standard waterfall development will require extremely detailed requirements. An agile methodology will not, as the requirements will be refined at each review cycle.
Regardless of the method used, it’s worth developing a standard template to capture the information. That way you are sure the information is in a consistent format and that it is as detailed as possible.
Whichever way you capture requirements, it is best to be as collaborative and open as possible. A series of requirements gathering workshops is normally the most efficient way of doing this. If you do choose this route, make sure that there is someone in the room whose sole responsibility is to be the scribe. This will make sure you don’t lose important information.

Documenting requirements

When document the requirements, it is worth capturing them in a central repository, whether it is a document or some type of requirements database.
Some organisations still use manual processes for requirements management. While they have their place it is far better to automate this as much as possible to ensure requirements are not overlooked or updated as things (inevitably) change.
They key outputs of this process are a requirements document (or database) that all stakeholders agree with and a requirements traceability matrix showing all the relationships and dependencies between the requirements.

Requirements feasibility

Once all the requirements have been defined, it is time to assess their priority and feasibility. You can use a number of different techniques to analyse requirements. They include:

  • Mandatory and Optional
  • Ranking
  • Value Analysis
  • Requirements Risk Analysis
  • Kano Analysis (delighting the customer)
  • Stakeholder impact analysis
  • PERT Analysis (Sequencing)

The most important part of this process is to determine the costs of each requirement and compare that to the cost of how things are currently being done. If nothing is in place then compare the cost of doing nothing.
The key output of this process is a signed-off, prioritised list of requirements and a draft budget.

Design & build the solution

Now you have a full set of requirements and a budget, it’s time to design the solution. At this point the requirements manager’s role becomes more about overseeing and monitoring the design to ensure all of the requirements are incorporated correctly. At this point you will really begin to benefit from an automated requirements traceability matrix.
The key outputs of this process will be a detailed design, any applicable interface specifications and more a more accurate breakdown. The design process may also uncover additional (more detailed) requirements or may identify requirements that are unfeasible.

 Test the solution against the requirements

At this point the test team get the original requirements so that they can build their test cases against them. This is where you really need to have good requirements traceability. As requirements are tested and functions change, it is important to ensure that the original requirements are not diluted or lost, as this can have a significant impact on the benefits of the solution.

I’ve spoken about traceability throughout this post, so what exactly is traceability of requirements?

At its simplest, traceability allows you to find your way around your project information. For example, one high-level requirement may be broken into a number of detailed requirements. Traditionally the high-level requirement lives in a different document to the detailed requirements.
To keep the relationship, or traceability, between these requirements, you need to have some type of connection or trace between them. If you don’t have a requirements management tool you could do this by adding a column showing the high-level requirement associated with each of the detailed requirements in the detailed requirement specification.
The main reason for having solid traceability in place is because when things change, you can quickly find everything that will be impacted by that change.

So what happens when things, inevitably, change?

What happens when things change and your customer changes their mind about some of the high-level requirements half-way through the project and you don’t have a traceability matrix?
If you’re running an agile project and haven’t analysed those specific requirements yet, then you’re ok. But it’s more likely they will change their mind about the requirements you’ve already done detailed analysis for and that you have the design and test-cases written for.
In this case you will have to trawl through every project document trying to find all of the derived requirements, designs, test-cases and other project artefacts and then update those to reflect the changes to the higher-level requirements. But updating the derived requirements may impact other requirements, designs, test-cases, etc. again. You then have to start again and find those secondary impacted items and update them accordingly.
This process will have to be repeated until you’re sure that all the possible implications of the high-level changes have been identified.
A traceability matrix makes this whole process easier. Psoda takes it one step further by automating the traceability matrix. If one requirement changes Psoda automatically shows you all the other requirements and test cases which are impacted.

Build a traceability matrix

So how do you create a traceability matrix?
First, place all of your requirements along both axes of a table. Then mark the relationship between each requirement – like the diagram below
Screenshot of a traceability matrix
Using SEC_01.1 in the matrix above as an example, to show that requirement SEC_01.1 is derived from requirement SEC_01 you do the following:

  1. Find the row with SEC_01 in the left-hand column
  2. Follow that row to the right until you find the column with SEC_01.1 at the top. In that cell you place and arrow to show the relationship or trace

You now have the beginnings of a traceability matrix.
To find all the requirements that are derived from a single high-level requirement all you need to do is find the row for the high-level requirement and follow it to the right. Each cell with an arrow in it will indicate a derived requirement.
What about finding any high-level requirements which have been forgotten and do not have any detailed requirements defined yet? It gets interesting if your requirements live in different documents. You’d end up having to make a checklist of all the high-level requirements. Go through each of the detailed requirements and tick off all of the high-level requirements that have detailed requirements defined for them.
With the traceability matrix it is a simple matter of finding any rows that have no arrows in them at all. In the image above, you can easily see that SEC_03 has no derived requirements. Psoda, automatically colours the row rose to highlight that this requirement has no derivatives for it. Alternatively, you can easily find requirements with no determinants or parent requirements associated with them. Just look out for columns with no arrows in them. Once again, Psoda automatically highlights these columns to make it easier to spot them.


Of course you don’t have to stop with requirements. Depending on the type of project you are running, you may be creating test-cases to test the functionality as defined by the requirements. In this case you want to extend the traceability matrix to include those test-cases. The test-cases are identified with a TC_ prefix in the image above.
The same principles we have just discussed regarding requirements now also applies to the relationship between requirements and test-cases. For example, to find any requirements that do not have test-cases derived yet, you just find rows with no arrows underneath the test-cases in the matrix.


In this blog post we’ve covered the basics of requirements management, walking you through a process that can improve requirements capture and traceability. Keep in mind when you begin your requirements management process, that all this effort is directly linked to your project’s success. We’ve written another blog on requirements management that’s worth a read. You can find it here. We’ve also got a great video on our YouTube channel on requirements management as well. You can check that out here.

Psoda plug

If you’re looking for a way to seamlessly manage your requirements, sign up for Psoda’s free trial and start clearly visualising requirements traceability through the entire lifecycle of your project.

Rhona Aylward avatar
Written by Rhona Aylward
Rhona is Deputy Everything Officer at Psoda, where she does everything except code. After starting life as a microbiologist she moved into PMO leadership roles around the world before settling in New Zealand with her family.

Leave a Reply

Your email address will not be published. Required fields are marked *