Requirement Gathering and their types
1)
One-on-one
interviews
The most common technique for gathering
requirements is to sit down with the clients and ask them what they need. The
discussion should be planned out ahead of time based on the type of
requirements you're looking for. There are many good ways to plan the
interview, but generally you want to ask open-ended questions to get the
interviewee to start talking and then ask probing questions to uncover
requirements.
2)
Group
interviews
Group interviews are similar to the one-on-one
interview, except that more than one person is being interviewed — usually two
to four. These interviews work well when everyone is at the same level or has
the same role. Group interviews require more preparation and more formality to
get the information you want from all the participants. You can uncover a
richer set of requirements in a shorter period of time if you can keep the
group focused.
3)
Facilitated sessions
In a facilitated session, you bring a larger group
(five or more) together for a common purpose. In this case, you are trying to
gather a set of common requirements from the group in a faster manner than if
you were to interview each of them separately.
4)
Joint
application development (JAD)
JAD sessions are similar to general facilitated
sessions. However, the group typically stays in the session until the session
objectives are completed. For a requirements JAD session, the participants stay
in session until a complete set of requirements is documented and agreed to.
5)
Questionnaires
Questionnaires are much more informal, and they are
good tools to gather requirements from stakeholders in remote locations or
those who will have only minor input into the overall requirements.
Questionnaires can also be used when you have to gather input from dozens, hundreds,
or thousands of people.
6)
Prototyping
Prototyping is a relatively modern technique for
gathering requirements. In this approach, you gather preliminary requirements
that you use to build an initial version of the solution — a prototype. You
show this to the client, who then gives you additional requirements. You change
the application and cycle around with the client again. This repetitive process
continues until the product meets the critical mass of business needs or for an
agreed number of iterations.
7)
Use cases
Use cases are basically stories that describe how
discrete processes work. The stories include people (actors) and describe how
the solution works from a user perspective. Use cases may be easier for the
users to articulate, although the use cases may need to be distilled later into
the more specific detailed requirements.
8)
Following people around
This technique is especially helpful when gathering
information on current processes. You may find, for instance, that some people
have their work routine down to such a habit that they have a hard time
explaining what they do or why. You may need to watch them perform their job
before you can understand the entire picture. In some cases, you might also
want to participate in the actual work process to get a hands-on feel for how
the business function works today.
9)
Request for proposals (RFPs)
If you are a vendor, you may receive requirements
through an RFP. This list of requirements is there for you to compare against
your own capabilities to determine how close a match you are to the client's
needs.
1 10) Brainstorming
On some projects, the requirements are not
"uncovered" as much as they are "discovered." In other
words, the solution is brand new and needs to be created as a set of ideas that
people can agree to. In this type of project, simple brainstorming may be the
starting point. The appropriate subject matter experts get into a room and
start creatively brainstorming what the solution might look like. After all the
ideas are generated, the participants prioritize the ones they think are the
best for this solution. The resulting consensus of best ideas is used for the
initial requirements.
Example form for requirement gathering:
Here is some basic types of requirement
are
Ø
Architectural
requirements
Ø
Structural
requirements
Ø
Behavioural
requirements
Ø
Functional
requirements
Ø
Non-functional
requirements
Ø
Core
functionality and ancillary functionality requirements
Ø
Performance
requirements
Ø
Design
requirements
Ø
Derived
requirements
Ø
Allocated
requirements
1. Architectural requirements
Architectural requirements
explain what has to be done by identifying the necessary systems
architecture of a system
2. Structural requirements
Structural requirements explain
what has to be done by identifying the necessary structure of a
system.
3. Behavioral requirements
Behavioral requirements explain
what has to be done by identifying the necessary behavior of a
system.
4. Functional requirements
Functional
requirements explain what has to be done by identifying the necessary
task, action or activity that must be accomplished. Functional requirements
analysis will be used as the top level functions for functional analysis.
5. Non-functional requirements
Non-functional
requirements are requirements that specify criteria that can be used to
judge the operation of a system, rather than specific behaviors.
6. Core functionality and ancillary functionality requirements
Core
functionality requirements are those without fulfilling which the product
cannot be useful at all. Ancillary functionality requirements are those that
are supportive to core functionality
7. Performance requirements
The extent to which a mission or
function must be executed. Generally measured in terms of quantity, quality,
coverage, timeliness or readiness.
8. Design requirements
The "build to",
"code to", and "buy to" requirements for products and
"how to execute" requirements for processes expressed in technical
data packages and technical manuals
9. Derived requirements
Requirements that are implied or
transformed from higher-level requirement. For example, a requirement for long
range or high speed may result in a design requirement for low weight.
10.
Allocated requirements
A requirement that is established
by dividing or otherwise allocating a high-level requirement into multiple
lower-level requirements.
