Please find below a transcription of the audio portion of Walter Stinnett’s session, Introduction to Requirements Management, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this webinar at your convenience.
Hello, my name is Walter Stinnett. And welcome to the first of three webinars on Project Requirements Management. In this first presentation, I will be giving an overview of requirements management. In part two, I will be delving deeper into this topic by discussing the process of collecting and writing requirements. And then finally, we will be ending up with a discussion on monitoring and controlling requirements. So, thank you for joining us today on this webinar, and let’s get started.
So, our topic for this particular installment is, An Introduction to Requirements Management. Our lesson objectives will be the following. We’re going to define requirements. We’re going to delineate between different types of requirements. We’re going to identify why requirements are essential to the project success. And then we’re going to define the importance of stakeholders in the requirements management process.
Before we start, I have provided some quiz questions. And as I read through them, keep them in mind. And hopefully, by the end of the presentation, you’ll be able to answer these correctly. So, the first question is, user stories are written from the perspective of the? Question number two, waterfall methodologies are best suited for what level of requirements uncertainty? Question number three, why are requirements captured?
The next question, in a highly predictive life cycle requirements are? And the next question, which stakeholder group is closest to a solution? Successful projects meet the needs of stakeholders only at the beginning of the requirements cycle, true or false? What are the benefits of a requirements management plan? Requirements are defined as? So, hopefully you’ll be able to answer these questions.
So, let’s begin the presentation. Every year, The Project Management Institute has a survey called the Pulse of the Profession. And in this particular year, which was 2017, they found that 47% of unsuccessful projects failed to meet original goals due to poor requirements. And 39% of failed projects identify inaccurate requirements gathering as a primary cause of failure. So, while this is in 2017, it might still be applicable to today. I haven’t been able to find, not that there isn’t, but I haven’t been able to find statistics in this manner for ’20 and ’21. But this really shows you the importance of requirements. Because look, 47% of unsuccessful projects fail to meet original goals due to poor requirements.
In fact, in 2019 11.9% of every dollar was wasted due to poor project performance. Now, think about that. That is $119 million for every $1 billion invested. Not only that, but 37% of completed projects experienced scope creep.
Now, in this study, it was determined that the top reasons for project failure were, listen to this. Now, as I say these, these aren’t in any particular order, but just think about this and think about your organization. Think about your projects. Do they experience any of these issues? One, change in organizations priorities. Two, change and project objectives. Three, erroneous requirements gathering. And fourthly, inaccurate cost estimates.
So, when I look at that list there, I think in actuality, each of those is related to requirements. So, we can see if the importance of what requirements are for a project. And if there’s any type of faulty requirements gathering, any type of issues with that, how that can negatively impact your project’s success.
So, why capture requirements? So, let’s just look at this here for just a moment. First of all, we talk about communication. Requirements if they are properly documented, will give you the ability as the project manager to communicate the scope and the breadth of your project. So, in other words, you will be able to… Let me just say it this way, that users will be able to understand what your project is about by understanding what the requirements are.
We’ll get into not this week, but a really more in depth next week, talking about needs. How do you understand needs? And you can do that by understanding requirements.
I think this goes without saying, when we’re talking about a solid foundation here, if you don’t have an adequate requirements for a system or product, how are you going to be able to really develop and deliver that product? So, as you see here, it provides a clear description. I think a lot of this really is talking about even the definition of requirements, serves as a foundation, the basis of design.
So, you can see here the importance of requirements management. Can you think of any others? Just take a moment and think of why you capture requirements. Why is it important to your organization? Has the whole process of requirements management been a good process or does it need to be improved? Just think about those as we go forward. And hopefully, as we work through this particular lesson and the subsequent lessons that they will help you to be able to build a process that will allow you to be successful in your projects, by understanding the process of requirements management.
Let’s take a look here at just a moment in context where requirements fall. Now, you may recognize these. We call them here where I work, monopoly cards. But you’ll probably recognize the processes here that are within the scope management knowledge area. And I’ve built it this way to just show what the flow is, to see how all of these processes work together.
So, if we look at the far left, we’ll notice in the plan scope management, the main output of the scope management knowledge area is the scope management plan. And not only that, but the requirements management plan. So, right from the very beginning, you are laying out the details of how you’re going to be doing requirements management, how you’re going to be defining scope.
If we can start right at this very first process within this knowledge area, that is going to help us to move through the whole process more successfully. If you haven’t adequately developed the roadmap on how you’re going to come up with your scope, how you’re going to do the whole management process, then that can be a detriment.
But as you move through process, these the scope management plan and the requirements management plan is going to be an input into the collect requirements process. Now, if you’ll notice here in this list, excuse me, you don’t see scope management plan and requirements management plan listed. And the reason being is that it is rolled into the project management plan. Those are what are called subsidiary plans. So, they are rolled into the project management plan. You’ll see the tools and the techniques.
And notice what the output are for the collect requirements process, is the requirements documentation and the requirements traceability matrix. Your requirements document is going to be that document that will record what those requirements are, along with other information.
Now, your requirements traceability matrix, and we’ll get more into requirements traceability in the third session, but the requirements traceability matrix also is going to have a list of your requirements as well. Now, the difference between the two are that your requirements documentation or document is just going to be housing the requirements and other information. But you’re going to be using the requirements traceability throughout the entire lifecycle of the project to ensure that the product service and result that you are going to be delivering is still meeting those requirements. If you’ve successfully and robustly developed your requirements documentation and requirements traceability matrix, then notice what the flow is. Then you will use that.
Again, you’ll notice here that it’s not listed in, those two specific artifacts are not listed in the defined scope inputs, but what you have in there are your project documents. Your project document are going to be containing, in other words, your requirements documentation and your traceability matrix. So, those are going to be used, especially the requirements documentation, to then define what the scope of your project is. And once you define what your scope is, then you will create a scope statement, which is a statement that details the description, the full scope of your project.
And then finally, notice the process where it moves into your project scope statement and your project document are going to be updated if needed. And those are going to be the inputs to your create your WBS. And it is the output of your WBS, which is going to be your scope baseline.
Hopefully, that gives you an understanding of the context of collect requirements and how it works within project management. And you can’t really be able to successfully create a WBS if you can’t define the scope. So, oftentimes, if you can’t define the scope, it’s because you haven’t fully and correctly, and accurately collected the requirement. Collecting requirements are so important, so important when it comes to project management and understanding the scope of your project.
So, what are requirements? How are requirements defined? Well, requirements are defined as conditions or capabilities required to be present in a product service or result to satisfy a business need. In COSI defines it as a statement that identifies a system product or process characteristic that is deemed necessary for stakeholder accessibility. So, you have two things here. You have capabilities, those are the fundamental requirements of a system or feature, and those are solution independent. And then you have conditions, which are measurable, qualitative and quantitative attributes and characteristics stipulated for a capability. When you boil it down, it is what is necessary to build your product service and result.
While there are factors that play into a successful project, requirements are the key. So, think about anything that you do, whether it’s work or personal, you might requires certain capabilities to properly do your work. How many of you have ever been at work and you just don’t have all of the tools that you need? Or let’s just bring it down to your personal life and at home. Have you ever tried to put up a fan and you just didn’t have the right tools to be able to do that? Or you’re trying to do something for your car and you just don’t have the right tools. It is difficult to be able to even finish what you started out to do, because you don’t have the capabilities to be able to do the work that you want to do. Well, it’s the same way with requirements. You have to have certain capabilities to properly build and deliver that product, service and result.
So, here are a number of different requirements. Just take a moment to read through these. You can think of others. Maybe you have worked with, developed or gathered other types of requirements, but you have business requirements which are those higher level organizational needs. It might be that those business requirements are why an initiative has been undertaken.
You have stakeholder needs, stakeholder requirements, which really are the stakeholder needs, what those stakeholders desire. And we’ll talk a little bit more about stakeholders a little later. You have solution requirements. Those are features and functions, and characteristics of a product meeting business and stakeholder requirements. They can be grouped into functional or non-functional categories. In other words, you’ve determined what the solution to the project is going to be, or to the problem, or to the need. And that’s what we’re talking about here.
Functional requirements are product behaviors. Non-functional are environmental conditions or qualities required for a product to be effective. You’ll notice there what it says, those types of conditions, reliability, security, performance, level of service and supportability.
Then you have transitioned requirements which are temporary capabilities, such as data conversion, training requirements, and operational changes to transition from a current state to a future state. And then finally, you have your system level requirements, which describe the functions of a system and what that system should fulfill to satisfy the stakeholder’s needs.
So, these are all the different types of requirements that you might have. You could have, more than likely you could possibly have more than one type of requirements in a project depending upon what that product, service or result is.
So, let’s take a look here for just briefly. We’re talking about requirements. So far, really what I’ve been discussing somewhat are the traditional view of what requirements are. But there are requirements when we talk about the agile type of life cycle, and those are user stories. And user stories are, as it says here, a short and simple description of a feature. They are going to be what will populate the product backlog, which is a list of those user stories. They are the requirements that the development team will use to develop the solution. As you see, they are told from the perspective of a user or customer of the system. And generally they follow this template. As a type of user, I want some goal, so some reason.
So, for example, here are some user stories as a customer. I want to be able to find past recipes, so I can prepare them again. And then you see the other two here that we have referenced.
Really, how are you going to be using your requirements? What type of life cycle are you using? Really, will determine the types of requirements often that you’ll be writing and collecting. So, if it is a predictive, waterfall type of lifecycle, you’re going to be doing all of the requirements management upfront. And we’ll see that here in just a moment.
So, here is an example of the systems development life cycle. And there are any number of ways to define a system life cycle. In fact, if you ask 10 people, what a life cycle is, you’ll get 10 different versions of this graphic. But the key here is for your organization to choose the one that best suits the work that you’re doing.
But here is really your sort of basic life cycled that you’ll find in COSI. And in the concept stage, that is where you’re going to be identifying your stakeholder needs, and you’re going to be exploring concepts and proposing viable solutions. It is in the development stage that you’re going to be defining and refining your systems requirements. You’re going to be defining your solutions description, the architecture and the design. You’re going to be initiating the initial system and integrating, and verifying and validating the system.
In the production stage, you’re going to be producing the system. You’re going to be identifying, inspecting and verifying. Utilization and support stage, you’re going to operate the system to satisfy the users need and support. And support really is providing sustained systems capability. Retirement stage, you’re going to be storing and archiving and disposing of the system. But really when it comes to the system development life cycle, you’re going to be doing the majority of your requirements work here in these first two stages.
So, when we talk about project life cycles, they occupy a continuum from predictive to adaptive. And you will see this chart here and you’ll notice in the first bullet, it really shows how requirements are handled in each of those life cycles. So, when we talk about predictive, we’re talking about that the majority of the planning is going to be done upfront. You’re going to be gathering and doing all of the requirements gathering and analysis, and elicitation write at the very beginning, so that you can have as much of information that you have. And then you’re going to work through the process, the project and deliver at the end. Iterative is that you’re going to be improving the products or results through successive prototypes or proofs of concept. So, every prototype is going to be yielding new stakeholder feedback and team insights. So, then you can take that feedback and you can improve the product service and result as you move through.
Now, with iterative, you’ll notice here that requirements are defined iteratively, and there are elaborated on periodically during the requirements process. So, that means, for example, if you are in an iteration to where you are getting feedback from your customer, there are changes that need to be made. Well, that is going to mean that those requirements are going to possibly need to be changed again. So, you’re going to be defining those iteratively.
And then finally, you have the highly adaptive or agile. Agile is you’ll notice here for the requirements. Requirements are elaborated at frequent recurring intervals for each iteration. So, in other words, what you have here is, for example, I have the CSM, the Certified ScrumMaster certification. So, I’m more familiar with Scrum, but you have all of your sprints that you are doing work in. So, at every iteration or increment, you’re going to have, for example, sprint planning to where you’re going to determine which stories that you’re going to work on. Then you’re going to have your sprint retrospective and your sprint review at the end. So, you’re going to see, well, what changes need to be made? Do we need to elaborate on anything? So, you’re going to be looking at what user stories can we work on in subsequent sprints. So, your requirements are going to be elaborated at more of a frequent and recurring interval.
So, which lifecycle do you work in? Now, it could be a combination. It could be predictive. It could be adaptive or iterative. Oftentimes, that will determine how you are going to be doing your requirements management.
Let’s take a look at this. And this is talking about requirements uncertainty. And really it’s similar to what we’ve already talked about in relation to the type of lifecycle. And depending on the scale, the novelty, the technical challenge and requirements, uncertainty, planning and budgeting for specific activities might become more challenging.
If you take a look at this, now notice here, the waterfall methodology, it’s more suited for something that is simple, less uncertainty. It relies really heavy on being predictable. That is the falls within the simple. And one of the things here is that some projects have considerable uncertainty around project requirements, and how to fulfill those requirements using the current knowledge or technology. And these particulars uncertainties can really contribute to a high rate of change and project complexity.
As the project uncertainty increases, so too does the risk of rework and the need to use a different approach. To mitigate the impact of these risks, teams might select life cycles that allow them to tackle projects with high amounts of uncertainty via small increments of work. That’s what it’s really showing here, that the more complicated and complex projects, then for the fact that in agile methodologies, you are doing smaller increments of work, therefore you can handle risk and identify risk on a more frequent basis, therefore that will allow you to be able to do more complex and complicated projects.
Another thing, teams can verify their work more frequently when they use smaller increments, and they can change what to do next to handle that complication and complexity. If there’s chaos, this is really just reminds me, how many of you consider when you are handling your projects, doing your projects, that it just seems like all chaos, it might not be, but it just sort of seems like that. That is very, very risky for having projects that basically are in an area of chaos.
Think about your project. Is it a simple project? Does it have simple deliverables? Well, what I mean simple, really no deliverable is simple. All deliverables really are important. But what is the complexity and uncertainty? Is there not a lot of uncertainty? Well, your waterfall methodology might be the best way to go about it. But if it’s your project is more complex, it’s more complicated, there’s more uncertainty, then your agile methodologies, to where you can do smaller increments of work, might be the best way to go about when it comes to your requirements into your project.
Let’s talk about requirements planning here. We’ve given an introduction to what requirements are, why they are important. Your project life cycle will dictate oftentimes what your requirements will, the type of requirements or the type of gathering of requirements process that you will use. But no matter the type of project that you might be in, that you might want to start, there is one thing that needs to be done no matter what. And that is to plan.
And in this instance, when we’re talking about requirements management is developing a requirements management plan. All of the management plans within the PIM bot guide really are just as this first bullet says, is to provide guidance and directions. And in this particular instance, it’s going to be guidance and directions on how requirements should be developed, managed, tracked, validated and reported. So, it’s really, I look at these management plans as roadmaps.
So, you’ll notice some of the other aspects of the requirements management plan. It focuses on the scope of requirements activities conducted and deliverables produced. It documents how requirements should be prioritized, approved, and maintained. It establishes the traceability structure and implementation to reflect which requirements attributes are captured on a traceability matrix. It details the roles and responsibilities, and specifies how requirements are documented and communicated to the stakeholders.
So, you see here how important the requirements management plan is to be able to detail all of this information, so that you would have a roadmap when it comes to the process of collecting requirements. And anyway, even all of the other requirements management plans, I can’t stress enough how important it is to ensure that you have a plan for those.
Project managers have a challenge. They have a challenge. And the challenge is to keep these three factors, scope, time and cost in balance. Now, the purpose of me showing this particular slide is not so much to go into scope and time, and cost because you know if the scope is impacted or one of these parameters, the other two are going to be impacted as well. If you have increased scope, then there’s a chance that you would have increased time and schedule, and increased costs.
Now, one of the things here, you’ll see quality right in the middle. That throughout your entire project, you’re going to be needing to keep scope, excuse me, quality in the forefront. But really, what I wanted to point out is the arrow circling around this triangle. Notice what it says here, stakeholder needs and expectations. So, really what are we talking about here? We are talking about the importance of understanding your stakeholders needs and your expectations. Because really, when it comes to requirements, you’re going to be eliciting, drawing out those requirements from stakeholders. Therefore, you’re going to be needing to understand their needs, and as well as the expectations. They might be thinking that the project is going to deliver one thing while you’re thinking another thing. So, we need to understand their expectations.
Also, why this is surrounding this balance is that stakeholders could possibly impact your project negatively. Maybe they implement a policy change that then trickles down to you and now you have to stop and go right into planning again. So, there’s a lot of factors when it comes to stakeholders.
So, we’re going to take some time here to look at the various stakeholders. What is a stakeholder? I think all of us probably know what stakeholders are. They are those persons who could impact your project or be impacted by your project. You’ll notice here, and accidentally had this under the graphic, but it is SMI, subject matter experts. And I liked this graphic here. I think it is a good representation of stakeholders. Stakeholders have different personalities, different types of influence. Maybe you have stakeholders that are like the turtle and the snail, they’re real slow, or like the ferret, maybe they’re really sly, or really young and new at the game. Or maybe you have the leader who really stands out or team members that talk back to you, even you’re telling them that what’s they need to do, and they talk back at you like the parrot. But whatever the case might be is that we need to identify those persons who need to be involved in the requirements management process.
And here are some of the examples here, users, operators, organizational decision makers, again, I apologize for the typo here, regulatory bodies, subject matter experts, contractors, product owners, Scrum master, Scrum team. This list is not all exclusive. It really is, who needs to be involved? There is nothing worse than being in a meeting where you have planned to talk about requirements and began the whole requirements gathering process, and the wrong people are there. That meeting is useless. So, one of the very first things is to understand and identify who those stakeholders are.
Now, here is a good tool. It is called the onion diagram, and it depicts the relationships between the stakeholders and the solution. You’ll notice here that is just one technique that you can use to model the relationships that exists between the stakeholders and the solution, that can be external to the organization or internal. But you’ll notice here that closest to the solution are those stakeholders who are directly involved with the development of the solution. So, they could be the development team, the developers, whomever those might be.
Then, and the next level of the onion, you have those stakeholders directly impacted by the solution. Who are you building that solution for? Is it for your organization? Is it for the public? Well, they could be directly impacted by the solution, especially if it’s internal. Then you have stakeholders who interact with those directly impacted by the solution. Could be other people in the organization and other departments. And then you have external stakeholders. Those could be your vendors and third party contractors.
So, this is one way that you can begin to think about who those stakeholders are by thinking about these specific categories. Each subsequent layer represents a lesser degree of relationship to the actual solution itself.
So, once you’ve identified your stakeholders, then you need to analyze them, how much influence do they have over your project or idea? Can they help move it forward or could they stop it in its tracks? You’re going to be doing this analysis during the planning process. You’re going to be determining not only your power, which I just mentioned, but their interests, how much interest do they have? Will it be beneficial to them? Just think about your work or your project, will it benefit them? What is important to them? What will they want to know or not want to know? These are things that need to be analyzed. Find out as much as you can. It will really help you with a strategy to build better relationships with them. And why it’s important when it comes to the requirements management process, is that you’ll be able to determine who those stakeholders are and who needs to be involved in the requirements process.
Now, you don’t want to necessarily have those who aren’t involved, I mean, who might not be touched, you may not necessarily want. If we looked at the onion diagram again, it might not necessarily be that you would want to invite. It could possibly be depending upon who they are, those external stakeholders.
Determine first of all, before you even have a meeting, who needs to be involved? Who are your stakeholders? What types of power and interests that they have? How close are they to the solution? You can then invite them to your requirements management process.
So, stakeholder requirements. Really, what you’re going to be doing, you’re going to be getting and understanding what the needs are. And then when you understand the needs, you’re going to be able to understand, be able to translate those into requirement. As you see here, they govern the systems development. They are essential factor in further defining or clarifying project development scope. They provide the basis for technical description of deliverables in an agreement. You’ll see here how important those stakeholder requirements are, because ultimately we want to satisfy our stakeholders.
So, here is basically, this is how it works. Okay. Stakeholders have wants. Those wants are then refined to needs. And then the needs are then transformed into requirements. Think about your work. What are some of the things that your stakeholders want? And what is a want? A want is to greatly desire something, something that someone would like to have, but it is not always necessary.
For example, I’m an avid photographer. And I’ve wanted a brand new camera, an upgrade. And I remember if I wanted something that was not feasible, like a new camera, my wife would say, “Well, you are old enough where your wants W-A-N-T, won’t, W-O-N-‘-T, hurt you. You’re old enough where your wants won’t hurt you.” Oh, I hated to hear that. What that means is that means is, you can want it as much as you want, but you’re not going to get it. And really that is true. When I think back and I’m thinking about the cameras that I wanted, it’s really true. So, the key point here is, is that I may have wanted to buy a new camera, but I really wasn’t taking into consideration on whether we could afford it or not. And really we couldn’t. So, it goes back to managing those stakeholder expectations.
Now, a need is a condition or a situation in which something must be supplied in order for a certain condition to be maintained or a desired state to be achieved. I like to look at a need as this, is that it is the gap between what is and what should be. So, you have a current condition, you want to move to a future condition, that need is that gap to get you from the current to the future.
So, here’s an example of really an informal requirements process. You have the stakeholder approaches the project manager. And this particular stakeholder says that, “I want a connection to the mainframe.” One thing that, and we’ll get into this more next week when we talk about eliciting and collecting, and writing requirements, is that often when we are gathering requirements, the stakeholders may not necessarily fully be able to articulate what they are wanting. So, if you look at this, he wants a connection to the mainframe, that really doesn’t tell you a whole lot, at least to that project manager, what is needed? Project manager begins to ask questions to understand the need. And the project manager continues to ask the questions until they have an understanding of what it is.
So, in this particular instance, they only want one connection versus numerous connections. In this instance, the end game here is that requirements are formed from the needs resulting in a single connection to the mainframe with accompanying security.
If you say the process here is that, first of all, you’re understanding what the stakeholders needs are, you’re understanding what their expectations are, you’re asking them to process that, to express that, well, that may not necessarily… They may know. Just think about, have you been in a situation to where you know what you want, but you just can’t express it fully? And you’re asked questions to, “Please, clarify.” Which really is the same thing. You are asking questions until… which is elicitation, really. You’re asking questions to understand what those needs are. Once you understand those needs fully, then you can write requirements.
Requirements are important. Requirements are in every aspect of your project. You really can’t move on through the whole process of understanding and defining your scope, and creating your work breakdown structure unless you truly understand those requirements. You can’t get those requirements until you really understand who your stakeholders are. And once you understand who your stakeholders are, and your stakeholders could be organizational needs. It doesn’t necessarily mean individual needs. But you begin to understand those needs, and you can begin to elicit. And then you can understand, and begin to write your requirements, which is what we are going to be discussing next week when we talk about collecting and writing requirements.
So, thank you so much for joining me on this particular webinar. I really appreciate it. We will continue next week on collecting and writing requirements.
So, you see my email here, please feel free to shoot me an email, if you have any types of questions. I’ll be glad to help you with that. So, thank you so much for joining us. And until next week, bye.
Watch the on-demand recording by clicking here.
