1.1 This plan helps you to
understand what kind
of requirements you
need to gather.
2.1 This is one of the outputs from the
last process. It tells you how
requirements will be gathered.
3.1 This plan tells you how to understand
what all of the stakeholders on your
project need and plans out how you’ll
communicate with them. You’ll learn
4 Project charter
4.1 The project charter tells you
at a summary level what
the project is supposed to
5 Stakeholder register
5.1 The stakeholder register is a list of all of the people you
need to talk to work out the requirements for the
6.1 Are important ways to get your
stakeholders to explain how they’ll use the
product or service your project is creating.
By talking to people one-on-one, you can
get them to explain exactly what they need
so that you can be sure that your project
can meet its goals.
7 Focus groups
7.1 Are another way to get a group of people to discuss their
needs with you. By letting a group discuss the end product
together, you can get them to tell you requirements that
they might not have thought of by themselves.
8 Facilitated workshops
8.1 Are more structured group conversations where a
moderator leads the group through brainstorming
requirements together. In facilitated workshops,
misunderstandings and issues can get reconciled all at
once because all of the stakeholders are working together
to define the requirements.
9 Group decision-making techniques
9.1 A big project usually has a lot of stakeholders, and that
means a lot of opinions. You’ll need to find a way of
making decisions when those opinions conflict with
each other. There are four major decision-making
techniques you can choose from.
9.2.1 Means everyone agrees on the decision.
9.3.1 Means that more than half the people in the
group agree on the decision.
9.4.1 Means that the idea that gets the most votes
9.5.1 Is when one person makes the
decision for the whole group.
10 Questionnaire & Interview
10.1 Plurality, Unanimity
11.1 Sometimes observing the people who will use your product while
they work with it will give you a better idea of how to solve their
problems. People don’t always know what to say when you ask
them for requirements, so watching them deal with the problem
your product is going to address can help you to find
requirements that they might not tell you about on their own.
12.1 Sometimes the best way to get your stakeholders to
give you an opinion on what your product should be is
to show it to them in a prototype.
14 Organizational Impact
15 Functional requirements
16 Nonfunctional requirements
17 Idea/mind maps
17.1 Are a good way to visualize the way your ideas relate to each other. When you’ve finished working
through an idea, it sometimes helps to create a map of how you got there and show which ideas can
be grouped together.
18 Context diagrams
18.1 Help your team show the way all of the processes and features in your product
scope relate to each other. It’s a picture of the scope of your product that shows
how users will interact with it.
19 Affinity diagrams
19.1 Are great when you have a lot of ideas and you need to
group them so you can do something with them. A lot of
people make affinity diagrams using Postit notes on walls.
That way, you can move the ideas around and change the
groupings when you think of new areas to explore.
Sometimes just putting requirements in categories will
help you to find new ones.
20 The nominal group technique
20.1 Is a form of brainstorming where you write down the ideas as you
find them and have the group vote on which ones they like the best.
You then use the votes to rank all of the ideas and separate the
ones that aren’t important from the ones you want to delve into
21.1 is one of the most commonly used ways of
collecting requirements. Whenever you sit a
group of people down to think of new ideas,
22.1 is a way of comparing the processes and practices
used in building your software with the practices
and processes in other organizations so you can
figure out the best ideas for improvement.
23 Document analysis
23.1 is a way of collecting requirements by reading through
all of the existing documents for your product.