Did you know Cybrary has FREE video training? Join more than 2,500,000 IT and cyber security professionals, students, career changers, and more, growing their careers on Cybrary.
This lesson focuses on collecting requirements when managing a project. This process creates the project requirements by focusing on project stakeholders needs. A project manager can use interviews, focus groups, observations, prototypes, benchmarking, document analysis, facilitated workshops, group creativity techniques, group decision-making techniques as well as questions and surveys to develop the requirements documentation. [toggle_content title="Transcript"] The next area under scope management is collect requirements. Collect requirements creates the project requirements by focusing on the project stakeholder needs. This process creates the requirements documentation and the requirements traceability matrix also known as the RTM. The key inputs for this plans is, the scope management plan, the requirement management plan, the project charter, and the stakeholder register. A project manager can use a whole bunch of different tools to get this process done. Interviews, focus groups, observations, prototypes, benchmarking. Document analysis, facilitated workshops, Group creativity techniques, group decision making techniques, questions and surveys or context diagrams. That helps to develop the requirements documentation, and the RTM. Let's go over these tools first. Interviews. If you think about an interview, it's usually one on one. It's very detailed oriented. I am talking to a specific person, I can ask whatever questions I want to that person but the problem is I'm focused on one person not giving a whole group. So it establishes stakeholder needs from one and one questions. It also develops accurate requirements but it's very time consuming. Think about that. Facilitated workshops. This is like a joint application development, quality function deployment or QFD or a voice of the customer. Examples of facilitated workshops. Usually used in development. Example of facilitated workshop is you have a group of people. You have one person at the back who's facilitating the meeting and you just have questions going back and forth. You're recording what the questions and answers are. It's basically streaming a whole bunch of information being recorded. You have focus groups. Focus groups are subject matter experts and specific stakeholders. They meet, you have a focus group and you're trying to get information from that group. Basically subject matter experts and specific stakeholders meet to determine the expectations and attitudes about the project, product, service or results. Under group creativity techniques you have brainstorming, nominal group techniques, ideal mind mapping, affinity diagrams and multi criteria decision analysis. Another tool is the group decision making technique. Under this technique, you want to go in knowing how the decision is going to be made. You don't want to be making this decision after it's been started. There's four decisions here: Unanimity, majority, polarity or dictatorship. Under unanimity you have to have 100% agreement before making the final decision. Under majority, you have to have over 50% in order to agree. Under polarity, you have to have the largest group. So if you have three groups the largest of those three groups for decision is how you're going to move forward. Under dictatorship, you have one boss. His is getting inputs from everybody else, and he's the one that's going to make that decision. At the set of questions and surveys you can send out to a large group of people. You can get a quick result back from that but you're limited. For this you can accumulate information from a lot of resources quickly because you're sending out surveys. You're limited on questions or statistical analysis because you can only write so much and you can probably would have an ABCD answer or limited response. Another tool is observations. This is also known as job shadowing. You're watching a person do their job. This can be done in many different ways. You can watch someone perform a process or you can go and absolutely observe like, "I notice that this person is doing this." This would help them do that process better. Also there is prototypes. This is basically creating a working model of the expected product but it's not 100% complete. This usually gives somebody something they'll play with. Where they can kind of figure out how they wanted to move forward by having something in their hands where they can work with. Another tool is benchmarking. You're comparing actual plan practices to comparable organizations to identify best practices. Another tool is context diagram. This basically depicts the products scope by showing a business system and how people in other systems interact with it. You also have document analysis which is using existing documentation and analyzing it to identify information relevant to the requirement. Basically you could be looking at the statement of work or you're basically trying to take information out of a document to create requirements. Requirements documentation. This is what your output is from all those tools. This is the basis of describing how requirements meet the business need of the project. Also the requirements need to be measureable, testable, and traceable, complete, consistent, and acceptable. There is nothing worse than trying to figure out what to do on a project when you don't have a good solid requirement. The requirement traceability matrix. It's basically a matrix which aligns requirement to the source, business need and projects objectives. It also aligns requirements to the project scope, WBS deliverables, project design and development, entity strategy and scenarios. It's basically covering your requirements in a table. Which I'll show shortly. The matrix may also wind high level requirements to detailed requirements. This is what a requirements traceability matrix could look like. It's basically a table and you're trying to show how things relate. It could be a WBS item, a requirements description, so for this one it could be doing a project in the backyard. Your requirements could be, cut the grass, fertilize the lawn and Inside the house, install crown molding. You're basically trying to trace where this requirement came from. Did it come from a document, did it come from a person. In this came it came from the wife, so, who is the owner? The owner is the person who is responsible for that requirement. In this case it's the husband. How are going to accept that requirement? What has to be done in order to meet it? These are instructions to make sure that they're done, then it's a living document. As the projects is in motion, you're going to be tracing where this status is for each one of this. For this one cutting the grass is complete, Fertilizing the lawn is in progress, and installing crown molding is not started. In summing up this process, your inputs are the scope management plan, which is the beginning of this knowledge area. This is what's setting up, how you are going to collect the requirements. You have the requirements management plan which came out of the first stage of it. You have stakeholder management plan, which comes out of human resources. Actually it comes out of stakeholder, different knowledge area: The stakeholder management plan as you're developing these requirements, you're going to know what the needs are for each one of the stakeholders and that's why that's there. Stakeholder register which is also under the stakeholder management area. This document is going to let you know who the contact. It's going to have contact information there, who they are, what their role is. To start off the project you have to have the project charter which is going to list your high level requirements. The tools we've gone over and the output of this whole process is the requirements documentation and the requirements traceability matrix. [/toggle_content]