Collect Requirements

00:01 This module examines the Killick requirements process from the Bot guide.

00:08 It has a very high exam importance because collecting requirements is one of the first necessary steps in defining our scope and ultimately creating our work breakdown structure.

00:19 The difficulty is that level medium because it may be that you don't do this in your real job, as the PMBOK guide outlines it and the memorization levels are medium.

00:31 There's a number of new concepts that we have to introduce to you.

00:35 The requirements process is part of the Project Scope Management Knowledge area, and it's one of four Planning processes in this knowledge area. The others being the plan scope management process, which creates our scope management plan. Also, the defined scope and create WBS processes. Click requirements. In summary, it is the process of defining and documenting stakeholders needs to meet the project objectives, and when we do this, we create requirements documentation that describes our individual requirements meet the business need for the project.

01:17 And requirements documentation will be iterative.

01:20 It will start at as high level and then become progressively more detailed as we find out more and more about the requirements.

01:28 We will use our requirements management plan.

01:32 Because this sets out how all of our requirements will be analyzed, documented and managed or change throughout the project in relation to the domain task that this process helps us understand better.

01:43 It's Planning task to.

01:46 Which also relates to the development of the scope management plan.

01:50 And it says develop a scope management plan based on the approved project scope and using scope management techniques, which include collecting requirements in order to define, maintain and manage the scope of the project so we can see there that collecting requirements as a necessary first step in defining the project scope.

02:13 The key themes go out and click the project, and product requirements from stakeholders, decide which of those requirements will become part of the approved project and product scope.

02:26 And once we have them track the delivery of those requirements.

02:31 The inputs that we may find useful in collecting the requirements are, first up, the scope management plan.

02:40 Now this is the broad plan which guides all elements and facets of defining our project scope, collecting requirements as a necessary first step in defining our scope. So we need our scope management plan.

02:53 If we did produce, one will also look to use our Requirements Management Plan here because it is specifically addresses how we will collect the requirements, how we would document them, how will we decide which ones go through to be delivered and will also document how we go on to check the delivery of those? We may also want our stakeholder management plan.

03:16 This is because this plan provides guidance on how we identify stakeholders, how we approach them, how we manage their expectations in the ways in which we influence them.

03:27 Because it's the stakeholders, they're going to give us those project requirements.

03:31 And that's why the stakeholder management plan is essential here.

03:36 We may also look to our project charter for preliminary information that may be known about our project requirements.

03:43 Remember that the Project Charter had enough information in it to allow the project to be authorized and initiated, and that information may include information about our project requirements.

03:55 It will also include information about project stakeholders and an early and preliminary assessment of their expectations of the project.

04:04 We may also want to have our stakeholder register here as an input now our stakeholder register is an output from the Identify Stakeholders process, and it will give us the names and contact details and assessment of the interest and how we're going to manage all of our stakeholders.

04:22 Because once again, just to emphasize the point, most of the collecting requirements work we do involves going to stakeholders and seeking information from them about what their requirements are for the project.

04:37 There are quite a lot of potential tools and techniques that we may find useful to us.

04:44 Have a look at these as they come up and see if you can figure out what most of them have in common, and we'll come back to that at the end.

04:52 The first tool and technique that we may find useful is interviews.

04:57 This is simply going out and interviewing stakeholders.

05:01 It could be done formally with formal sit down meetings, it could be done informally. It could be done virtually with websites and you put questions to them.

05:11 You get their responses back via interviews.

05:15 You may also choose to run focus groups where you bring in a number of stakeholders and you ask them particular questions and get their responses to those questions, all about project requirements.

05:28 You may choose to run facilitated workshops where you'll bring in an outside expert with specialist skills and holding a workshop and get stakeholders to think about the requirements that they want and the project.

05:43 During a workshop, you may also choose to use group creativity techniques, and what you're trying to do here is to get people to think slightly outside the box a little bit creatively.

05:54 So things like brainstorming, challenging somebody's ideas, having somebody play devil's advocate.

06:00 These are all effective group creativity techniques to get people out of that rut they can sometimes get in.

06:07 You may also choose to use questionnaires and surveys, sending them out to people and asking for them to fill them out and return them.

06:16 And these questionnaires and surveys can ask them about their requirements for the project. Observations, there are another great tool and technique you actually observe stakeholders and action to figure out what their requirements are for the project.

06:35 Prototypes, another great way to solicit this information from stakeholders is to make a prototype.

06:42 And if in the construction industry, you may actually make a small model if you're in the IT and software industry, you may mock up some screenshots and show them to the stakeholders and go, Is this what you meet with your requirements information? You may also choose to use benchmarking where you compare the requirements of your project with the requirements of a previous project completed.

07:06 Context diagrams give us a very useful way to see how the requirement for one requirement.

07:14 A fix or not, a fix, the need for other requirements in our projects, so if we need requirement A., We probably need Requirement B.

07:24 And we may finally choose to use some document analysis, past projects, industry legislation and regulations will all give us an insight into particular requirements we must deliver on the project.

07:37 Now, at the beginning of this tools and techniques section, I ask you if you would notice anything about many of those tools and techniques.

07:47 Maybe you notice that many of them were ways to gather information from stakeholders, because that's the essence of collecting requirements, is going to the stakeholders and asking them What are your requirements for this project? Keep in mind that once they've given you their requirements, that doesn't automatically mean those requirements will be delivered.

08:10 Your next step is to assist those requirements, make sure they all map back to a defined business need and then make a decision about which requirements will be delivered in the project and which requirements will not be delivered by this project. When you do make those decisions, make sure you communicate those decisions back to the stakeholders effectively.

08:31 As a result of taking those useful inputs and applying any number of those tools and techniques to them as appropriate, you will produce requirements documentation.

08:42 Now this is a list of all the requirements that have been asked for on the project, but also your assessment of whether or not they will be delivered as part of your project.

08:52 And this is where you need to make that decision.

08:54 Do these requirements deliver a business need and to help you do that? You may also produce another output.

09:01 The requirements traceability matrix.

09:04 Now this is how you can map each of your comments back to a particular business. Need to make sure that it should definitely be included in your project.

09:14 So with the requirements, documentation and the requirements traceability matrix, you've got a robust and transparent description of all the stakeholder requirements for your project, and you can list the ones you will deliver.

09:27 And you can also account for the ones you're not going to deliver in this project.

09:32 So in summary, the Click Requirements process is the first step in defining your project and product scope.

09:41 It's the state where you go out and you talk with stakeholders and gather their requirements for the project and make decisions about which requirements you are going to deliver and which ones you're not.

09:52 And you're going to produce a list of approved requirements and always trace them back to projects, objectives and business needs.

10:00 Make sure no requirements get in there that you cannot trace back to an approved business need for the project.

10:08 So this has been the requirements process from the PMBOK guide.