What are appropriate methods for determining the requirements of a project?

In this article, we will explore the definition of project requirements, why requirements are so important, and how to elicit, analyze, document, and validate requirements.

What are Project Requirements?

Stakeholders hear the term "requirements" but interpret the meaning in different ways. Before we can manage anything, it's critical that we have a working definition.

Requirement. Something that is needed or that must be done. –Merriam-Webster Dictionary

The Project Management Body of Knowledge, Seventh Edition defines requirement as "a condition or capability that is required to be present in a product, service, or result to satisfy a business need."

Karl Wiegers, author of Software Requirements, gives this definition: "Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute."

Requirement. A condition or capability that is required to be present in a product, service, or result to satisfy a business need. –PMBOK® Guide, Seventh Edition

Part of the confusion concerning requirements is that there are different types. The PMBOK® Guide, Sixth Edition classifies requirements as follows:

• Business requirements - describe why the project is being undertaken
• Stakeholder requirements - describe the needs of a stakeholder or stakeholder group
• Solution requirements - describes features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements
  • Functional requirements - describes the behaviors of the product
  • Non-Functional requirements - describes the environmental conditions or qualities required for the product to be effective
• Transition requirements - describes the temporary capabilities needed to transition from the current as-is state to the desired future state
• Project requirements - describes the actions, processes, or other conditions the project needs to meet
• Quality requirements - describes any condition or criteria to validate the successful completion of a project deliverable or fulfillment of other project requirements

Be sure to include the definitions you use in your requirements management plan.

Why are Requirements Important?

Imagine that you've contracted with a general contractor to build your dream house. You've been thinking about this house for years. As you have visited friends, you've made notes about what you like (and don't like) about their homes. Perhaps you have a Pinterest page where you've saved your favorite pictures.

So, you have your first meeting with the general contractor to discuss the requirements for your house. The contractor walks you through a checklist, explains your options and pricing. You specify the size of the house, the type of construction, the number of rooms, the types of systems, and the features of the home. You leave nothing to chance.

A week later, the contractor walks you through an interactive computer model of the home. You progressively refine your requirements. After a few more meetings, the contractor understands your needs. Guess what! The contractor has a much higher chance of meeting your expectations.

When requirements are vague, projects are at risk of not delivering what is needed. At a minimum, missed requirements result in rework. There will likely be adverse impacts to the schedule and to the budget. And your customers, as well as your team members, will not be happy!

How do we develop requirements?

How to Develop Requirements

In some projects, we can more easily define the requirements up-front. For others, we begin with a general understanding of the requirements and elaborate the requirements over the course of the project. Either way, we must elicit, analyze, document, and validate our requirements.

If you think someone will simply hand you the project requirements, you're in for a BIG surprise. Most people don't know what they want; they need help.

When requirements change, I see project managers point their finger and say, "the users never know what they want." While there may be some truth to this, I have always held the position that the requirements analyst – whether a project manager, business analyst or business lead – is largely the problem. Why?

A good analyst knows how to elicit—draw out—and validate requirements. I have made an observation after hundreds of projects. Skilled requirements analysts can greatly reduce requirement-related issues. If you are a project manager and you don't have the time or the requirement development skills, make sure you secure a skilled requirements analyst; otherwise, you are asking for problems.

Here are some elicitation tools and techniques:

• Brainstorming
• Nominal group technique
• Interviews
• Document analysis
• Surveys
• Requirements workshops
• Job shadowing
• Context diagrams

The word "analyze" means to break down or examine in detail the constitution or structure of something. For software projects, we break the requirements into greater detail as we move from business requirements to user requirements and further into the detailed system requirements. Once we've determined the details, we can synthesize the components together to meet the higher level needs.

Practically speaking, how do we analyze requirements? One of the most powerful ways is to build prototypes or create diagrams; it doesn't have to be complicated. When users see things, they can respond with what they like and don't like.

Another tool for analysis is a context diagram that visually depicts a product such as a building, process, or software application and how actors (individuals, groups, or other systems) interact with it. We can see the things that flow in and out of the process and who receives the outputs.

Some organizations prioritize requirements during the analysis. Which features and functions provide the greatest benefit? Which ones may cause the greatest risk? In agile projects, we can rank order the user stories in the product backlog.

In recent years, there has been a move to lighter requirements documentation and more collaboration, particularly for agile projects. There are benefits to documenting. As we document, we think and we analyze. It is also helpful to have a light version of documentation for reference as people extend the features and functions in future projects.

Business requirements are typically defined as goals in the project charter. User requirements are often captured in a use case or user story format. The detailed software requirements are often documented and captured in a requirements management tool.

Finally, we talk about requirements validation, how to ensure that the project requirements are correct, free of defects/bugs, and meets the needs of the users. Conduct validation meetings to review the requirements with a cross-functional team such as the BAs, developers, and testers.

Click here for details about requirements validation.

Once the team has reached agreement on the requirements, baseline the requirements with the appropriate sign-off process.

Where Do We Go From Here?

As you've read this article, you may have thought—this is a lot of stuff! Yes, it is. As with all project management processes, scale the requirements management processes to meet the needs of each project. Early in your project, think about your approach to requirements and create a simple requirements management plan:

What are the three types of project requirements?

What are steps in the process of identifying project requirements?

What is the fourth step in determining the requirements for a project?

What are the 5 stages of requirement gathering?