Project Requirements

Posted on 17th December, by JimYoung in Blog. Comments Off on Project Requirements

“But you were supposed to…” “Oops I wanted…” “I thought…” “But that’s not what I said…” “Can you just…” “While you’re on the job…”

Requirements can be one of the biggest problem in projects. They drive the project scope. Get requirements wrong and everything we do after that is pretty much doomed. Without the right effort in gathering, documenting, agreeing and keeping to requirements, we won’t deliver the thing that our client wants, and in most cases, we won’t then get paid and we won’t be asked back. The requirements gathering process happens way before the project plan is put together. Requirements are a basis for the project product or service specifications. Requirements are based on stakeholders needs and describe what the finished product or service will do, whereas specifications are typically a more detailed and explicit technical explanation that show how the requirements will be achieved – what the deliverable will do.


Defining requirements means figuring out what is needed before we start to make it, keeping in mind that the end product should suit the needs of the client rather than the client suit the product. Requirements serve three important functions:

  1. They establish a consensus and common ground amongst project stakeholders and participants.
  2. They quantify expectations into specific needs.
  3. They form the basis for project product and service specifications.

Every project is created in response to a business need.  Requirements analysis is the process of discovering, analysing, defining and documenting the project requirements. For larger more complex projects this job is often done by a business analyst (BA) who communicates with stakeholders, gathers requirements, and makes sense of these requirements in order that the end products will solve the business problem, opportunity or compliance at hand. In essence, project managers are responsible for delivering the solution to the problem, whereas business analysts are responsible for discovering the problem and determining the solution. When a project manager and a business analyst are both present on a project team, the project manager can focus their efforts on project schedule, cost, resource and risk management, and the business analyst can spotlight their time and energy on ensuring accurate requirements management —both critical roles for a successful project.

Thus, requirements analysis is the process by which we clearly define the scope of the project, so that we can assess the work effort and resources needed to complete it. Defining requirements identifies the capabilities, features or attributes of the project’s deliverables.  Stakeholder needs, wants and wishes are analysed to derive these requirements.  Requirements are prioritised to determine which requirements will be included and excluded from the project.


Some project managers are directly involved in determing requirements and some are not. In either case, it is not uncommon for project managers to underestimate the complexity of business analysis work. A good business requirements analysis leads us to better understand the business needs and helps produce detailed, specific requirements that everyone agrees with. And it’s much quicker and cheaper to fix a problem or misunderstanding at this analysis stage than it is when the “finished product” is delivered. Many projects start with the barest headline list of requirements, only to find later the clients’ needs have not been properly understood. The requirements definition is a continuous process of fleshing out and refining the baseline description of the project deliverables. Below is a seven step guide to conducting a business requirements analysis.

Step 1: Identify the sponsor

We start by clarifying exactly who our project’s sponsor is. This may be an internal or external client. Either way, it is essential that we know who has the final say on what will be included in the project scope, and what won’t. Of course our sponsor who holds the purse strings may not be the real customer who is more likely to be the product user. To manage project requirements correctly, we need to convince our sponsor to allow us or a business analyst sufficient time to gather these requirements and that a few days or even weeks spent gathering requirements at the front-end is worth it because we won’t have the wasted time and cost of continuously adding requirements later during our project’s life span. The later we add or change requirements the more expensive the project becomes, particularly if such changes occur during the project execution phase or even after project finish.


Step 2: Identify the stakeholders

Now we identify the key people who will affect the project or will be affected by the project including those who will use the final deliverable – solution, product or service. End-users are those people that our project is intended to satisfy. We must determine a communications strategy for engaging with our stakeholders. We will need to build bridges to the stakeholders, and will ideally be able to establish at least one face-to-face meeting with each stakeholder, and ideally at least one collective meeting with all stakeholders. We develop a list of questions, organised around various facets of the problem to be solved by the project. This list should provide clarification to both ourselves and the stakeholders on the issues to be addressed. Make sure they address a clear understanding of the problem, as opposed to specifying a solution. Vet the questions with the team and with our project sponsor. A preliminary stakeholder analysis using a template with the following headings may be useful preparation for face-to-face stakeholder meetings:



Step 2: Analyse stakeholders

Stakeholder analysis is the technique used to identify the key people who have to be won over, which is important because:

  • – We can use the opinions of the most powerful stakeholders to shape our project at an early stage. Not only does this make it more likely that they will support us, their input can also improve the quality of our project.
  • – Gaining support from powerful stakeholders can help us to win sufficient resources – this makes it more likely that our projects will be successful.
  • – By communicating with stakeholders early and frequently, we can ensure that they fully understand what we are doing and understand the benefits of our project – this means they can support us actively when necessary.
  • – We can anticipate what people’s reaction to our project may be, and build into our plan the actions that will win their support.

Step 3: Elicit stakeholder requirements

The sooner we start to engage with the project’s stakeholders the better. They may not be so co-operative if our first engagement with them is during project implementation. We know that for our projects to succeed and for us to get the information we need to build our end-product, we need good requirements. To get good requirements, we need to ask the right questions. The only way for a project to obtain comprehensive, correct and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them. Determine how much time will be needed for the project requirements gathering and prepare a schedule for the necessary meetings.


We now need to ask each of these key stakeholders, or groups of stakeholders, for their requirements for the new product or service. What do they want and expect from our project? When interviewing stakeholders, we need to be clear about what the basic scope of the project is, and keep our discussions within this. Otherwise, end-users may be tempted to describe all sorts of bells and whistles (ie, feature creep) that our project was never designed to provide. If users have articulated these desires in detail, they may be disappointed when they are not included in the final specification.

We can use several methods to understand and capture these requirements. Here are four techniques that may be used in combination:

  1. Using stakeholder interviews. Talk with each stakeholder or end-user individually. This allows us to understand each person’s specific views and needs.
  2. Using focus groups. Conduct group workshops, remembering it’s a good idea to keep asking “Why?” for each requirement. This may help us eliminate unwanted or unnecessary requirements.
  3. Using case studies. A scenario-based technique lets us walk through the whole system or process, step by step, as a user. It helps us understand how the system or service would work.
  4. Building a prototype.       Build a mock-up or model of the system or product to give users a proper 3D feel of what our final product will look like. Using the prototype, users can thoroughly evaluate the product, and help identify any inconsistencies and possible problems. As a result of feedback there may be a second and improved prototype and so on.


The big challenge is to get all stakeholders, end-users and project teams on the same page in regards to the requirements.

In the case of a new commercial product, market research is usually needed. Such research can be a project in its own right when we identify the key factors that matter to customers – showing us what to focus on. For example, market research can help us assess how much customers might be willing to pay for new product features. Research can also be used to test other aspects of product design, such as product packaging or names.

Step 4: Categorise requirements

Requirements may vary by project type and circumstance, but may be quantified according to four categories:

  1. Functional Requirements: Determine the appearance, features and operational functionality of the project deliverables.
  2. Technical Requirements: Determine the technical elements of the project deliverables, including design specifications, operational requirements, and performance requirements.
  3. Business Requirements: Determine overall project goals and vision, including business goals, objectives, productivity expectations, return on investment and payback requirements.
  4. Process Requirements: Determine the project process requirements, governing the way that the project is to be managed, including project management policies, procedures and best practices.

Four tests to help ensure sound project requirements are:

  1. Make sure requirements are clear, concise and measurable.
  2. Validate each requirement by removing it to assess its effect on the project.
  3. Have other people read the document to validate that everyone comes to the same conclusions.
  4. Make sure that there is a direct link between each requirement and the project.

Step 5: Interpret and record requirements

Once we have gathered and categorised all of the requirements, we then determine which requirements are achievable, and how the project product can deliver these. The process is:

  1. Define requirements precisely. We ensure that the requirements are not ambiguous or vague, but clearly worded and sufficiently detailed so that everything is known. (Project over-runs and problems usually come from unknowns that were not identified, or sufficiently well-analysed.)
  2. Prioritise requirements. Although many requirements are important, some are more important than others, and budgets are usually limited. Therefore, identify which requirements are the critical, and which are “nice-to-haves”.
  3. Analyse the impact of change.       Here we check the consequences our project will have for existing processes, products and people.
  4. Resolve conflicting issues.  Now we sit down with the key stakeholders and resolve any conflicting requirement issues. Trade-offs may be negotiated.
  5. Assess feasibility. Determine how reliable and easy-to-use the new product or system will be. Such a check can help identify any major problems or risks.

A particularly effective way for prioritising requirements is to complete a paired comparisons table. For example, the office needs a new photocopier, so we canvas the users for their needs and then prioritise them as shown in the following completed example:


There may of course be more than 10 requirements in which case the table would need to be expanded. The “Score” is the number of times that the requirement is identified throughout the matrix. As a check, the total score will be 45 for 10 items. That is, Total Score = {(Number of Items) x (Number of Items – 1)} / 2. If requirements have the same score we may distinquish between their importance by checking the result when these two requirements are compaired. For example, requirements 1 and 9 both scored 3, however, when these two requirements are compared, requirement 1 is of greater priority. Once features and functions are prioritised, they may be costed. Budget limitations or cuts would normally see requirements progressively removed – least important first. Requirements elicitation may result in too many requirements and we may need to eliminate some features that don’t add sufficient value.

Once we’ve gathered, documented and prioritised the project requirements, we need to check that we’ve truly understood them and that they accurately reflect the understanding of our key stakeholders. We go about this by locking ourselves in a room with those people, and staying there until we’ve got a common understanding of every single one of the requirements, and an agreement on exclusions. Now we put the requirements document in front of our sponsor, and get him or her to sign it. We sign it too. It’s a contract and any changes to it will likely affect the project’s cost, schedule, risk profile and ultimate benefits realised during the product life.

Once everything is analysed, we might present our results and a detailed report of the business needs. Circulate this document among the key stakeholders, end-users, and development teams, with a realistic deadline for feedback. This can help resolve any remaining stakeholder conflicts, and can form part of an agreement between ourselves and the project stakeholders.

Step 6: Agree how to manage change

Requirements may change as our project develops, and as needs and circumstances dictate. These changes can arise from new ideas, new information, new technology, new perspectives, changes in regulations or budget cuts and are often requested by project customers (ie, our end-users).  Thus, before sign off on the base requirements we need to agree the change procedure and criteria for change request acceptance or rejection. Requirement changes should be kept to a minimum, and only as needed, and to ensure that requirement changes are evaluated appropriately, change requests should mention the specifics of the change, the reason for the change, and the likely impact of the change on the project budget, schedule, benefits and risk profile.


Once change requests are submitted, reviewed and approved, the changes must be incorporated into existing project plan. Plan version control is therefore important.

Step 7: Sign off

The final requirements will be the basis of all the planning we will do for the project. So getting them definitively agreed and not subject to interpretation by clients is essential. We must produce documentation that is clear and concise, using graphics, models and other visuals if it helps clarify what we mean. Our documentation must also be detailed enough for anyone else to plan the project and start work on delivering the requirements. And make sure we get the signed agreement of key stakeholders, or representatives of key stakeholder groups, saying that the requirements reflect their needs. This formal commitment will play an important part in ensuring that the project does not suffer scope creep. The result of all this is that we’ll have requirements that are understood by everyone, are agreed to by everyone, are documented such that there is no room for arguments, and are the basis for the accurate project planning.   The further along the project is in its life cycle the more costly it becomes to correct errors. Boehm’s Curve shows us that the cost of correcting a requirement error increases exponentially as the project matures.


I know starting the real work on the project is tempting. It may even be possible – if it’s a small project. But if our project is of any significant length, complexity and cost, then we must have genuine project requirements. These requirements must be detailed enough to design and build a solution, and complete enough for us to avoid making wrong assumptions that result in expensive and time-consuming rework later on during our the project.

Comments are closed.


My latest thoughts on Project Management and life.


My big thanks to the coronavirus lockdown that provided me with an undisturbed opportunity to put together this 104 page booklet on Earned Value...

Project Estimating Checklist

Hofstadter’s Law: “It always takes longer than you expect, even when you take into account this law.”

Hofstadter was right....

Earned Value Management Misconceptions and Limitations

Although EVM offers excellent benefits, and is undoubtedly a very clever thing, it’s not perfect. In this final chapter I’ve discussed in detail a...