It's important to collect the project requirements because that tells you what you have to create in
your project.
So this is a project management process which is collecting project requirements.
It's how do you determine document and manage requirements throughout your project.
Now you may be doing this as the project manager.
You might also be doing this with a business and Lois so collecting the required check requirements
help you define the product scope and the project scope.
Typically in a predictive environment we're collecting requirements upfront.
You might be collecting requirements at each phase or if you're an adaptive environment those requirements
are going to fluctuate based on the product backlog.
Let's check out the Ito's for collecting project requirements our inputs the charter because that's
our high level requirements some place to start the project management plan.
While the scope management plan requirements management plan our stakeholder engagement plan project
documents the assumption log lessons learned register stakeholder register.
All of that business was helping us to gather requirements so these are places that we would look that
we're going to get requirements from.
Same with our business case.
Remember the business case defines business value and how does this project meet business value.
That's a good place to look for requirements and then E-F.
Oh P-A as always we see that over and over lots of tools and techniques to gather requirements expert
judgment data gathering we're going to do things like brainstorming interviews focus groups doing surveys
and benchmarking new term for you will see coming up data analysis.
Look at your documents look at all the documents you have so far that's a great place to collect requirements.
Doing some decision making with voting multi-pack criteria analysis data representation are a way of
making charts or visualizations of our requirements.
So I Finerty diagrams mind maps having some interpersonal and team skills the nominal group technique
observation and conversation facilitation using a context diagram and prototypes and don't worry we're
going to see that business coming up in detail the outputs of collecting requirements will be the requirements
documentation and that requirements traceability matrix one of the best tools and techniques for gathering
requirements is to do interviews with stakeholders.
So you use the stakeholder register because that identifies who our stakeholders are and we'll do a
one to one conversation.
It could be a one to many words you and three or four stakeholders or maybe to many where it's you and
your project team and three or four stakeholders and you all are talking about the requirements so asking
questions and really understanding and learning about the requirements of focus group is a moderated
event at 6 to 12 people.
We have that neutral moderator that will come in and kind of facilitate the conversation.
So it's not leading participants to a solution.
One thing that we want to consider with requirements and focus groups is what's the participant composition
if we are doing a new project and we're gathering requirements do we only bring in participants from
the sales group and then only participants from marketing and only people from manufacturing and then
only I.T. so we can isolate these groups of stakeholders to ask them specific questions about their
area or do we mix and match.
We bring in people from all of these groups and mash them all up together and then they can interact
with one another.
So that's the idea.
Participant composition like who should be involved in this.
And what's the distribution of stakeholders.
Of course you can do questionnaires and surveys you know use Webmonkey or some survey tool or whatever
you want to create surveys that are fast especially when you have a lot of stakeholders to Cali up results
or people are distributed around the world.
Not anything shocking there right.
Benchmarking the requirements is when we compare two or more systems or solutions or even businesses.
So I want to compare ad Jayal to sequel or I've get soundproofing material for this house so I want
to do some test.
I want to build a booth and test the decibels of one and the other.
So on benchmarking where I'm setting my requirements based on an external basis for performance.
So the how will they perform tells me how well this material should be in my project and that's the
one I'm going to select and then comparing organizations so I can look how they do it at 90.
That's how we can do it here.
Manufacturing or how that a public company do it.
There's an article we read or a white paper and that will set some goals for how we can do it at our
organization one of the best places to begin gathering requirements is through documentation.
All of those brochures and proposals and blueprints and those early specs that you have that's great
places to do a requirements identification.
So analyze project documents when you have all those folks together and they're going to vote on requirements.
You can do group decisions every unanimous the majority more than 50 percent.
That's the way we go.
The plurality the largest bloc agrees.
So you might have 100 100 people and you have 40 people are in favor of a requirement a and then 30
people are in favor of requirement B.
And then you know maybe there's 20 people and some people then vote or they're just mad and they don't
want to participate.
So even some other people that here they want a requirement a.
There's more people against what the largest bloc is for.
So let's plurality.
So even though more people may be not in agreement with what's wanted this is the group that wins because
they're the largest bloc when there's multiple choices and then dictatorship one person decides multi
criteria analysis.
We've seen this a couple of times already and we're going to see it some more.
It's just they have different factors to raise or prioritize or even eliminate project criteria.
So we could say things like performance metrics in our testing.
What risk were introduced.
Just the requirements themselves based on priority and the amount of time and money we have.
So this is a decision matrix a little table down here where we can give different scores and then you
know do some math here as to how many points you get and then from that we would choose the requirements
that have the most points or any requirements you know above 50 points or whatever.
But that's a multi criteria analysis.
The decision matrix to measure and score and I Finerty diagram is is very similar to brainstorming but
what we do is we group ideas into these different clusters so we could say all right we want to do a
project with social social networking.
So on Facebook basically we want to have simple tips and tricks and create some publicity about our
project so we can say well what are some different ideas that we can do and how does that help our project
and how does that help communication.
And then as we brainstorm we put little post-it notes up into these different ideas.
So it's an affinity.
Affinity like ideas like minded that folks go into these different categories.
So with requirements gathering it's a way to decompose and to organize your different ideas.
So when I.T. we can always say you have hardware software data network.
So it's going to fit into one of those four.
And then as we brainstorm we would focus on hardware software network and data mind mapping is kind
of fun to do.
It's a way of when you're trying to generate ideas or brainstorm ideas you just kind of draw it out
and you can see in this picture here.
One thing leads to another to another to another.
So it's a way to visualize the brainstorming process.
It's a way to generate new ideas and to consolidate ideas and you've got a lot of people participating.
You can have all these crazy branches and how do they touch each other and it's just a way to visualize
ideas.
A term that we saw one of our tools and techniques was the nominal group technique.
There's five steps here for the nominal group technique.
First off you want to generate ideas.
You kind of brainstorm ideas and then you vote and you'll rank these ideas.
Then each participant will brainstorm the problem or opportunity with their ideas.
Everyone does this on their own.
And then the facilitator will add each person's ideas on a white board and then you talk about each
idea.
So everyone has a clear understanding and then you will privately vote on each idea from 1 to 5.
And then you whoever gets the most points you can repro your ties and start the process over or that'll
be the requirements you go with.
So there is a sense of anonymous here as to to do I like the idea or do I hate the idea even though
it's my boss.
He gets one.
All right.
So it's a nominal group technique is a way of having these rounds of voting and brainstorming on ideas.
Larger projects you might do a facilitated workshop and I say larger projects because generally you
leave you go off site somewhere and you're going to spend two or three days and you're just going to
dig in and just hammer out all of the requirements that you're unavailable for that time.
So you might call it a joint application design.
That's a software development.
So sneeze and the developers meet and they just hammer out the requirements.
But it's a long process it's a workshop could be facilitated by a neutral moderator probably have a
very intense outline to follow or an agenda to follow.
In manufacturing you might have a similar approach called the quality function deployment.
It's also known as the voice of the customer.
And this is a workshop typically in manufacturing where you identify these characteristics and then
you prioritize them based on what the customers are saying they want.
And so that's used for product development.
In an agile environment we also have some requirements gathering.
So we have these user stories user stories or the entries in our product backlog.
Well use your story as a way of describing what happens with that event or with that requirement.
And there's typically three features and a user story that you have the user which would be the role
that's the person who benefits from the feature.
The goal what is the stakeholders trying to accomplish.
Why do we need that requirement.
Why do we need this thing.
What's the end result of what we are creating.
And then the motivation is the why what's the benefit.
Why do we need that.
Why is the stakeholder interested in doing this.
So you have the role the goal and the motivation and those are the user stories in the backlog and that's
how we can move through to create our requirements or to gather requirements.
Stakeholder observation is we have job shadowing we have passive and active passive is where I just
follow you around and observe.
I don't see anything active.
It's why I follow you around and not only do I reserve but I might try to do some of the work you might
allow me to do some of the work or to try it out or I could interact and have a conversation with you
and ask questions and so on.
So job shadowing a context diagram shows the flow of data through a system or the flow of a process
through a system.
So an example here in the scope model is we're looking at the different working components so it would
show all the servers are the workstations or laptops where the databases were the data stored What's
the workflow how does data get in.
How do people retrieve it.
How is it secured.
And then who are the people the people are sometimes called actors.
So context diagram takes a requirement and it puts it in context of how people interact with that solution.
Prototypes are another thing that we have prototypes.
We have a throw away prototype like this sketch here it's not really doesn't do anything for us.
We sketch it up and we show a picture and people OK I get it.
Let's go with that a functional because we actually create something that if you agree to it it can
become part of the solution.
So sometimes like a web mock up or create a new Web site you just kind of market and test the colors
and the look and feel.
You don't really put a whole lot of time into it but if you like that when you've already got it set
up and you can begin building it out storyboarding is kind of like a throw away prototype but actually
draw the story of how the requirement works in the solution.
So it's just like in the movies where you see like the storyboard of how the how Batman and Superman
are going to fight I watch that movie so storyboards what happens there.
They're all cartoons.
It's a storyboard or in a movie it shows the flow of the story or their narrative.
So the prototype would be the same thing.
It shows how you interact with it and what happens.
All right good job a lot of terms here about prototypes and about requirements and the requirements
management plan as it relates to scope.
Great job.
Keep moving forward.