Requirements Fundamentals: Process Stages, Levels, Types

In this lesson you will learn about the four roles that collaborate in the requirements development initiative, the responsibilities of each role, and common job titles of people who perform the roles.

In this lesson, we are going to:

• Define the Requirement Producer role

• Identify common activities that the Requirement Producer is responsible for

• Identify job titles, or other roles, of people that frequently perform as Requirement Producer

In this lesson, we are going to:

• Define the Requirement Supplier role

• Identify the responsibilities of the Requirement Supplier

• Identify job titles, or other roles, of people that frequently perform as Requirement Suppliers

Naturally, if there is a group of Requirement Suppliers, there is a group of Requirement Receivers. In this lesson, we are going to:

• Define the Requirement Receiver role

• Identify the responsibilities of the Requirement Receiver

• Identify job titles, or other roles, of people that frequently perform as Requirement Receivers

Last, and certainly not least, is the role of the Requirement Supporter.

Similar to the organization of the previous lessons, in this lesson, we are going to:

• Define the Requirement Supporter role

• Identify the responsibilities of the Requirement Supporter

• Identify job titles, or other roles, of people that frequently perform as Requirement Supporters

In this training module, we explored four roles that collaborate in the requirements management process.

In conclusion, if you are watching this training video, it is because you have been asked to perform one or more of these roles and are expected to collaborate with others to development good requirements.

In this lecture, we'll look at the definition of "good requirements."

Since we are embarking on a journey to develop good requirements, we should survey the territory that we must navigate through. Requirements are grouped into three distinct levels referred to as the Requirements Hierarchy, and they are:

• BUSINESS – which are high-level requirements that convey the objectives of the organization, customer or client who requests the system

• USER – which are requirements that convey the roles that will be interacting with the system, and the goals that the users want to achieve through interaction with the system

• SYSTEM – which are requirements that convey what the system must do to enable the users to perform their business functions, and how well the system environment supports the users

In the previous module, we defined the three levels of the requirements hierarchy. While the levels of requirements guide the direction for your approach to applying the requirements management process, the types of requirements help to articulate and represent the requirements consistently across multiple projects and diverse stakeholders.

Described briefly, the four types are as follows:

1. Business requirements describe the purpose of the project, including measurable business benefits for doing the project, and state the expectations for what the project team is to deliver.

2. User requirements describe the user goals or tasks that the users must be able to perform through interaction with the system being developed.

3. Functional requirements describe functionality that must be built into the system to enable the users to perform their goals or tasks.

4. Nonfunctional requirements describe the system environment or characteristics of the system. They describe constraints imposed on the design and construction of the system, as well as quality attributes related to the users’ experience while interacting with the system.

Focusing on one requirement type at a time, in the following lessons we will explore:

• How the requirement type aligns with the requirements hierarchy

• The stakeholders engaged in developing the requirement

• Example questions used to elicit the requirement

• Suggested sentence formats for representing each type

A business requirement is defined as a statement that describes WHY the project is being done, and WHAT the project team is expected to accomplish.

Let’s begin this lesson by defining the user. In the context of this training and an emphasis on software requirements, a user is anyone who affects or is affected by the system under development. This definition includes people and things, such as machines, computers, and external systems, that interact with the system, as well as other people and things that receive by-products such as information and materials from the system. In other words, a user is anyone or thing that provides inputs to the system and receives outputs from the system.

In Module Four on the Requirements Hierarchy, I presented a discussion on the system-level requirements and stated that the focus of the system level is on two aspects. First, WHAT the system does to fulfill the user needs, which are captured in functional requirements. And, second, HOW WELL the system environment supports the users, which are captured in nonfunctional requirements.

Once again, in Module 4 on the Requirements Hierarchy, I stated that the focus of the system-level requirements is on two aspects. First, WHAT the system does to fulfill the user needs, which are captured in functional requirements. And, second, HOW WELL the system environment supports the users, which are captured in nonfunctional requirements. We explored functional requirements in the previous lesson. Now, we will turn our attention to nonfunctional requirements.

First, I should warn you that I have a bit of a passion for this type of requirement. Not because they are sexier than the other three. Rather, the fact that they are too often ignored and overlooked when defining requirements for a product or system, yet the need to define them is vital to the success of a development effort.

Although I have a lot that I could share about nonfunctional requirements, I’ll refrain, for now, and aim to summarize the topic here. Of course, if you’re interested in learning more, I encourage you to read my book, The Quest for Software Requirements, in which a majority of the chapters are devoted to defining and exploring nonfunctional requirements.

Simply defined, a nonfunctional requirement is a specification of HOW WELL a software system must function.

For each of the four requirement types, we looked at the following:

• How the requirement type aligns with the requirements hierarchy

• The stakeholders engaged in developing the requirement

• Example questions used to elicit the requirement

• Suggested sentence formats for representing each type

• A few examples of written requirements

The requirements management process is comprised of five stages. Briefly described here, the five stages are as follows:

• Requirements ELICITATION is the process of identifying stakeholder classes, defining the project scope, identifying requirement sources, and applying techniques to gather the information.

• Requirements ANALYSIS is the process of analyzing the information elicited, resolving conflicts, documenting assumptions, constraints, and dependencies, and working with the stakeholders to establish priorities.

• Requirements REPRESENTATION is the process of specifying the business needs using a combination of graphical models and textual documents.

• Requirements VALIDATION is the process of reviewing the represented information with the stakeholders for quality characteristics such as completeness, correctness and feasibility.

• Requirements CHANGE CONTROL is the process of maintaining a set of approved or baselined requirements throughout the lifecycle of the development project.

In the subsequent lessons of this training module, I will present an overview of each stage that includes:

• Purpose

• Objective

• Summary of primary tasks performed in the stage

REQUIREMENTS ELICITATION is the process of identifying stakeholder classes, defining the project scope, identifying requirement sources, and applying techniques to gather the information. The purpose of the elicitation stage is to discover and articulate the business and user needs.

The objective of the elicitation stage is to gather requirements from various sources, engage the right stakeholders in a variety of elicitation techniques, and capture the information provided for use in analysis.

REQUIREMENTS ANALYSIS is the process of analyzing the information elicited, resolving conflicts, documenting assumptions, constraints, and dependencies, and working with the stakeholders to establish priorities.

The purpose of the analysis stage is to review and organize the information obtained during elicitation.

REQUIREMENTS REPRESENTATION is the process of specifying the business and user needs using a combination of graphical models and textual documents. The purpose of the representation stage is to determine the best means for visualizing and communicating the requirements to the stakeholders.

REQUIREMENTS VALIDATION is the process of reviewing the represented information with the stakeholders for quality characteristics such as completeness, correctness and feasibility.

The purpose of the validation stage is to confirm that you have the correct set of requirements that enable the development team to build a solution that satisfies the business needs.

REQUIREMENTS CHANGE CONTROL is the process of maintaining a set of approved or baselined requirements throughout the lifecycle of the development project.

The objective of the analysis stage is to review and clarify the requirements information, capture assumptions, identify constraints and dependencies, and collaborate with stakeholders to prioritize the requirements.

In this training module, you learned that the requirements management process is iteratively and incrementally applied in a top-down approach to define the business, user, and system-level requirements. The stages of the process are sub-disciplines. That is, each stage is itself a process that encompasses multiple tasks. Perhaps it all sounds like a lot of work. And, maybe you’re wondering if it is all worthwhile.

I want to share the wise words of my friend and industry expert, Karl Weigers, from his second edition of Software Requirements:

“There is no systematic formula to requirements development.”

I agree with Karl. There is no one way, and for that matter, no wrong way to manage your next requirements initiative. However, there are some ways that produce better results than others.

In this module, you will gain an understanding of an approach to requirements management that I have found enables my clients to better develop requirements through the successful collaboration of stakeholders. Now, you too can develop better requirements by implementing the recommendations that I offer in this course. The lessons in this module summarize a set of activities that make up The Requirements Quest Approach.

The requirements process is applied first to derive the business-level requirements. The focus of the business level is on WHY the project is being done. For the purposes of this course, the business need or opportunity has already been identified. Therefore, the objective of the business level is to describe how doing the project is going to solve the business problem or satisfy the business opportunity.

Following the successful definition of the business-level requirements, the focus of the user level of requirements is on WHO benefits from interacting with the system under development. The objective of the user level is to identify who needs to use the system and the user goals to be accomplished through usage of the system.

Following the successful definition of the business-level and user-level requirements, the requirements process is applied to derive the system-level requirements. System requirements describe the requirements for a product that is composed of multiple components and subsystems. Thus, a system can be all software or it can be software and hardware.

As you should expect, this Requirements Fundamentals course devotes a lot of attention to defining what requirements are. However, it is also necessary to point out what requirements are not. In the context of representing requirements, the following elements should be excluded from the requirements specification:

• Design, or how to implement the solution to the requirements

• Project-related information

• Business Rules and Standards

In our discussion in Module 4 on the Requirements Hierarchy, you should have noticed that the three levels of requirements focus on WHY and WHAT.

• The business-level requirements focus on WHY the project is being worked on.

• The user-level requirements focus on WHAT the users need.

• The system-level requirements focus on WHAT the system must do for the users, as well as WHAT quality attributes the system environment must have.

In the previous lesson, you learned that design elements are HOWs, and do not belong in the requirement specification.  Another element that should be excluded in a requirement specification is project-related information.

Similar to design and project-related information, business rules and standards are also elements that should be excluded from a requirements specification. Defined loosely, business rules are the decisions made regarding policies and procedures for how a business will operate day-to-day. The Business Rules Group defines a business rule as:

“A statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business.”

Apply a facilitation strategy ("be nice") to manage dysfunctional behavior in your requirements workshops.