Requirements Fundamentals: Process Stages, Levels, Types
3.7 (37 ratings)
Instead of using a simple lifetime average, Udemy calculates a course's star rating by considering a number of different factors such as the number of ratings, the age of ratings, and the likelihood of fraudulent ratings.
958 students enrolled
Wishlisted Wishlist

Please confirm that you want to add Requirements Fundamentals: Process Stages, Levels, Types to your Wishlist.

Add to Wishlist

Requirements Fundamentals: Process Stages, Levels, Types

Learn industry terminology and explore core tasks and activities for developing GOOD requirements. Business Analysis.
3.7 (37 ratings)
Instead of using a simple lifetime average, Udemy calculates a course's star rating by considering a number of different factors such as the number of ratings, the age of ratings, and the likelihood of fraudulent ratings.
958 students enrolled
Last updated 10/2016
English
Price: $30
30-Day Money-Back Guarantee
Includes:
  • 3 hours on-demand video
  • 1 Article
  • 4 Supplemental Resources
  • Full lifetime access
  • Access on mobile and TV
  • Certificate of Completion
What Will I Learn?
  • Collaborate with others to develop good requirements
  • Apply a quality requirements management process to elicit, analyze, represent, validate, and manage changes to requirements
  • Differentiate between business, user, functional, and nonfunctional requirements
  • Ask suggested questions to better elicit requirements
  • Apply sentence formats to write requirements
  • Consistently apply an approach to requirement activities
  • Articulate what requirements are and are not
  • Master requirements industry terminology
View Curriculum
Requirements
  • Keep an open mind, and be ready to learn
  • Be willing to apply the requirements management process and approach on your next requirements initiative
Description

Master requirements industry terminology and explore core tasks and activities for developing GOOD requirements. Take this course to learn about a proven requirements management process, ask questions to better elicit requirements, and apply a 12-activity approach to define business, user, and system-level requirements. The requirements management process is applicable in waterfall, iterative, and agile development environments.

This course is designed for those seeking to improve their ability to:

  • Collaborate with others to develop good requirements.
  • Apply a requirements management process to elicit, analyze, represent, validate, and manage changes to requirements.
  • Differentiate between business, user, functional, and nonfunctional requirement types.
  • Consistently apply an approach to requirement activities.

By the end of the course, you will be able to:

  • Identify tasks in a 5-stage requirements management process.
  • Ask suggested questions to better elicit requirements.
  • Apply sentence formats to write requirements.
  • Identify 12 activities in the Requirements Quest Approach.
  • Articulate what requirements are and are not.

The ideal student for this course is the:

  • New business analyst that wants to build a solid foundation of requirements terminology, tasks, and activities.
  • Experienced business analyst looking to improve consistency in their requirements approach.
  • Product owners, development team members, and stakeholders who  seek a better understanding of requirement fundamentals. 

This course includes 8 modules, 30 lectures, 3 hours and 15 minutes of videos, 29 quizzes, and 4 downloadable quick-reference job aids. 

Enroll now and navigate the route to good requirements with confidence!

Who is the target audience?
  • Entry-level business analysts who want to build a solid foundation of industry terminology, tasks, and activities
  • Experience business analysts who are seeking to improve consistency in their requirements approach
  • Product Owners, Project Managers, Quality Assurance Analysts, Development Team Members, and all project Stakeholders who play a role in developing good requirements
Students Who Viewed This Course Also Viewed
Curriculum For This Course
31 Lectures
03:06:09
+
Requirements Fundamentals Introduction
1 Lecture 04:10

Welcome to Requirements Fundamentals!

I am excited for the opportunity to help you master the Requirements Fundamentals presented in this course. Here’s what you can expect in the modules that follow.

You are probably watching this video because you contribute to the development of requirements in one or more of the following roles:

  • Requirement Producer, or someone that is responsible for eliciting and documenting the requirements
  • Requirement Supplier, or someone that has business or technical knowledge of a topic related to the product or system being developed
  • Requirement Receiver, or someone that uses the requirements as an input to one or more components to building a solution
  • Requirement Supporter, or someone that champions the requirements process

An in depth discussion of these four requirement roles occurs in module two. For each of the four roles, I provide a definition, identify the responsibilities, and identify other job titles of people who commonly perform the roles.

In module three, I tell a few stories about good requirements, as well as present a definition of good requirements and analysis of the key components of the definition.

In module four, I explain the three distinct levels of requirements that are referred to as the requirements hierarchy. The three levels included in the hierarchy are business, user, and system.

In module five, we look at four requirement types: business, user, functional, and nonfunctional. For each type, I present a definition, a suggested format for written statements, and some examples.

In module six, I present the five states or sub-processes of the requirements management process. For each of the process stages, I provide a definition, and outline the primary tasks that are performed.

In module seven, I share the Requirements Quest Approach. I explain how the requirements management process is iteratively and incrementally applied at each level of the requirements hierarchy. For each level, I identify the primary activities that are performed.

Finally, in module eight, I summarize the contents of a requirement specification, and discuss three elements that should be excluded from it. The elements are as follows: design or how to construct the system, project-related information, and business rules.

To maximize your on-demand learning experience, I encourage you to print the downloadable materials provided. These supplemental materials align with the visuals presented in the training videos and can improve your comprehension. Furthermore, the printed materials serve as quick-reference job aids following the training, which can improve retention of what you learned.

Once again, thank you for choosing Requirements Quest for your requirements training needs. I look forward to helping you explore the Requirements Fundamentals.

To the best version of yourself,
Roxanne Miller

Preview 04:10
+
Requirement Roles
6 Lectures 33:11

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.

The success of any new product, project effort, or requirements initiative is never due to a single individual’s effort. Rather, the success is due to the collaboration of a team. Although individuals may come and go throughout the life of the requirements effort, the need to fill the roles described in this module is continuous.

Furthermore, a single individual may be responsible for activities that span across multiple roles. Likewise, one role may need to be performed by multiple individuals in order to complete all of the role-related tasks. The business sponsor is ultimately accountable for filling all the needed roles throughout the life of the project.

Now, I would like to briefly introduce the requirement roles by showing you four icons that will be used to represent or symbolize the requirement roles, starting with the Requirement Producer. In short, the Producer role is primarily responsible for driving the requirements management process and producing the requirements. Thus, the icon is that of a person wearing a cap and using a steering wheel to designate the Producer role as the driver.

The next role is the Requirement Supplier, and the icon of a person speaking into a microphone illustrates the importance of the Supplier’s responsibility for being the voice of the customer.

Next is the role of Requirement Receiver. This icon depicts a person receiving a package. I use the term Requirements Package to encompass all the artifacts that communicate the requirements. The Requirements Package often includes models, prototypes, and other visual graphics, as well as numerous textual deliverables such as requirements definitions, use cases, and user stories.

The fourth role is the Requirement Supporter. Looking at the icon of a person that is holding money, you would probably guess that the Supporter may offer financial backing. While that is often true, the Supporter is more likely a requirements process champion. That is, they are often in a position to influence others, and contribute by enabling the Producer, Supplier, and Receiver to apply requirements best practices.

Now, before I go further in defining the roles, please keep in mind that within the requirements development initiative, it is very probable that you will play multiple roles. In fact, in many smaller companies this is almost a certainty. With that being said, as we move throughout the course, please make sure that you are thinking about the content of what is being taught from both your ‘primary’ role and any of the ‘secondary’ role(s) that you may need to play during your contributions on the requirements initiative.

Furthermore, please keep in mind that your role in the requirements is not dependent upon or dictated by your job title. If you have been assigned to, or asked to participate in, a project that involves requirements development, recognize that regardless of what the name plate says on your workstation, or how you describe your job to polite company at dinner parties, for this part of your job, you need to adhere to the role and the responsibilities outlined in this course, and that by doing so you will be more effective at developing good requirements.

Starting with the next lesson, I will define the four roles that participate in the requirements development process, and how you can contribute toward good requirements.

Requirement Roles Introduction
05:31

Roles Introduction Quiz
5 questions

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

Simply defined, a Requirement Producer is any individual who is responsible for capturing the requirements. In more explicit terms, the Requirement Producer is any individual who is responsible for driving the process of eliciting, analyzing, representing, validating, and managing changes to the requirements.

The Requirement Producer is a liaison between the business stakeholders that have a business need, and the stakeholders that will develop and implement a solution to the business need. The Requirement Producer’s primary responsibilities are to first, identify the right stakeholders to engage in developing the requirements, and second, to facilitate the communication and collaboration of the stakeholders to implement a solution to the requirements that are derived from the business need.

Without jumping too far ahead into content that we will explore in later modules, the Requirement Producer is responsible for leading the activities of the approach to develop requirements at each of the levels in the requirements hierarchy. The three levels in the requirements hierarchy are business, user, and system.

I take the first letter of each level to form an acronym. String together the B from Business, the U from User, and the S from System, to derive B-U-S, and pronounce it as bus (like a school bus). You should now have a little better understanding of why I use the icon of a bus driver to symbolize the Requirement Producer. Additionally, the Requirement Producer facilitates the stakeholders through the five stages of the requirements management process including elicitation, analysis, representation, validation, and change control.

Here is a brief summary of the activities that the Requirement Producer performs within each process stage:

  • In the requirements elicitation stage, the Requirement Producer identifies stakeholders, gathers sources for requirements, and applies a variety of techniques to elicit the requirements.
  • In requirements analysis, the Requirement Producer documents assumptions, identifies constraints and dependencies, and facilitates the stakeholders through discussions to prioritize the requirements.
  • The Requirement Producer determines the right combination of models, visuals, and text-based documents to communicate the requirements in the requirements representation stage of the process. Some of the common deliverables created by the Requirement Producer are process maps, requirement definitions, use cases, and user stories.
  • In requirements validation, the Requirement Producer facilitates reviews of the requirements with the stakeholders.
  • And, finally, the Requirement Producer coordinates communication and traceability to manage changes to the requirements.

Now, let’s talk briefly about four common job titles, or perhaps other role names, of individuals who routinely perform as a Requirement Producer.

  • BUSINESS ANALYSTS are responsible for translating the business and user needs into detailed software requirements.
  • DATA ANALYSTS are responsible for the development and management of information requirements for the business.
  • SYSTEMS ANALYSTS are responsible for designing and supporting software applications.
  • And, NETWORK ARCHITECTS are responsible for the structure, location, and access to software applications.

In summary, the role that is responsible for capturing requirements varies from organization to organization depending on:

  • The size of the organization
  • The division of responsibilities
  • The size and complexity of the software development initiatives

Come join me in the next lesson to learn more about the Requirement Supplier role.

Preview 06:05

This quiz will affirm your understanding of the responsibilities of the Requirement Producer role.

Requirement Producer Role
5 questions

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

Simply defined, a Requirement Supplier is any individual who is responsible for defining the business needs to be satisfied. This includes supplying all the detail from the initial idea or inception through each incremental iteration of the system development and implementation.

Let me repeat what I said in the first lesson in this module. That is, a single individual may be responsible for activities that span across multiple roles. Also, one role may need to be performed by multiple individuals in order to complete all of the role-related tasks. In my experience, most projects require multiple individuals as Requirement Suppliers to fully define requirements.

Again, trying not to jump ahead too much to content that will be explored in the upcoming modules, we can look at the expectation for multiple stakeholders to participate when applying the requirements approach to define requirements for each of the three levels of requirements. It is fairly typical to have the Project Sponsor perform the role of a Requirement Supplier at the business level in order to define the high-level business need. At this level the Requirement Supplier provides the business strategy and direction of the project initiative. Furthermore, subject matter experts from multiple business areas often play the role of Requirement Supplier during the development of user-level requirements. At this level the Requirement Supplier provides the details that define the needs of the users that will interact with the system under development.

You may hear this representation of the users’ needs referred to as the “Voice of the Customer”. Thus, I use the icon of the person using a microphone to symbolize the Requirement Supplier.

If the Requirement Producer is the driver of the bus, then the Requirement Supplier is a key passenger. As we expect multiple Requirement Suppliers to be engaged, the Requirement Producer will make frequent stops along the route to good requirements as they pick up and drop off Requirement Suppliers. If you’re a Requirement Producer, watch out for the Requirement Supplier who tends to be a back-seat-driver and may tell you where to go!

The Requirement Supplier is responsible for supplying knowledge relevant to the development of requirements in support of the business strategy and direction. I strongly recommend that the Requirement Producer employs a technique called Stakeholder Profiling. This technique is used to identify the knowledge that is needed to represent the requirements, what stakeholders have that knowledge, and who is available during the development of the requirements. This technique is one of the activities included in the Requirements Quest Approach. An overview of the Approach is presented in module 7 of this course.

While the Requirement Producer is responsible for eliciting the requirements from Requirement Suppliers, the Requirement Suppliers are accountable for the correctness and completeness of the requirements, as well as establishing the necessity and prioritization of the requirements.

To better understand the responsibilities of the Requirement Supplier, let’s look at four common job titles, or other roles, of individuals who routinely perform as a Requirement Supplier:

  • BUSINESS OWNERS are a common source for project initiatives as these individuals often have ideas for the overall business strategy. The Business Owner contributes to the requirements effort by providing a vision statement or business goals deliverable.
  • PROJECT SPONSORS are usually executive-level individuals that have ownership of a project effort, and ultimately are responsible for the success or failure of the project. The Project Sponsor has an understanding of the company’s strategic direction, and holds authority to allocate budgeted funds and resources to the project. The Project Sponsor contributes to requirements by providing a business case, as well as assisting with Stakeholder Profiling in order to assign the most knowledgeable stakeholders as resources for the detailed requirements.
  • PRODUCT MANAGERS are responsible for the day-to-day planning, management, and quality control of the products. Individuals in this role often lead the different teams that are working on project efforts, and report project status and issues to executive management. The Product Manager contributes to requirements by providing direction on development of the products or system applications, and like the Project Sponsor, assists with Stakeholder Profiling in order to assign the most knowledgeable stakeholders as resources for the detailed requirements.
  • SUBJECT MATTER EXPERTS, or Knowledge Experts, are individuals that have expertise in one or more particular business area. Sometimes the acronym S-M-E, often pronounced SME, is used to refer to this role. The Subject Matter Expert contributes to requirements by providing their knowledge of the product or business topic verbally or through written documentation. They also participate in product reviews. A key point to remember about Subject Matter Experts is that their knowledge is valuable, and that the utilization of their time must be used wisely as they are frequently engaged in multiple projects over and above the day-to-day business operations that they support.

Again, these are some of the common roles that perform as Requirement Suppliers. There are certainly many others that went unmentioned here.

To summarize, the Requirement Supplier is any individual that contributes to requirements development by providing the vision, strategy, and direction for the product or system under development, and by providing the details that define the business and user needs.

Come join me in the next lesson to learn more about the Requirement Receiver role.

Requirement Supplier
08:25

This quiz will affirm your understanding of the responsibilities of the Requirement Supplier role.

Requirement Supplier Role
5 questions

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

Simply defined, a Requirement Receiver is any individual who is responsible for developing a solution to the defined requirements. The Requirement Receivers use the defined requirements as key inputs to developing the work products for their respective role in delivering a solution.

The Requirement Receiver contributes during the requirements development process by participating in requirement reviews. The Requirement Receiver is primarily concerned with the feasibility.

In other words, is it viable to deliver the system that is being requested?

As I stated in the first lesson of this module, I use the term Requirements Package to encompass all the visual and text-based deliverables that represent the requirements. I even consider a verbal conversation to be part of the total Requirements Package. At any rate, the Requirement Receivers receive the Requirements Package and use it to build a workable solution.

Now, let me remind you that the Requirement Producer is the driver of the bus (meaning that they drive the approach to apply the requirements process at the business, user, and system-level requirements). Just as the Requirement Suppliers are key passengers on the bus, so too, are the Requirement Receivers. So the Requirement Producer makes multiple stops along the route to good requirements to pick up and drop off Requirement Suppliers and Requirement Receivers.

To better understand the responsibilities of the Requirement Receiver, let’s look at five common job titles, or other roles, of individuals who routinely perform as a Requirement Receiver:

  • PROJECT MANAGERS are individuals responsible for the day-to-day planning and management of the project effort. They are accountable for the successful completion of all work deliverables, and monitor and track the project budget and timeline. The Project Manager leads the project team members and reports status and issues to the respective Product Managers and Project Sponsor for the project. The Project Manager contributes to the requirements effort by helping to remove impediments to the teams’ progress and completion of work. They, too, have a keen interest in Stakeholder Profiling in order to get the most knowledgeable stakeholders assigned to the project.
  • SYSTEM DESIGNERS are responsible for translating business system requirements into a physical system design. While the Requirement Producer may focus on “what” and “why”, the System Designer focuses primarily on “how”.
  • DEVELOPERS or Programmers are responsible for developing source code for the solution system. The Developer also focuses primarily on “how”.
  • TEST ANALYSTS or Quality Control Analysts are responsible for planning and executing tests to demonstrate the implementation of the requirements, and that the requirements meet the business and user needs. The Test Analyst participates in reviews of the requirements, and helps to detect implementation components that don’t accurately satisfy the requirements.
  • TRAINERS are individuals that have responsibility for administering training and education for both user and technical areas as needed. Trainers are concerned with the public view of the system, and the internal organizational view of the system. Like the Test Analyst, the Trainer participates in reviews of the requirements.

To summarize, the Requirement Receiver is any individual that uses the requirements as inputs to develop one or more aspect of the solution to the business and user needs.

Come join me in the next lesson to learn more about the Requirement Supporter role.

Requirement Receiver
05:37

This quiz will affirm your understanding of the responsibilities of the Requirement Receiver role.

Requirement Receiver Role
5 questions

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

A Requirement Supporter is defined as any individual who is responsible for assisting the Producers, Suppliers, and Receivers in applying the requirements management process. The Requirement Supporters review the requirements, as well as the requirements approach, to offer suggestions for improvement on future project efforts. That is, they are process champions and support the activities of the process and look for ways to improve the process.

Interestingly, whereas the Requirement Suppliers and Receivers are passengers on the bus, the Requirement Supporters are not. That is, the Supporters are not participants in the process. Rather, the Supporters are cheerleaders for the process. As the bus rolls along the route to good requirements, the Requirement Supporters cheer from the sidelines. If the bus breaks down, the Supporters are the ground crew that will help change tires and refuel the bus. They are the medics that care for tired and weary drivers and passengers.

Now, let’s look at three common job titles, or other roles, of individuals who routinely perform as a Requirement Supporter.

  • PROCESS OWNERS are individuals responsible for the development and maintenance of process procedures and methods. The Process Owner assists the project team in appropriately selecting activities and techniques to help the specific project succeed.
  • QUALITY ASSURANCE CONSULTANTS act as auditors to ensure that standards and processes are being followed.
  • FACILITATORS are individuals that are skilled in organizing, planning, and conducting workshops for the objective of eliciting, analyzing, representing, validating, and managing changes to requirements. Facilitators do not contribute to the process or make decisions about the product or system under development. Rather, the Facilitator should be neutral to the project outcome. They aide the requirements development process by fostering an environment for optimal stakeholder collaboration.

To summarize, the Requirement Supporter is a process champion and assists the Producers, Suppliers, and Receivers in successfully applying the requirements management process.

Come join me in the next lesson for the conclusion of Requirement Roles.

Requirement Supporter
04:18

This quiz will affirm your understanding of the responsibilities of the Requirement Supporter role.

Requirement Supporter Role
3 questions

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

First, you learned that the Requirement Producer is any individual that is responsible for eliciting, analyzing, representing, and validating requirements, as well as managing changes to the requirements. The Requirement Producer is the driver of the approach to define requirements at the business, user, and system levels. Examples of Requirement Producers include Business Analysts, Data Analysts, System Analysts, and Network Architects.

Next, you learned that the Requirement Supplier is any individual who is responsible for defining the business needs to be satisfied. This includes supplying all the detail from the initial idea or inception through each incremental iteration of the development and implementation of the system. The Requirement Suppliers are key passengers of the bus that travels the route to good requirements. Examples of roles that perform as Requirement Suppliers include Business Owners, Project Sponsors, Product Managers, and Subject Matter Experts.

Next, you learned that the Requirement Receiver, who is also a key passenger on the bus, is any individual who uses the requirements package to develop and implement one or more components of the solution. Examples of roles that perform as Requirement Receivers include Project Managers, System Designers, Developers, Test Analysts, and Trainers.

Last, you learned that the Requirement Supporter is any individual who assists the stakeholders in applying the requirements management process. Examples of roles that perform as Requirement Supporters include Process Owners, Quality Assurance Consultants, and Facilitators.

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 the next module, I will help you to understand the meaning of Good Requirements. Come join me in the next module.

Requirement Roles Conclusion
03:15

Requirement Roles Quiz
5 questions
+
The Quest for Good Requirements
1 Lecture 10:50

I would like to open this lesson by sharing a story with you. A couple years ago, Requirements Quest was a sponsor for the Building Business Capability conference, the International Institute of Business Analysis’ premier annual event. It was the first time that I was sponsoring and attending the conference. One of my favorite things about attending a conference such as this is the opportunity to network with fellow business analysis professionals.

That year, the conference was held in Las Vegas, Nevada. From my sponsor’s viewpoint, I attend a conference with hopes of starting a partnership with a new client, of landing an onsite training session, or having someone invite me to speak at their upcoming event. Additionally, I want to make a favorable impression on the conference attendees so I decided to purchase a quality tradeshow display. So my business associate, Bruce Opsal, and I, with my new 8-foot, lighted display kit in tow, flew to Las Vegas. Ha, it was Las Vegas, after all. Of course, I had to have lights!

Bruce and I enjoyed talking to attendees that were visiting our sponsor display. With the display all lit up, attendees, even from afar, could read the inviting, thought-provoking statement that spanned the upper portion of the display.

Good Requirements Save You Time and Money

I distinctly recall one attendee’s reaction to my display. I saw him approaching the Requirements Quest booth from several yards away. He came walking straight for the booth, and stopped just a few feet directly, and squarely, in front of me. Thank goodness for the table that put that 3 feet between us.

He looked me right in the eye and said, “Good requirements are a myth.”

Keep in mind that I had never met this person before, and there weren’t any introductions, formal or otherwise, that provided me with any clue regarding his demeanor.

My mind raced through the archives of all my past experiences and training in soft-people skills, and I surprised myself with my quick-witted response. More likely, it wasn’t wit; rather, my instinctual gut reaction as a business analyst, and my inability to refrain from asking questions.

I said, “I think you’re right, but I want to know why you think you’re right?”

In the somewhat lengthy conversation that followed, we discussed his views about his original statement.

Now, I want to ask you essentially the same question that I asked him. Do you think he is right? Are good requirements a myth?

Before I define good requirements, I want to share with you another story about my interaction several years ago with the CIO of a large corporation for whom I was consulting for. The CIO’s name was Rich. It was fairly early in the consulting engagement, and Rich gave me his definition of good requirements.

Rich told me that, “Good requirements was when he could pick up the written requirements work product from any project, and without conversation with any person that contributed to producing the written requirements, he could read the requirements and know exactly what to develop as a solution.”

I told Rich that I would have my things packed up and be on my way within the hour. I told him that what he expected wasn’t possible within the budget and schedule constraints for his projects. As it turned out, I was onsite for over a year with his organization. I never did achieve his definition of good requirements, but I helped the people in his organization achieve mine.

So, maybe you’re thinking, “Hey, Roxanne, aren’t there things that you can look for in documented requirements that are viewed as good practices?”

Yes. There are quality attributes of well-written, text-based requirement deliverables. For example, I could review written requirements and access the correctness and completeness. I can measure the degree of modifiability, and judge whether the requirement statements are traceable, testable, and prioritized. However, believe me, when I say that I have come across well-written requirements that I would not have shared as an example of good requirements.

Here’s another question that I have for you. Do requirements have to be written?

Just one more story, and then I promise to give my definition of good requirements. A few months ago, I had quality time bonding with my adult-aged daughter, as we spent the weekend building a table. My daughter came over to my house on Friday and showed me a picture of a do-it-yourself entry table that was made from a repurposed wood pallet. She showed me the picture and said, “Mom, we could make this table.” By ‘we’, she meant ‘me’, as in I should make the table for her.

So Saturday morning we embarked on the wood-pallet table project, and on Sunday she left with a table that she couldn’t wait to set in her foyer.

On Monday, I emailed ‘before’ and ‘after’ photos of the table to my friend John. Then, later that day in a phone conversation with John, he teasingly said to me, “Oh, so you made a table without documenting requirements.”

I laughed, and replied, “That’s right! I applied agile practices and worked alongside the customer, and continuously elicited and validated requirements throughout each incremental iteration of the product development.”

Finally, here’s my definition of good requirements:

“A state achieved as an outcome of effectively applying a quality requirements management process in which stakeholders collaborate and derive the same interpretation of the defined requirements, and the requirements accurately reflect the desired business value and user needs.”

Let’s take a closer look at key elements contained in this definition.

First, note that good requirements are not necessarily a tangible thing. Rather, the adjective ‘good’ clarifies the state or condition the requirements are in at a specific time. During requirements development the state of the requirements continuously evolves.

Another key element of the definition is a quality requirements management process should be used to iteratively and incrementally develop the requirements. Within each level of the requirements approach the requirements are elicited, analyzed, represented, validated, and monitored for changes. In the beginning of this development process, we don’t label a first draft of written requirements as ‘bad’. We understand that the requirements are still evolving.

Another element is the need for stakeholder collaboration and agreement on the requirements. The activities in the requirements approach facilitate stakeholder collaboration, and help the stakeholders to reach consensus on a consistent interpretation of the requirements.

Finally, a key element of the definition is that the defined requirements should accurately state the business and user needs, and represent value to the business. Following a quality requirements management process and effective collaboration of the stakeholders will deliver products and systems that the customer and end-users need.

In the remaining modules of this Requirements Fundamentals course, we will explore the components of a quality requirements management process.

Come join me in the next module.

Preview 10:50

What Are Good Requirements Quiz
5 questions
+
Requirements Hierarchy
1 Lecture 06:44

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

Repeating what I stated in Module 2 on Requirement Roles, I use the first letter of each of the words, Business, User, and System, to form an acronym, B-U-S, pronounced as BUS, like a school bus. Furthermore, the individuals who perform the role of Requirement Producer are the drivers of the BUS, with key passengers being the Requirement Suppliers and the Requirement Receivers.

The levels of the requirements hierarchy support you on your journey to good requirements by serving as a guide to your requirements approach. They help you to gauge where you are in applying the requirements management process, which is eliciting, analyzing, representing, validating, and managing changes to requirements.

I use a pyramid to depict the requirements hierarchy as shown here. I use a pyramid for a couple reasons.

First, the pyramid represents the top-down approach to iteratively applying the requirements management process. The approach starts at the top with the high-level business requirements, then flows downward to the user requirements, and ends with the detailed, system-level requirements.

Second, each level of the pyramid is proportionate in size to the other levels to illustrate the relative quantity or number of requirements that are typically written at each level. For example, it is common to have one business requirement statement to describe why a project is being done, and hundreds, if not thousands, of functional requirements to describe the details of what the system must do to support a handful of user roles.

Now, let’s take a closer look at the focus of each level of the hierarchy.

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.

Next, the requirements process is applied to derive the user-level requirements. The focus of the user level 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.

Finally, 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. Therefore, a system can be all software or it can be software and hardware. A good example of a system is a product that is commonly referred to as a mobile phone. The mobile phone is both hardware and software. The user of the mobile phone can expand the features by downloading additional software applications or subsystems.

Without jumping too far into the content of the next training module on requirement types, the system level includes functional and nonfunctional requirements. 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.

To recap, there are three distinct levels in the requirements hierarchy:

  • The Business Level – wherein you focus on WHY the project is being done
  • The User Level– wherein you focus on WHO is going to use the system
  • The System level – wherein you focus on WHAT the system must do, and HOW WELL it must do it

Come join me in the next module to explore four types of requirements.

Requirements Hierarchy
06:44

Requirements Hierarchy Quiz
5 questions
+
Requirement Types
6 Lectures 42:36

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

Come join me in the next lesson to examine the business requirement type.

Requirement Types Introduction
02:35

Requirements Types Quiz
4 questions

Let’s begin by placing the business requirement type within the business-level requirements of our hierarchy. You’ll recall that the essence of the business level of requirements is to capture the high-level objectives of the business organization.

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.

The business requirement statement is written from the project sponsor’s point of view. In Module 2 on the Requirement Roles, I stated that Project Sponsors often contribute to requirements by performing the role of Requirement Supplier, and more specifically to provide the business strategy and direction of the project initiative. The business requirement articulates the sponsor’s business goal, and summarizes the business value for doing the project.

The business goal is typically one or more of the following:

  • Increase revenue
  • Reduce expenses
  • Improve service
  • Comply with regulatory requirements

Usually in an interview with the Project Sponsor, or equivalent Requirement Supplier, I ask questions such as the following to elicit business requirements:

  • What business opportunity or business problem does this project initiative resolve?
  • What is the project team expected to deliver or implement to satisfy the business opportunity or resolve the business problem?
  • Stated in terms related to increasing revenue and decreasing expenses, how will you measure the success of the project initiative?
  • Why do this project?

The answers to questions like these are summarized as business requirements and commonly written in a project charter. Other common names for this deliver are vision statement, project definition document, and business case.

I like to use the following three components to formulate a business requirement statement: The purpose of [ABC] is to [DEF] so that [XYZ].

Where [ABC] is the name of the project, [DEF] is a description of what the project team is expected to deliver or implement, and [XYZ] are specific, measurable business benefits that will be realized as a result of doing the project.

Some years ago I worked on a project for an owner of a gas station and small convenience store. Here is an example business requirement from that project.

The purpose of the Automated Teller Machine Project is to purchase and install an Automated Teller Machine (ATM) inside the Parkside gas station and convenience shop so that (a) convenience item sales increase by four percent (4%) per month within 3 months following the ATM installation, and (b) ATM usage-fee revenue of at least $10,000 is generated within 1 year of the project completion.

To recap, the business requirement type describes why the project is being done. A project sponsor is typically the Requirement Supplier of the business requirement. So a good question to ask the Project Sponsor is, “What value does the business get from doing this project?”

Come join me in the next lesson to explore the user requirement type.

Business Requirements
05:16

This quiz will affirm your understanding of the business requirement type.

Business Requirements
5 questions

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.

The user requirement type is captured within the user-level requirements of the requirements hierarchy. Also, let me remind you that the user-level requirements are derived from the business-level requirements.

Using the business requirements as a key input, the essence of the user level of requirements is to identify the roles that perform within the scope of the project or requirements initiative. The objective is to determine what business functions and processes are affected by the scope of the project, and who performs those functions or performs a role in those affected processes.

Within the user requirements level, we must identify the goals that each user role expects to accomplish through interaction with the system under development.

A user requirement is defined as a statement that describes user goals or tasks that the users must be able to perform through interaction with the system.

While the business requirements describe WHY the project is being done, the user requirements describe WHO is using the system and WHAT information and materials are exchanged with the system. The user requirement statement is written from the user role’s point of view.

In Module 2 on Requirement Roles, I stated that subject matter experts from multiple business areas often play the role of Requirement Supplier during the development of user-level requirements. At this level the Requirement Supplier provides the details that define the needs of the users that will interact with the system under development. Thus, we need to collaborate with stakeholders that represent the Voice of the Customer.

Usually in an interview with a Subject Matter Expert, or equivalent Requirement Supplier, I ask questions such as the following to identify WHO, or what user roles, will interact with the system:

  • Who, or what roles, will interact with the system under development?
  • Who provides information and materials as inputs to the system?
  • Who receives information and materials as outputs from the system?

Once I have identified WHO interacts with the system, then for each user role I ask questions to identify the user goals, such as:

  • What is the reason that the user role interacts with the system?
  • What goal is the user role looking to accomplish through interaction with the system?
  • What work is the user role performing?

Finally, for each user goal, I ask questions to elicit the user requirements:

  • What does the user role provide as inputs to the system?
  • What does the user role expect to receive as outputs from the system?

The answers to questions like these are grouped as sets of user requirements and written in a requirements definition document. Other common text-based deliverables used to represent user requirements are use cases and user stories.

I like to use the following structure to form a logical set for the user requirements to reside. The logical set itself follows a hierarchy. First in the logical set is the System Domain. This is the system that the user role initiates interaction with in order to accomplish some desired benefit.

Next in the logical set is the User Role. The user role identifies who or what interacts with the system.

Next in the logical set is the User Goal. The user goal is usually a short phrase of 3 to 5 words that summarize the reason why the User Role interacts with the system. Further, I recommend using a verb-noun format to name the user goal.

Let me illustrate the structure of a logical set for you through an example. We’ll identify a Mobile Phone as the system domain, and a Customer as the user role that interacts with the Mobile Phone. Next, let’s identify reasons why a Customer interacts with a Mobile Phone, and apply a verb-noun format. Some reasons for interaction are as follows:

  • Add a Contact
  • Send Texts
  • Answer Incoming Calls

Finally, for each user goal, I’ll write user requirement statements in one of two formats. To describe user inputs to the system, I write:

The [User Role] provides [“named information or materials”].

Here are a couple examples:

  • The Customer provides “Contact Information”.
  • The Customer provides “Text Data”.

Similarly, to describe user outputs from the system, I write:

The [User Role] receives [“named information or materials”].

Here are a couple examples:

  • The Customer receives “Contact Summary”.
  • The Customer receives “Sent Message Confirmation”.

To summarize this lesson, the user requirement type describes user goals or tasks that the users must be able to perform through interaction with the system. Several Subject Matter Experts are the Requirement Suppliers of user requirements as they represent the user point of view. At the highest level, there are 4 questions you should ask to elicit user requirements:

  • Who interacts with the system?
  • Why does the user role interact with the system?
  • What information or materials does the user input?
  • What outputs of information or materials does the user expect to receive?

Come join me in the next lesson to explore the functional requirement type.

User Requirements
09:34

This quiz will affirm your understanding of the user requirement type.

User Requirements
10 questions

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.

Moreover, in the previous lesson, you learned that the User requirements describe WHO is using the system and WHAT information and materials are exchanged with the system. Functional requirements describe functionality that must be built into the system to enable the users to perform their goals or tasks. Functional requirements identify the processing that the system must perform on the inputs of information and materials to prepare and present outputs of information and materials.

While the user requirements are written from the user role’s point of view, the functional requirements are written from the system function or feature point of view. A feature is a set of logically related functional requirements that provides a capability to the user and enables the accomplishment of the user’s goal.

So what does functional processing mean?

Well, functional processing includes the following activities:

  • Information and Material Transformation – This involves the movement of data. The data must be received, recorded, saved, stored, transferred, and retrieved by the system.
  • Data Validation – This consists of routines to edit data, and check for accuracy and correctness.
  • Computation – This encompasses calculations that the system must perform with the data.
  • Error and Exception Handling – This consists of routines to prevent data corruption.

Similar to user requirements, multiple Subject Matter Experts are necessary to fill the role of Requirement Supplier when eliciting functional requirements.

While Subject Matter Experts for user requirements tend to reside in the business operation areas, stakeholders for functional requirements often have technical or system-specific expertise. I approach the elicitation of functional requirements by extending the logical requirement sets formed at the user level.

For each logical set consisting of user role and user goal, and the user inputs and outputs related to each user goal, I ask questions such as the following to elicit functional requirements:

  • When the user does X, what must the system do?
  • What data must be retrieved by the system?
  • What data must be edited or validated by the system?
  • What data-entry errors must the system handle?
  • What exception routines should the system perform?
  • What data must be calculated by the system?

Also like the user requirements, functional requirements are often written in requirements definition documents, use cases, and user stories.

A sentence structure that I find helpful when writing functional requirements is as follows:

The [System Domain] shall {describe functional processing} when {stated event or condition}.

Continuing the logical set of requirements presented in the previous lesson on user requirements, here are some example functional requirements:

  • User Role = Customer
  • User Goal = Add a Contact
  • User Requirement (Input) = The Customer provides “Contact Information”.
  • The Mobile Phone shall present “Missing Required Data Notification” when “Required Contact Information” is absent.
  • The Mobile Phone shall present “Duplicate Contact Notification” when “Contact Name” matches an existing contact.
  • The Mobile Phone shall present “Contact Summary” when “Contact Information” is valid.

In summary, the functional requirement type describes what the system must do to enable the users to perform their goals.

Functional requirements include the following aspects for processing information and materials:

  • Information and Material Transformation
  • Data Validation
  • Computation
  • Error and Exception Handling

The purpose of functional requirements is to support the user. Thus, a good question for eliciting functional requirements is, “When the user does X, what must the system do in response?”

Come join me in the next lesson to explore the nonfunctional requirement type.

Functional Requirements
07:51

This quiz will affirm your understanding of the functional requirement type.

Functional Requirements
7 questions

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.

It’s true. Nonfunctional requirements are vital to the success of developing systems. If nonfunctional requirements are not properly addressed, undesirable results occur such as unsatisfied users, and schedule and budget overruns to correct the system that was developed without the nonfunctional requirements in mind.

I group nonfunctional requirements according to three aspects of the user needs. In this context, the user is any person who comes into contact with the software system. The user contact might occur in the following ways:

  • OPERATION or using the functionality. This user perceives the system as an electronic tool that helps to automate what would otherwise be done manually.
  • REVISION or changing source code or data that drive the system. The user perceives the system as a set of programmed language statements. These statements must be analyzed, modified, and tested as the business changes the way it operates.
  • TRANSITION or managing the upkeep of the system. From this point of view, the system carries similar characteristics as hardware. That is, the user is concerned with aspects such as packaging, transport, and compatibility with other systems.

The three main groups of user needs for software quality are briefly defined here, along with the subdivision of nonfunctional categories within each group.

The OPERATION group describes the user needs for a system that performs or functions well. The operation group subdivides into the following nonfunctional categories:

  • Access Security — how well the system is safeguarded against deliberate and intrusive faults from internal and external sources
  • Availability — how dependable the system is (able to function) during normal operating times
  • Efficiency — how well the software system handles capacity, throughput, and response time
  • Integrity — how well the data are maintained by the software system in terms of accuracy, authenticity, and without corruption
  • Reliability — how well the software system consistently performs the specified functions without failure
  • Survivability — how well the software system continues to function and recovers in the presence of a system failure
  • Usability — how easily the user is able to learn, operate, prepare inputs and interpret outputs through interaction with a software system

The REVISION group describes the user need for a system that is easy to correct when errors occur, and is easy to add on new functions. The revision group comprises the following nonfunctional categories:

  • Flexibility — how easily the software can be modified to adapt to different environments, configurations, and user expectations
  • Maintainability — how easily faults in the software system can be found and fixed
  • Scalability — how well the software system is able to expand its processing capabilities upward and outward to support business growth
  • Verifiability — the extent to which tests, analysis, and demonstrations are needed to prove that the software system will function as intended

The TRANSITION group describes the user need for ease of adaptation to changes in the technical environment. The transition group includes the following nonfunctional categories:

  • Interoperability — how well the software system is able to couple or facilitate the interface with other systems
  • Portability — how easily the software system can be transferred from its current hardware or software environment to another environment
  • Reusability — how easily a portion of the software system can be converted for use in another

So what stakeholders are engaged to define nonfunctional requirements?

Again, similar to user and functional requirements, multiple Subject Matter Experts are necessary to fill the role of Requirement Supplier when eliciting nonfunctional requirements. Subject Matter Experts for the Operation group of nonfunctional categories tend to come from the business operation areas, while Subject Matter Experts for the Revision and Transition groups of nonfunctional categories tend to have technical or system-specific expertise.

Now, let’s look at questions you might ask to elicit nonfunctional requirements.

If you use the three groups that I just described, then there are three questions that kick off the elicitation:

  • For operation requirements, ask, “How well does the system perform for daily use?”
  • For revision requirements, ask, “How easy is it to correct errors and add functions?”
  • For transition requirements, ask, “How easy is it to adapt to changes in the technical environment?”

I could go on and on with suggested questions. However, I provide over 2,000 suggested elicitation questions in my book, The Quest for Software Requirements. Additionally, a downloadable starter set of questions is provided for you on the job aid titled, Elicitation Questions by Requirement Type.

Now, let’s look at a format for writing nonfunctional requirements. The one that I use is as follows: The [System Domain] shall {describe system qualities or environment characteristics}.

Here are a few examples:

  • The Mobile Phone shall maintain all functionality after being submerged in water for less than 60 seconds. (The Mobile Phone will not be damaged if dropped in water and subsequently retrieved in less than 1 minute.)
  • The Mobile Phone shall be self-explanatory and intuitive such that a Customer (age 16 to 80) shall be able to perform a Call Contact function within 30 minutes of encountering the system for the first time.
  • The Mobile Phone shall power off and reboot within 3 minutes when installing system updates.
  • Written requirements like these examples are typically found in common text-based deliverables such as Requirement Definition Documents, User Stories, and stand-alone Nonfunctional Requirement Documents.

With regard to the timing or when to elicit nonfunctional requirements, I feel they can be elicited at any time. That is, although they are considered part of the system-level requirements, they can actually be defined at any time. This is because of their global nature, meaning that they apply to systems as a whole and are not usually traced specifically to a given user role or user goal. For example, nonfunctional requirement categories such as security and safety are often known or thought about already at the business-level requirements when the product or system is first being considered.

In summary, the nonfunctional requirements describe the qualities of the system environment that the user performs in.

Nonfunctional requirements are grouped based on user needs in three areas:

  • Operation, or using the functionality of the system
  • Revision, or changing the source code or data that drive the system
  • And, Transition, or managing the upkeep of the system

At the outset of eliciting nonfunctional requirements, start with these high-level questions:

  • How well does the system perform for daily use?
  • How easy is it to correct errors and add functions?
  • And, How easy is it to adapt to changes in the technical environment?

Finally, I want to close this lesson with one more piece of advice. Errors of omission or failing to properly account for nonfunctional requirements are generally acknowledged to be among the most expensive errors and the most difficult to correct following the implementation of a system. So my advice is, pay more attention to nonfunctional requirements.

Come join me in the next lesson for the conclusion of the requirement type module.

Nonfunctional Requirements
14:18

This quiz will affirm your understanding of the nonfunctional requirement type.

Nonfunctional Requirements
10 questions

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

Here is a summary of the purpose of each requirement type:

Business Requirements define the business value and scope of the project initiative and system under development.

User Requirements define who and what interacts with the system (user role), the reason for the interaction (user goal), and identify the information and materials that are inputs to and outputs from the system.

Functional Requirements define what processing the system does to support the functions performed by the user roles.

Nonfunctional Requirements define the qualities of the system environment that the user performs in or interacts with.

I know some of you are still wondering why we need to define requirements using a classification such as these four types. If everyone spoke the same language and thought the same things, we probably wouldn’t need to classify the requirement types. However, people do think differently and speak differently and so on.

So, as best practices go, the requirement types help us to:

  • Have a common understanding of purpose
  • Establish clarity and consistency with terminology and communication
  • Improve the effectiveness and efficiency of our process and approach

Come join me in the next module for a detailed explanation of the five stages of the requirements management process.

Requirement Types Conclusion
03:02

The questions in this Quiz are example requirement statements. Using the “Business Requirement” and the “Additional Information” provided below, for each requirement statement, identify the requirement type it most closely resembles as User Requirement, Functional Requirement, or Nonfunctional Requirements.

Business Requirement: The purpose of the Call Center Project is to implement an Interactive Voice Response (IVR) system to allow Customers to inquire on the status of a previously reported claim so that the company improves customer service. 

Additional Information: An Interactive Voice Response (IVR) system is an automated telephone answering system that receives customer calls and handles the call based on the Customer responses to prompted questions. The Customer accesses the IVR system via a telephone using a toll-free telephone number provided by their insurance agent.

Requirement Statements Quiz
10 questions
+
Requirements Management Process Stages
7 Lectures 50:50

We are on a journey to develop good requirements. In module 3, I provided a definition for good requirements as: “A state achieved as an outcome of effectively applying a quality requirements management process in which stakeholders collaborate and derive the same interpretation of the defined requirements, and the requirements accurately reflect the desired business value and user needs.”

A key element of this definition recommends a quality requirements management process be used to iteratively and incrementally develop the requirements. In simple words, software requirements management is the process of studying user needs to arrive at a definition of the software requirements.

In their book, Managing Software Requirements, Dean Leffingwell and Don Widrig define requirements management as:

“A systematic approach to eliciting, organizing, and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.”

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

Before we dive in, let’s talk about the iterative nature of the requirements management process. For training purposes, I am delivering information to you about the process stages in a specific sequence. However, you should not anticipate performing the activities of these stages in a linear, one-time sequence.

The reality is that they are applied iteratively and incrementally.

So what does iterative mean? In the context of the requirements process, iterative means that the process stages are repetitive or repeated.

And, what does incremental mean? Again, in this context, incremental means that as the process is applied, the requirements will accumulate as you go. With each repetition of the process, you will add on to requirements that you defined in previous iterations.

In Module 4 on the Requirements Hierarchy, I explained that the hierarchy guides the top-down approach to applying the process. Using the pyramid to depict the requirement levels, we can overlay the model to illustrate the iterative and incremental application of the process stages at each level of requirements. The process is applied first at the business requirements level, and next to the user level, and then to the system-level requirements.

Finally, I’m all for using a variety of ways for presenting this material to appeal to the different learning styles that my audience prefers. So here’s a story that might appeal to your learning preference.

A few years ago I was delivering my popular 3-day training course. On the morning of day 3, we were in the middle of a hands-on exercise designed to bring together all of the components presented in the first two days. The exercise was designed to help the student feel the iterative nature of the process as we applied the approach to a case study.

I’ll never forget the expression made by one of my students as the light-bulb or ah-ha moment hit her. She said excitedly, “Oh, Roxanne, I finally get it. You’re E-A-R-V-ing.”

What? She said it again, “You’re E-A-R-V-ing. You are eliciting, analyzing, representing, and validating the requirements at each level in the requirements hierarchy.”

Come join me in the following lessons to learn about the tasks that are performed in each of the process stages.

Requirement Management Process Introduction
07:02

Requirements Management Process Quiz
6 questions

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.

Following are three primary tasks performed in requirements elicitation:

IDENTIFY STAKEHOLDERS. The goal of this task is to identify individuals and groups that can represent the business areas and user roles affected by the scope of the initiative. In essence, you want to identify the Requirement Suppliers and Requirements Receivers needed to effectively articulate, represent, and validate the requirements for the system under development. The value of getting the right stakeholders engaged is so important that I produced a 2-hour Extension Course on Stakeholder Profiling to help you master this technique.

IDENTIFY SOURCES FOR REQUIREMENTS. The goal of this task is to identify people, places or locations, and things where requirements may be elicited from. Following are sources that you might consider:

  • Enterprise analysis to gain an understanding of the current state of the business process. This is usually done by creating a variety of models that help people “see” their business.
  • Requirements documents for current systems. Searching requirements specifications from previous projects can uncover potentially reusable material, thus saving time and duplication of effort.
  • Problem reports and enhancement requests for a current application.
  • Form analysis relies on the communication channels in the organization. A form is simply a way to structure data entry and retrieval.
  • Business artifacts such as training manuals, end-user documentation, and procedure guides are all good sources for requirements information.
  • Marketing surveys and user questionnaires. These are great techniques to use when there is a very broad audience of stakeholders with little or no opportunity (usually due to time and cost) to elicit from all of them.
  • Observing users at work. Observation may be performed in an active-visible manner (the observer is actively interjecting questions while the user is working) or a passive-invisible manner (the observer is silent and non-intrusive).
  • Experiencing life as a user. Figuratively, walk in the user’s shoes for a day. This is only possible when the work is not too complex or dangerous to be taken on by a novice. Working with users can help you understand the problems they encounter.
  • Scenario analysis of user tasks. In the most general sense, a scenario is a step-by-step account of what an end-user does to achieve a desired goal. A set of logically-related scenarios (associated to the same user goal) can help the development team see the big picture of the work performed.
  • Interviews and discussions with end-users and stakeholders. This is the most direct way to find out what the users need—ask them. While there are many elicitation techniques to choose from, I produced an Extension Course on the Elicitation Interview because this technique is the most frequently applied.
  • Workshops with a group of stakeholders. A workshop brings the right collection of people together, and enables participants to contribute in building the requirements deliverable.

ELICIT REQUIREMENTS. The goal of this task is to apply a variety of techniques to discover requirements from the stakeholders and other sources that were identified in the previous two tasks. Common techniques that may be used include brainstorming, document analysis, requirements workshops, elicitation interviews, user observation, questionnaires, and prototyping.

While there are many elicitation techniques to choose from, I produced an extension course on the Elicitation Interview because this technique is the most frequently applied. When properly prepared and executed, the elicitation interview can be a highly effective means of discovering requirements, and is a great way to build rapport and develop trust with stakeholders.

To summarize, the requirements elicitation stage is about getting the stakeholders and sources for requirements together, and applying a variety of techniques to bring the requirements into focus. The primary tasks included in the elicitation stage are to identify stakeholders, identify sources for requirements, and elicit the requirements.

Come join me in the next lesson to learn about Requirements Analysis.

Preview 07:33

This quiz will affirm your understanding of the Requirements Elicitation stage of the Requirements Management Process.

Requirements Elicitation
7 questions

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.

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.

Following are four primary tasks performed in requirements analysis:

DOCUMENT ASSUMPTIONS. Some people struggle with this task. They admit that they make assumptions. However, they are challenged by recognizing when assumptions are made and getting them written for others to confirm. The reason for documenting assumptions is to have the stakeholders validate the assumptions as true. If the assumptions are false or wrong, then it is highly likely that the requirements developed with the assumptions in mind, are also wrong or incorrect.

IDENTIFY CONSTRAINTS. I refer to constraints as limitations. That is, constraints put limits on what the development team can build. Constraints are common on projects where an existing system is being enhanced. Often the constraints are necessary due to the current functionality or technology incorporated in the existing system.

IDENTIFY DEPENDENCIES. I refer to dependencies as show stoppers. I consider anything that in the absence of, the requirements could not be successfully implemented.

PRIORITIZE THE REQUIREMENTS. Requirements workshops are a good technique to employ for this task as they help the stakeholders to collaborate. For successful collaboration it is important to use a meaningful prioritization ranking scheme. A ranking scheme such as must have, should have, and nice to have, is generally going to bring greater consistency to the prioritization outcome than a ranking scheme such as high, higher, and highest, which is one that my client seems to favor.

To summarize, the requirements analysis stage is about sifting, sorting, and clarifying the requirements information gathered in preparation for the representation stage. The analysis stage is the time and place to look for and resolve inconsistencies between the requirements.

Come join me in the next lesson to learn about Requirements Representation.

Requirements Analysis
04:03

This quiz will affirm your understanding of the Requirements Analysis stage of the Requirements Management Process.

Requirements Analysis
6 questions

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.

The objective of the representation stage is to assemble and format the elicited and analyzed requirements into graphical and textual deliverables in preparation for stakeholder validation. Every project is unique, and the stakeholders from project to project will change. The goal of the requirements management process is to obtain one, and only one, consistent interpretation of the requirements by all stakeholders involved.

Therefore, the goal of the representation stage is to find the right combination of visual deliverables that help the stakeholders to derive a common understanding of the requirements. I frequently say: there is more than one right way to represent requirements, but only one right interpretation.

Let’s look at the two primary tasks performed in requirements representation:

CREATE GRAPHICAL MODELS, PROTOTYPES, AND VISUAL REQUIREMENTS. Did you know that over 65% of the adult population prefers visuals to take in information? I admit that I’m definitely in that majority group. I prefer a picture over reading text any day of the week. What I’m saying is that there is a good probability that the audience of the requirements will appreciate seeing the requirements as a picture, model, or visual graphic. So turn everything that you can into a picture. Even when there is a lot of text to communicate, it is best to organize and present it in a table or similar structure.

WRITE TEXTUAL REQUIREMENTS. For each of the four requirement types presented in module 5, I recommended a written sentence format. These formats improve communication effectiveness by presenting requirements in a consistent manner. Additionally, I indicated common text-based deliverables that contain written requirements such as Requirements Definition Documents, Use Cases, and User Stories.

So perhaps you’re wondering how much detail should be included when representing requirements.

Determining the level of detail and specificity that may be represented in the requirements depends upon the following considerations:

  • The experience level of the intended audience
  • The synergy of the stakeholders and their capability to collaborate as a team
  • The development approach such as Waterfall or Agile.

For example, I may include more details in my requirements representation if:

  • The audience is not familiar with the business or the technology of the system under development
  • This is the first time I’m working with this particular development team
  • My audience is located remotely and my interaction occurs over a longer duration of time and with lower frequency
  • There are language barriers or other communication challenges

My advice for determining the level of detail is to know your audience. Also, there’s no such thing as perfect requirements. When it comes to written requirements, you are aiming for good enough.

To summarize, the requirements representation stage is about developing models and text deliverables that will convey a clear, concise, and consistent understanding of the requirements to all stakeholders.

Come join me in the next lesson to learn about Requirements Validation.

Requirements Representation
05:39

This quiz will affirm your understanding of the Requirements Representation stage of the Requirements Management Process.

Requirements Representation
8 questions

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.

The objective of the validation stage is to conduct reviews of the requirements with the stakeholders.

Following are four primary tasks performed in requirements validation:

REVIEW QUALITY CHARACTERISTICS. If a perfect requirements definition document could exist it would have the following attributes of well-written requirements:

  • Complete. The requirements deliverable is complete if it states all the conditions under which the set of requirements apply. In other words, the deliverable is complete if it: (a) states all that the software is supposed to do, (b) defines all the responses of the system to every realizable situation, (c) all the pages are numbered and all tables and figures are inserted, and (d) no sections contain placeholders such as To Be Determined.
  • Correct. The requirements deliverable is correct if every requirement stated therein represents something required of the system being built.
  • Consistent. The requirements deliverable is consistent if (1) no requirement stated therein is in conflict with other requirement deliverables, and (2) no subset of requirements stated therein conflict. There are four aspects of inconsistencies that you can look for: (a) conflicting behavior, (b) conflicting terms, (c) conflicting characteristics, and (d) temporal inconsistency.
  • Unambiguous. The requirements deliverable is unambiguous if every requirement stated therein has one, consistent interpretation by all the stakeholders.
  • Organized. The requirements deliverable is organized if requirements contained therein are easy to locate.
  • Modifiable. A requirements deliverable is modifiable if its structure and style are such that any necessary changes to the requirements can be made easily, completely, and consistently.
  • Verifiable. A requirements deliverable is verifiable if requirements statements therein can be verified. That is, there must be a cost effective process with which a person or machine can check that the as-built software meets the requirement.
  • Traceable. A requirements deliverable is TRACED if the origin of each of its requirements is clear. A requirements deliverable is traceable if the requirements therein are all referenced to the components such as design elements and tests that satisfy the requirements.

A summary of these attributes of well-written requirements is included in the downloadable job aid titled Tips for Writing Good Requirements. You can read about these attributes in Alan Davis’ book, Software Requirements: Objects, Functions, and States.

ELIMINATE AMBIGUITIES. Differences in language and terminology can make writing requirements a challenge. The goal is to achieve a consistent interpretation of the requirements. Following are aspects of written requirements that can cause ambiguity:

  • Precedence Relationships. This ambiguity can occur when you need to group requirements into a specific order or sequence.
  • Dangling Else. Developers or programmers often use an if-then-else format when writing source code. While the if-then-else format can be an effective analysis technique, it often causes ambiguity in written requirements when one or more components of the if-the-else are absent.
  • Negation. Words such as no, not, none, and without are challenging for people to interpret. It is best to avoid negation if at all possible.
  • Temporal References. Even with standard time zones, references such as morning, afternoon, and local time can cause ambiguity.
  • Boundary References. Boundary limits are a common cause of ambiguity. It is a challenge to accurately include the start and end points. For example, the customer will receive a 10% discount when the total purchase amount is greater than $100. What if the customer’s total purchase amount is exactly $100, should they get the 10% discount?
  • Statement Grammar. Verbs, adjectives, and adverbs! Oh, my! Need I say more?
  • Logical Operators. Words such as AND and OR are used to combine and compare components. These are not your friend in written requirements.
  • Acronyms. The use of acronyms is a form of abbreviation and should be avoided.
  • I.E. versus E.G. To better understand the cause of this ambiguity, we have to look at the definition of each term. I.E. is an abbreviation for THAT IS. When used at the beginning of a list, I.E. means that the items that follow are the complete list. On the other hand, E.G. is an abbreviation for FOR EXAMPLE. When used at the beginning of a list, E.G. means that the items that follow are a partial list. Lots of people either simply don’t know the difference between I.E. and E.G., or are easily confused by them. At any rate, both are abbreviations and should be avoided.

TRACE THE REQUIREMENTS. Traceable is one of the attributes of well-written requirements mentioned previously. Each requirement statement should be traced to the originating component, and be traceable to all the components that satisfy the requirement. Techniques to accomplish this include numbering every paragraph, assigning a unique label to each requirement statement, and using a standard convention for indicating a requirement.

CONDUCT REQUIREMENT REVIEWS. The goal of the review is to identify requirements that are incorrect, incomplete, or ambiguous. The goal is not to beat up on the person who wrote the requirements. And, the person who wrote them shouldn’t take it as a personal attack when errors are identified. Keep in mind that everything you find is easier and cheaper to correct during requirements development compared to the cost of rework when missed requirements are corrected during system development and testing.

I use a proven technique that I named Ink-Free Sign-Off for reviewing requirements. A detailed explanation of the technique is presented in the Extension Course titled, Reviewing Requirements: Ink-Free Sign-Off.

To summarize, the requirements validation stage is about the stakeholders collaborating to review the defined requirements. The challenge is reviewing the requirements to discover what was overlooked or missed. It is hard to see what isn’t there. The fear of missed requirements has caused more than a few Requirement Producers to lose sleep.

Come join me in the next lesson to learn about Requirements Change Control.

Requirements Validation
11:33

This quiz will affirm your understanding of the Requirements Validation stage of the Requirements Management Process.

Requirements Validation
10 questions

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.

The purpose of the change control stage is to anticipate and accommodate changes in the requirements in a way that minimizes disruption to the development of the system. The objectives of the change control stage are to define a requirements baseline, follow a process for evaluating the best way to accommodate proposed changes, and update and maintain requirement deliverables to reflect accepted changes.

Whether your project is following a predictive development approach, an agile approach, or any other, managing changes to requirements is an essential stage of the requirements management process. Effective change control helps the stakeholders to have realistic expectations during the development process. In other words, a change control process helps you to know where you are going, the progress you are making, and when you have arrived at your destination.

Organizations understand that the requirements will change. It is virtually impossible to define all of the requirements for a system upfront. Business needs will change as they respond to new market opportunities, regulations, and policy changes.

Software change is not a bad thing. Rather, it is necessary. An effective development team is one that can quickly respond to necessary changes so that they build a solution that delivers user value in a timely manner.

Nonetheless, change always has a price. Even rejecting a proposed change has a cost because of the time invested in submitting, evaluating, and rejecting the change. Effective change control practices can reduce stakeholder frustration, rework, and wasted time. Unless the stakeholders manage changes during development of the system, they won’t really know what is going to be delivered, and risk huge gaps in expectations.

Now, let’s look at three primary tasks performed in requirements change control.

BASELINE ACCEPTED REQUIREMENTS. I define a baseline as a snapshot in time of a set of requirements that the stakeholders have reviewed and accepted. The set can be an entire requirements definition or any partial subset thereof. A baseline typically follows requirements validation where the requirements have been reviewed and accepted. However, it can occur at any time provided the stakeholders are in agreement. Once a baseline is agreed, any subsequent changes to the baselined requirements will follow the change procedures defined by the project team. Prior to the baseline, the requirements are still developing, and imposing the change control procedures would be unnecessary process overhead.

APPLY CHANGE CONTROL PROCESS. An effective change control process allows the following activities to occur:

  • Change Request Submission. Procedures are necessary that outline who can submit a request for change and the timing for and conditions under which the request can be made. A Change Request is a term used to identify a form that is typically completed and submitted by the change initiator.
  • Track and Monitor Change Requests. The submitted Change Request will follow a defined process, and will undergo many states or statuses as the Change Request transitions or moves through the process. These states are a vital component for communicating the progress of the Change Request. Common statuses include Proposed, Analyzed, Approved, Deferred, Rejected, Implemented, Verified, and Closed.
  • Impact Analysis. The submitted request for change must be analyzed to determine the overall impact that the change may have on developing the system.
  • Review and Approval. The review of the impact analysis is performed by an assigned group of stakeholders often called a Change Control Board. These stakeholders are responsible for and have authority for making decisions to approve or reject requests for change.
  • Implementation and Verification of Approved Changes. Effective requirements tracing helps to ensure that all components of the system that are affected by the approved change are properly modified to encompass the change, and subsequently verified.
  • Closure and Communication. The change control process should have procedures for reporting the status of Change Requests to all affected Stakeholders, as well as procedures for closing a request for change. Closure procedures should be established regardless of the decision outcome to approve or reject a change.

MAINTAIN REQUIREMENTS. Maintaining documentation is seldom anyone’s favorite task. However, maintaining a record of implemented changes and updating requirements deliverables to incorporate approved changes, improves the value of the requirements for reuse on future projects. Updating requirements trace information is good practices that will benefit the stakeholders and project team of the system being developed.

To summarize, the requirements change control stage is about effectively responding to requests for change, and following procedures that ensure requests are properly evaluated to enable stakeholders to make informed decisions regarding the approval or rejection of requests for change. A quality change control process improves team communication and helps to maintain stakeholder expectations about the system being built.

If you would like more information about effective requirements change management and the details of a change control process, I recommend reading the chapters in Part Four of Software Requirements, 3rd edition, by Karl Wiegers and Joy Beatty.

Come join me in the next lesson for a discussion on the benefits of applying a requirements management process.

Requirements Change Control
09:04

This quiz will affirm your understanding of the Requirements Change Control stage of the Requirements Management Process.

Requirements Change Control
6 questions

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 cannot give you an equation to calculate the return on investment for implementing a quality requirements management process. Nonetheless, I can confidently say that good requirements save you time and money. There is a cost to poorly defined and missed requirements. There is a cost to development rework because a requirement was overlooked. And, yes, business opportunities are lost because the customer doesn’t like the product or system.

So let’s discuss the benefits of applying a requirements management process by aligning the benefits with six key business objectives.

  • SATISFY CUSTOMER NEEDS. A requirements management process helps to promote a complete, clear and correct definition of the business requirements. The process enables the project team to fully understand and meet the needs of customers the FIRST time. And, it enables early identification of missing requirements and requirement deficiencies, ambiguities, and errors.
  • MEET PROJECT DEADLINES. A requirements management process helps to provide the method for controlling and prioritizing requirements, which form the basis for creating an accurate project schedule. A process also allows identification of requirement changes that may affect the schedule. And, a process reduces scope creep by communicating any changes, and obtaining agreement on project schedule changes.
  • LOWER PROJECT COST. A requirements management process helps to manage cost by reducing extraneous features, and reduces rework by involving business owners and development team members in a formal validation of the requirements early in the project life cycle. A process provides the means to more accurately estimate timeframes and work estimates.
  • PROMOTE COMMUNICATION. A requirements management process provides a common understanding of where and how requirements documents are to be managed, which promotes and supports reuse. The process promotes full definition, including the use of supporting information. It offers a formal process for proposing and managing changes to requirements, and promotes discussing and investigating the impact of changes prior to making them. A process also improves communication between team members and business owners or customers through a formal requirements review process, which helps to ensure customer needs can be met the first time.
  • MAINTAIN A PRACTICAL PROJECT SCOPE. A requirements management process promotes tracking relationships between requirements to aid in impact analysis on proposed changes. A process helps to keep the project team focused on the goals of the project.
  • COMPLIANCE WITH CERTIFICATION STANDARDS such as ISO and Capability Maturity Model Integration (CMMI). A requirements management process provides guidelines for documenting requirements in a consistent manner, allows analysis of requirements and requirement relationships, and drives the use of requirements as a basis for solid application development and testing.

In the next module, Requirements Approach, you will gain a better understanding of how the requirements management process is iteratively applied.

Come join me in the next module.

Benefits of Applying a Requirements Management Process
05:56

Requirements Management Process Quiz
5 questions
+
Requirements Quest Approach
4 Lectures 20:42

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.

While the approach is presented and summarized here in a linear, sequential manner, it is almost never applied as such. In the previous modules of this course, I have stated that the requirements management process is iterative and incremental. Iterative means that the process is repetitive. Incremental means that the requirements accumulate as the process is applied using the top-down approach through the three levels of the requirements hierarchy.

The five stages of the requirements process including elicitation, analysis, representation, validation, and change control are first iteratively applied at the business requirements level. Incrementally building upon the business requirements, the process stages are then iteratively applied at the user-level requirements. Finally, incrementally building upon the business and user requirements, the process stages are iteratively applied at the system-level requirements.

As statistician George Box famously said, “All models are wrong, but some are useful.” I know that this approach isn’t perfect and may not work on every project. However, it has proven to be useful on so many of my own projects and those of my clients that I am confident it can help you successfully define requirements for yours.

The requirements approach consists of 3 primary objectives:

  1. Define the business-level requirements
  2. Define the user-level requirements
  3. Define the system-level requirements

These primary objectives are accomplished through 12 activities, which are identified here and summarized in the subsequent lessons that follow. A detailed examination of the approach occurs in the course titled Requirements Quest Approach. Activities included in defining the business-level requirements are:

  •   Review Existing Business Artifacts
  •   Conduct Scope Interview
  •   Perform Stakeholder Profiling
  •   Model the Requirements Scope
  •   Confirm Business Requirements
    Activities included in defining the user-level requirements are:
  • Identify Logical Requirement Sets
  • Prioritize Logical Requirement Sets  
  • Plan Stakeholder Utilization
  • Define User Requirements

Activities included in defining the system-level requirements are:

  • Define Functional Requirements
  • Define Nonfunctional Requirements

Come join me in the next lesson for an overview discussion on the activities for defining the business-level requirements.

The Requirements Quest Approach Introduction
05:47

This quiz will affirm your understanding of the Requirements Quest Approach.

The Requirements Quest Approach (Intro)
5 questions

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 are 5 activities included in defining the business-level requirements:

The first activity is REVIEW EXISTING BUSINESS ARTIFACTS. The objective of this activity is to gain a better understanding of the initiative, and identify and gather potential sources for requirements. Examples of business artifacts that I look for are project charter, vision statement, process models, and past project deliverables.

The next activity is CONDUCT SCOPE INTERVIEW. The objective of this activity is to understand the scope of the initiative and the business benefits for doing the project. This is typically an interview with the Project Sponsor or Product Owner. The goal is to draft a visual model of the scope of the initiative, which shows the business areas, processes, and roles affected. I also like to get a jump on the upcoming activity by asking about potential stakeholders.

PERFORM STAKEHOLDER PROFILING is the next activity in defining the business-level requirements. The objective of this activity is to identify the business and technical knowledge needed, and the potential stakeholders that have the level of knowledge required. I want to minimize the risk of missed requirements by engaging the right people.

The next activity is MODEL THE REQUIREMENTS SCOPE. The objective of this activity is to create visual models to depict the affected business entities, business processes, and user roles. Four models that I consider core to this activity are Relationship Map, Process Map, Context Diagram, and Use Case Diagram.

And the last activity is CONFIRM BUSINESS REQUIREMENTS. The objective of this activity is to confirm what the project team is expected to deliver, and the business benefits for the initiative. A key output of this activity is the written business-requirement-type statement such as the following, “The purpose of the project…is to…so that…” I explained the business requirement type in Module 5. Business requirements are frequently represented in deliverables such as Project Charter and Business Case, but may also be found in a Requirements Definition document.

Come join me in the next lesson for an overview discussion on the activities for defining the user-level requirements.

Business-Level Activities
04:28

This quiz will affirm your understanding of the business-level activities in the Requirements Quest Approach.

Approach: Business-Level Activities
5 questions

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 are 5 activities included in defining the user-level requirements:

The first activity is IDENTIFY LOGICAL REQUIREMENT SETS. The objective of this activity is to organize the requirements information into sets by system domain, user role, and user goal. This organization helps to estimate and plan the requirement tasks and techniques. The sets also help to communicate with and engage stakeholders in a timely manner.

The next activity is PRIORITIZE LOGICAL REQUIREMENT SETS. The objective of this activity is to facilitate stakeholder collaboration to create prioritized requirement sets. The prioritized requirement sets help to estimate and plan requirement tasks.

PLAN STAKEHOLDER UTILIZATION is the next activity in defining the user-level requirements. The objective of this activity is to identify stakeholder availability, negotiate for needed stakeholders, and plan for stakeholder engagement. The aim of this activity is to make good use of time with stakeholders who often have very limited time to give.

The next activity is PLAN REQUIREMENTS TASKS AND TECHNIQUES. The objective of this activity is to identify, estimate, and schedule the requirements tasks. Frequently used techniques include Requirement Workshops, Elicitation Interviews, Requirement Reviews, and Modeling and representing the requirements.

And the last activity is DEFINE USER REQUIREMENTS. The objective of this activity is to confirm the user roles, user goals, and inputs and outputs of information or materials needed to achieve the user goals. Key outputs of this activity are the written user-requirement-type statements such as, “The user role provides input,” and “The user role receives output.” In the context of a user interacting with a Mobile Phone as the system domain, and the user goal of Add a Contact.  An example user requirement is, “The Customer provides Contact Information.” Written user requirements are frequently represented in Requirements Definitions, Use Cases, and User Stories.

Come join me in the next lesson for an overview discussion on the activities for defining the system-level requirements.

User-Level Activities
04:23

This quiz will affirm your understanding of the user-level activities in the Requirements Quest Approach.

Approach: User-Level Activities
5 questions

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.

The system level includes functional and nonfunctional requirements. 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. Therefore, two primary activities included in defining the system-level requirements are define functional requirements and define nonfunctional requirements.

Let’s start with DEFINE FUNCTIONAL REQUIREMENTS. Functional requirements describe functionality that must be built into the system to enable the users to perform their goals or tasks. Functional requirements identify the processing that the system must perform on the inputs of information and materials to prepare and present outputs of information and materials.

Functional processing is concerned with information and material transformation, data validation, computations, and error and exception handling. The key outputs to this activity are the written functional-requirement-type statements such as, “The System Domain shall describe processing when condition.”

FOR EXAMPLE:  The Mobile Phone shall present Duplicate Contact Notification when Contact Name matches an existing contact.

Functional requirements are often found in Requirements Definitions and Use Cases.

Now, let’s turn our attention to DEFINE NONFUNCTIONAL REQUIREMENTS. Simply defined, a nonfunctional requirement is a specification of HOW WELL a software system must function.

You may recall from the discussion in Module 5 that nonfunctional requirements are classified into three groups:

  • Operation, or using the functionality of the system. Nonfunctional categories included in the Operation group are Access Security, Availability, Efficiency, Integrity, Reliability, Survivability, and Usability.
  • Revision, or changing the source code or data that drive the system. Nonfunctional categories included in the Revision group are Flexibility, Maintainability, Scalability, and Verifiability.
  • Transition, or managing the upkeep of the system. Nonfunctional categories included in the Transition group are Interoperability, Portability, and Reusability.

Key outputs of the Define Nonfunctional Requirements activity are the written nonfunctional-requirement-type statements such as, “The System Domain shall describe system qualities or environment characteristics.”

FOR EXAMPLE:  The Mobile Phone shall power off and reboot within 3 minutes when installing system updates.

Nonfunctional requirements are often found in Requirements Definitions. I’ve also seen them written as acceptance criteria for User Stories. Furthermore, due to their global nature, it is common to capture them in a stand-alone Nonfunctional Requirements Definition.

To conclude, let’s summarize what you learned in this training module. In essence, the activities of the requirements approach support the iterative and incremental sub-processes for eliciting, analyzing, representing, validating, and managing changes to requirements for each level of the requirements hierarchy.

Come join me in the next module for a discussion of what are not requirements.

System-Level Activities
06:04

This quiz will affirm your understanding of the system-level activities in the Requirements Quest Approach.

Approach: System-Level Activities
5 questions
+
What Requirements Are Not
5 Lectures 17:08

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

These elements are discussed in the subsequent lessons that follow.

Before we can effectively explore the elements that should be excluded in specifying requirements, let’s look at the elements that are recommended for inclusion in a requirement specification. My favorite detailed explanation of the contents of a requirements specification is found in Stephen Withall’s book, Software Requirement Patterns.

Withall recommends an introduction section that includes a purpose statement, purpose of the document, format of requirement definitions, glossary, references, and document history. The introduction is followed by a content section and includes scope, assumptions, exclusions, key business entities, and infrastructure.

Following the introduction and content sections there are appropriate placeholders for functional and nonfunctional requirements. Although it may not be obvious, it should be noted that visual representations of the requirements can be attached as supporting artifacts for the written requirements.

Come join me in the next lesson for a discussion on WHAT versus HOW.

Contents of a Requirements Specification
02:59

This quiz will affirm your understanding of typical contents of a Requirements Specification deliverable.

Contents of a Requirements Specification
3 questions

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.

Therefore, requirements are frequently referred to as the WHATs.

On the other hand, HOWs typically describe the design elements or the way in which the system will be constructed. HOW will the information or material be presented to the user? HOW will the system receive, store, and retrieve the information that is desired?

The HOW’S are the solutions to providing WHAT is needed.

For example, during requirements-gathering interviews, I will often hear a Subject Matter Expert say that they want a new screen or report. The screen or report is the HOW. That is, the screen or report is the means by which the desired information is presented to the user. The information displayed on the screen or printed on the report is WHAT the user really needs to perform their role or achieve their user goal.

Certainly, legitimate constraints may dictate that the solution be delivered via a screen or a report. Still, the screen and report are HOW, not WHAT. It is absolutely essential that the solution team first correctly identify WHAT is needed before a solution is designed and constructed.

Come join me in the next lesson to better understand the project-related information and tasks that should be excluded from requirement specifications.

Why and What Versus How
03:08

This quiz will affirm your understanding of the exclusion of design elements from a requirements specification.

Why and What Versus How
3 questions

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.

Project-related information includes:

  • Budgets
  • Schedules
  • Implementation plans
  • Release plans
  • Verification plans
  • Project Task lists
  • Risk Management plans

Project-related items like these are often packaged with the requirements documentation for the convenience of any number of project team members in an attempt to centralize information. In general, this must be strictly avoided since changes in the project-related information increases the quantity of document versions and fosters the tendency for the requirements to be out of date. This compromises the integrity of the requirements as they become less trustworthy and more likely to be ignored.

Moreover, the inevitable debates that occur regarding the project-related information should be separated from discussions on what the system is supposed to do. There are different stakeholders that must contribute and participate in the discussions, and the purpose of each discussion is significantly different.

Essentially, if the information doesn’t focus on describing the functionality or behavior of the system or the quality attributes or constraints of the system environment, then the information doesn’t belong in the requirements specification.

Exclude Project-Related Information
02:43

This quiz will affirm your understanding of the exclusion of project-related information from a requirements specification.

Exclude Project-Related Information
3 questions

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.”

Almost every business in the world has business rules, but the degree in which the rules are documented and accessible vary greatly. The following are examples of business rules related to paying employees:

  • An employee is entitled to four weeks of paid vacation following their tenth consecutive year anniversary of full-time employment.
  • An employee with at least one month of employment is entitled to company-paid holidays.
  • Employees are paid bi-monthly with 24 pay periods in a calendar year.

While business rules represent the management decisions and policies relating to the operations of the business, requirements relate to a specific application or system domain that is being considered or developed, which usually automates the business processes. Requirements are documented at a specific point in time to define what changes are necessary in the specific application or system domain to enforce any changes in the business rules. Therefore, you will generally derive functional and nonfunctional requirements from business rules in order to enforce the rules or support the regulations and standards that govern the operation of the business.

Let’s say, for example, that an organization currently has an automated system to process payroll. The current system, whether a purchased software package or an in-house developed application, is processing according to business rules that dictate 24 payroll periods. That is, employees are paid bi-monthly on the 1st and 16th day of the month with additional rules to handle non-business processing days throughout the year such as holidays and weekends.

Continuing the example, executive leadership of the organization makes a decision to purchase a new payroll system. A Payroll Project is planned and launched to convert from the current system to the new system. Executive leadership has also decided to change the number of payroll periods from 24 to 26. The new business rule is to process payroll on a bi-weekly basis every other Friday, and again, taking non-business days into account. The new business rule will take effect upon installation of the new system.

The requirement specifications created for the Payroll Project will detail all the changes necessary to convert payroll processing from 24 to 26 pay periods. These detailed requirements will describe the necessary changes to processes, sub-processes, procedures, calculations, event triggers, error and exception handling, and so on. The functional requirements describe what the new payroll system must do, and the nonfunctional requirements describe how well it will do it.

When the new system is operational, the requirement specifications for the Payroll Project are archived. The business rules governing the payroll processing remain in effect. That is, business rules live beyond the lifecycle of a project, whereas the requirement specifications are relevant only for the duration of the project initiative.

A close relative of business rules that should also be excluded from requirements specifications are standards. Standards are the written or unwritten business rules, regulations, and/or contracts that dictate the business operations. Standards are typically set by upper management to guide the day-to-day business decisions.

Standards are the required level of quality that the product or system must measure against or comply with. Standards are often imposed on a business by external government or regulatory agencies. In these instances, the imposed standards must be adopted by the business as business rules (whether they like it or not). If the business does not operate within compliance of these forced business rules, the business risks going out, or being put out, of business.

Now, let’s conclude this module by summarizing the elements that should be excluded from requirement specifications.

  • Design or other components that describe HOW to implement a solution to the requirements
  • Project-related information such as budgets, schedules, and risk-mitigation plans
  • Business Rules and Standards that govern the day-to-day operations of the business
Business Rules Are Not Requirements
07:50

This quiz will affirm your understanding of the exclusion of business rules and standards from a requirements specification.

Business Rules are Not Requirements
3 questions

Thanks again for purchasing the Requirements Fundamentals course!  Roxanne invites you to connect with her, and to visit the Requirements Quest website for free resources.

BONUS: Connect with Roxanne; Access FREE Resources
00:28
About the Instructor
Roxanne Miller, CBAP
3.7 Average rating
43 Reviews
1,218 Students
2 Courses
Requirements Super Freak; Industry Keynote Speaker, Author

Industry expert and the Requirements Super Freak, Roxanne Miller is a Certified Business Analysis Professional (CBAP) and an engaging, passionate requirements coach, mentor, and trainer. Roxanne's popular book, The Quest for Software Requirements, is a first-of-its-kind reference guide that helps business and IT individuals master the elicitation of hard-to-identify and vital nonfunctional requirements. A companion file, Software Requirements Questions, contains the 2000+ elicitation questions included in the book (sold separately).

Roxanne has been involved in the Information Technology (IT) industry since 1984 and founded Requirements Quest® in 2001. Roxanne is committed to bringing your business into focus®! She has been consulting on requirements process improvement and business analysis practices for over 20 years. As principal consultant and lead instructor at Requirements Quest, Roxanne has consulted, mentored, and delivered live training to over 5,000 business analysts worldwide. Roxanne earned a bachelor degree in Management Information Systems (MIS) at the University of Wisconsin—Eau Claire, Eau Claire, Wisconsin, USA.