All of us must have heard this proverb umpteen number of times in our lives. However, when it comes to elicitation, we tend to forget the same.Elicitation is possibly the most important job we business analysts do. I am surprised that many of us understand only few facets of elicitation such as requirements gathering and recording.Elicitation is much more than requirements gathering and recording. A good elicitation activity can significantly reduce effort in changes in requirements and subsequent changes to design, construction and testing activities.Here is an attempt to make our elicitation exercises more effective.

1. CRUTIAL STEPS IN
REQUIREMENT GATHERING

2. Hello!
I am Abhinav Sabharwal
You can find me at Skyabhinav@gmail.com
https://www.linkedin.com/in/abhinavsabharwal

3. ““A stitch in time saves nine.”

4. GATHER
ANALYZE
RECORD
VALIDATE
VERIFY
TRACE
CONFURM
REQUIRMENTS LIFECYCLE

5. GATHER REQUIREMENTS
◎ Gather requirements from various sources, primary one being from
stakeholders. Requirements can also be from existing system
documentation, competitor system documentation or from existing
system interfaces

6. Questionnaires
Sessions
REQUIREMENTS SOURSES

7. One-on-one Interviews
The most common
technique for gathering
requirements is to sit
down with the clients and
ask them what they need
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.
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 courage.
◎Joint application
development For a
requirements JAD
session, the participants
stay in session until a
complete set of
requirements is
documented and agreed
to
Questionnaires
Questionnaires are much
more informal, and they
are good tools to gather
requirements from
stakeholders in remote
locations
Prototyping
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.
REQUIREMENTS SOURSES
Request for proposals 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
Brainstorming
The appropriate subject
matter experts get into a
room and start creatively
brainstorming what the
solution might look like
Facilitated Sessions
In a facilitated session,
you bring a larger group
(five or more) together for
a common purpose.

8. CAPTURING REQUIREMENTS
◎ CAPTURING DATA REQUIREMENTS – ENTITY MODELLING
◎ CAPTURING FUNCTIONALITY REQUIREMENTS – USER STORIES
◎ CAPTURING FUNCTIONALITY REQUIREMENTS – USE CASES

9. ENTITY MODELLINGI
Entity modeling is used to
record the data that needs to
be stored, and the historical
facts that need to recalled at
a later stage.
Entity modeling also
documents the relationship
between entities, their
primary key (what makes a
record uniquely identifiable).
If the system is to have a
database at its core then we
would recommend that an
articulate DBA works with
the project stakeholders
CAPTURING REQUIREMENTS
USER STORIES
User stories record the
activities that different types
of operators do and their
effects on the system and
the data. Operators may be
particular staff roles (say
bookings manager) or other
people that interact with the
business (say customers) or
even other triggers (say a
timer).
Often it is good practice to
capture the user stories as
just “titles” to start with, then
priorities them, then add on
the explanation in a
“conservation phase”.
USE CASES
User Cases is a list of actions
or event steps, typically
defining the interactions
between a role (known in the
Unified Modeling Language
as an actor) and a system, to
achieve a goal.
The actor can be a human or
other external system. A use
case is a methodology used
in system analysis to identify,
clarify, and organize system
requirements. The use case is
made up of a set of possible
sequences of interactions
between systems and users
in a particular environment

10. REQUIRMENTS PHASE
Capture
Requirments
Validate
Requirments
Gather Requirments
C
o
m
m
o
n
T
o
o
l
s
Trace
Requirements

11. Requirements analysis, also called requirements engineering, is the process of determining
user expectations for a new or modified product. These features, called requirements, must be
quantifiable, relevant and detailed. In software engineering, such requirements are often called
functional specifications.
For Analyzing requirements take the following steps
1) Make Requirements S.M.A.R.T
2) MoSCoW the Requirements
3) Classify The Requirements
ANALYZE THE REQUIREMENTS

12. MAKE THEM SMART
Requirements should be
Specific – target a specific area
Measurable – quantify or at least suggest an indicator of progress.
Actionable – specify who will do it.
Realistic – state what results can realistically be achieved, given available resources.
Time-related – specify when the result(s) can be achieved.

13. MOSCOW THE REQUIREMENTS

14. MoSCoW
◎All requirements should be listed before commencing a project. Also, they should
be ranked according to their importance.
◎ This helps the entire team know what to develop first and what to leave, in case
there is a pressure on resources.
◎
MoSCoW is a method by which you can create a prioritized list of requirements.
◎
MoSCoW is essentially an acronym for Must, Should, Could, and Would:
◎By using the MoSCoW method, it is easy to prioritize which requirements should by
met with first, and which can come on later.
◎A clear set of prioritized requirements, agreed with the customer, alongside the
overall timescale and budget is essential.

15. MUST:
These requirements are
absolutely essential and
indispensable for
sustaining the viability of
the project. The
absence of these could
affect project objectives.
They are non-
negotiable. Therefore
you must have these
changes. used.
SHOULD:
These requirements
should be met with if
possible but the project
success does not rely
on it. The absence of
these could weaken the
case but the project
would still be capable of
meeting with its
objectives.
COULD:
These requirements are
useful but they do not
weaken the business
case. This means you
could have these, but
their absence will not
affect anything else in
the project.
WOULD:
These requirements are
not essential or
important in any way, so
they can wait. This
means you would like to
have these
requirements later.
MoSCoW

16. MoSCoW THE REQUIREMENTS
Requirem
ent
Must Have Should Have Could Have Would Have
Login Page X
Two Factor
Authenticati
on
X
Social
Media Login X X

17. CLASSIFY THE REQUIREMENTS

18. In software project management
Verification and Validation (V&V) is the process of checking that a software system meets
specifications and that it fulfills its intended purpose. It may also be referred to
as software quality control
VERIFICATION & VALIDATION
Verification is a process of evaluating
the intermediary work products of a
software development lifecycle to check
if we are in the right track of creating the
final product.
Validation is the process of evaluating the final
product to check whether the software meets the
business needs. In simple words the test
execution which we do in our day to day life are
actually the validation activity which
includes smoke testing, functional testing,
regression testing, systems testing etc

19. VERIFICATION & VALIDATION
Verification
Did we built the
thing right
In Other words
has it been built
as per design
Validation
Did we built the
right thing
In Other words
are the
specifications
correct

20. VERIFICATION & VALIDATION
Criteria Verification Validation
Definition The process of evaluating work-products (not
the actual final product) of a development
phase to determine whether they meet the
specified requirements for that phase.
The process of evaluating software during or at
the end of the development process to
determine whether it satisfies specified
business requirements.
Objective To ensure that the product is being built
according to the requirements and design
specifications. In other words, to ensure that
work products meet their specified
requirements.
To ensure that the product actually meets the
user’s needs, and that the specifications were
correct in the first place. In other words, to
demonstrate that the product fulfills its intended
use when placed in its intended environment.
Question Are we building the product right? Are we building the right product?
Evaluatio
n Items
Plans, Requirement Specs, Design Specs,
Code, Test Cases
The actual product/software.
Activities  Reviews, Walkthroughs & Inspections  Testing

21. VERIFICATION & VALIDATION

22. TRACE REQUIREMENTS
◎ Requirements tracing is the process of recording logical links between
individual requirements and other system elements.
◎ You can trace a single functional requirement backward to its origin, such as
a use case, product feature or business rule.
◎ You can also trace that functional requirement forward into the bits of
design, code and tests that were created because of that requirement.
◎ To do requirements traceability, the analyst must write requirements in a
fine-grained fashion and give every requirement a unique and stable
identifier.
◎ Start performing traceability by linking functional requirements to individual
tests that verify the correct implementation of those requirements.

23. Requirment.Tracibality.Matrix

25. There are two times during each project when sign off is
required on the requirements from the business
The first is when the business requirements document (BRD) is
complete. When the BRD is complete, you will have a sign off
list of people who will read and validate the document. Usually
this list includes the project sponsor, the steering committee, the
IT Lead, the project manager and the business lead.
Second is just prior to launch when the requirements traceability
matrix (RTM) is complete. The second time you need sign off is
when you have completed your requirements traceability matrix.
This ensures that the solution has met the functional
requirements.
A third review occurs during the testing phase if any
requirements cannot be met by the solution; at which time initiate
a gap analysis. Usually this document is prepared while you are
in testing, so any gaps identified would be noted on the gap
analysis document and you can obtain sign off at the same time
REQIRMENTS SIGNOFF

26. Thanks!
Any questions?
You can find me at skyabhinav@gmail.com