Based on what I had
read, Requirement Discovery is also
often referred to as requirements elicitation, requirements gathering,
requirements analysis, and requirements definition. We prefer to use the term
because it's a little less high-brow, more meaningful, and more appropriate to
the activity it is intended to describe. It is
a process and tools used to
identify system requirements of the users of the proposed system. A system
requirement is a description of the needs and desires for a system or
application. A system requirement describes functions, features and
constraints.
During
the requirements discovery process, project team members use fact-finding
techniques to gain a better understanding of the requirements of the system.
Fact-finding activities include, but are not limited to activities such as:
·
Research
·
Interviews
·
Meetings
·
Questionnaires
·
Sampling
This process is also
called information gathering or data collection.
Keep
in mind that the purpose of requirements discovery is to correctly identify
the knowledge, process, and communication requirements for the users of a new
system. Regardless of whether it is an information system or software program -
failure to correctly identify system requirements may result in one or more of
the following situations:
·
The
system may cost more than projected
·
The
system may be late.
·
The
system may not meet the users' expectations resulting in them not using it
·
Costs
of maintaining and enhancing the system may be excessively high
·
The
system may be unreliable and prone to errors
The Criteria to Define System Requirements are very important in
Requirement Discovery to achieve a successful project in a future.
•
Consistent
•
Complete
•
Feasible
•
Required
•
Accurate
•
Traceable
•
Verifiable
The Process
of Requirement Discovery is the way you (and the other party) discover
the other side’s view of what happened in the case. This process is like a
roadmap allowing you to see the other side’s version of when and where things
happened. Discovery is a very important process because it allows you to
collect the information necessary to assess the strengths and weaknesses of
both your case and the case of the opposing party. It also shows you where you
and the other party agree and disagree.
•
Problem
discovery and analysis
•
Requirements
discovery
•
Documenting
and analyzing requirements
•
Requirements
management
Ishikawa Diagram
When utilizing a team approach to
problem solving, there are often many opinions as to the problem’s root cause.
One way to capture these different ideas and stimulate the team’s brainstorming
on root causes is the cause and effect diagram, commonly called a fishbone. The
fishbone will help to visually display the many potential causes for a specific
problem or effect. It is particularly useful in a group setting and for
situations in which little quantitative data is available for analysis.
The fishbone has an ancillary benefit
as well. Because people by nature often like to get right to determining what
to do about a problem, this can help bring out a more thorough exploration of
the issues behind the problem – which will lead to a more robust solution.
To construct a fishbone, start with
stating the problem in the form of a question, such as “Why is the help desk’s
abandon rate so high?” Framing it as a “why” question will help in
brainstorming, as each root cause idea should answer the question. The team
should agree on the statement of the problem and then place this question in a
box at the “head” of the fishbone.
The rest of the fishbone then consists
of one line drawn across the page, attached to the problem statement, and
several lines, or “bones,” coming out vertically from the main line. These
branches are labeled with different categories. The categories you use are up
to you to decide
