Requirements Gathering

& Analysis

www.wgconsulting.com
 The Facts

 70% of organizations have suffered at least one project failure in the prior 12 months.

 50% of respondents also indicated that their project failed to consistently achieve
what they set out to achieve!

 Many organizations fail to measure benefits so they are unaware of their true status
in terms of benefits realization (success assessment).
Source: KPMG Study, Global IT Management Survey
Dec 2010

11/12/2019 2
 What is the problem?

 Too many project managers either overlook the importance of requirements

management or fail to understand the difference between scope, requirements,
and expectations.
 Scope = draws boundary b/w what’s in and what’s out of the projecct.

 In fact, 60-80 percent of project failures can be attributed directly to poor

requirements gathering, analysis, and management.

11/12/2019 3
 Why are requirements important?

 The requirements gathering or the discovery phase is essential to the

success of any project.

 Many experienced project managers would agree that if the

requirements are identified correctly and early in the project cycle there
would be a significant reduction in the project budget.

 If an effort to save time and project dollars, requirements gathering is

often overlooked or is not allocated enough time or budget.

11/12/2019 4
 Five key components of requirements gathering

1. Gathering requirements comes first, defining scope comes second.

It is fairly common in the project management world for people to use

the terms “requirements” and “scope” synonymously. But they are
different. “Requirements” define what is needed and “Scope” is how you
are going get there.

 “Requirements” are the demands, needs, and specifications for a

product as outlined by project stakeholders. The Deep Fried Brain
Blog defines requirements as what the customer needs.

 “Scope” is defined as the work that needs to be accomplished to

deliver a product, service, or result with the specified features and
functions.

11/12/2019 5
 Five key components of requirements gathering

2. There are two types of requirements: project requirements and

product requirements.

Project Requirements define how the work will be managed. Project

requirements focus on who, when, where, and how something gets
done.

Product Requirements include high level features or capabilities that the

business team has committed to delivering to a customer.

Project requirements must be defined first and then products evaluated

based on the best fit to these needs.

11/12/2019 6
 Five key components of requirements gathering

3. Make sure you adequately document all the requirements.

The requirements gathering process should be iterative and all discussions

documented and verified to make sure requirements were understood
correctly.

Requirements should be evaluated throughout the project to make sure

systems are not overly complicated, over designed and address the initial
needs defined at the beginning of the project.

11/12/2019 7
 Five key components of requirements gathering
4. Select the best methodology for the project.

The approach when developing a project must be determined for each

engagement based on the project team, the organization and the goals of
the project. In some cases, a hybrid of these methodologies is ideal.
A few examples of project methodology include:
RAD (Rapid Application Deployment) Spiral JAD (Joint Application Design)
• Used for less structured projects • Involves the client or end user in the
• Projects are divided to smaller design and development of an
initiatives application
• Prototyping is used • Collaborative workshops
Spiral • Requires dedicated resources
• Incremental build Scrum
• Additional functionality added later • Flexible and collaborative
• Prototyping used • General guidelines are set but
Waterfall constantly reevaluated
• Tightly defined objectives • Inspect and reevaluate
• Controlled process
• Major milestones with accountability
11/12/2019 8
 Five key components of requirements gathering

5. Engage a diverse cross section of users

It is always important to engage a broad group of users. Requirements

gathering sessions are usually effective in involving groups of users.

The facilitator of these discussions is critical providing leading questions,

understand the business and be able to gather information effectively.

It is often difficult for participants to articulate their daily routines and

processes. The success of requirements gathering is contingent on the
ability to extract detailed and high level information and then create a
global picture of the needs of the organization.

11/12/2019 9
 Requirements: The first critical step
“A good beginning makes a good ending.”
(Read yourself)
 The requirements gathering process may not guarantee a successful project but
provides a foundation for project that can be managed to meet well defined
objectives.

 Requirement gathering sessions should be designed to define business

processes, owners, and reporting needs.

 Requirements sessions should set a proactive tone for the project. Many project
teams get into the mindset of being reactive is addressing issues. A clear, concise
requirements document will create the baseline to building scope, project plans,
risk mitigation plans.

 Requirements provide the stepping stone to deriving scope. There are times
where at the end of the requirements phase, scope cannot be clearly defined. It
is essential at this point that the project methodology is modified to perhaps
include a proof of concept or prototyping phase.

11/12/2019 10
 Requirements: The first critical step

 Our requirements sessions are designed to be interactive and not follow a script.
This environment allows users to learn from the other subject manager experts
in the sessions as well as create a baseline for strong communication.

 These sessions should include how communication will be delivered, the project
team and their roles on the project and tools that will be used to document such
as an issues log, requirements matrix, or weekly status reports.

 A clear set of defined goals and objectives, reviewed throughout the term of the
project is a essential to manage expectations and avoid project pitfalls.

11/12/2019 11
 In general, one of the biggest problems that globally/nationally dispersed teams face in
requirements gathering and systems analysis is communication.

Solution?

11/12/2019 12
 Software Requirements Characteristics

 Gathering software requirements is the foundation of the entire software

development project. Hence they must be clear, correct and well-defined.
 A complete Software Requirement Specifications must be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source

11/12/2019 13
What kinds of specifications?

 Functional: What the system should do

 Non-Fictional: what constraints there are on the system its

development. (For example that a work processor runs on
different platforms)

14
What requirements should be gathered?
 Functional: What the product should do.

 Data requirements: Capture the type, volatility, size/amount, persistence,

accuracy and the amounts of the required data.

 Environmental requirements: a) context of use b) Social environment (eg.

Collaboration and coordination) c) how good is user support likely to be d)
what technologies will it run on

 User Requirements: Capture the characteristics of the intended user group.

 Usability Requirement: Usability goals associated measures for a particular

product.

15
Data Gathering Techniques

 Questionnaires:
– Series of questions designed to elicit specific information from us. The questions
may require different kinds of answers: some require a simple Yes/No, others ask
us to choose from a set of pre-supplied answers.

 Interviews:
– Interviews involve asking someone a set of questions. Often interviews are face-
to-face, but they don’t have to be (more on next page).

16
Data-gathering techniques

 Focus groups and workshops:

– Interviews tend to be one on one, and elicit only one person’s perspective. It can be very
revealing to get a group of stakeholders together to discuss issues and requirements.

 Naturalistic Observation:
– It can be very difficult for humans to explain what they do or to even describe accurately
how they achieve a task. (more on next page)

17
Data-gathering

 Studying documentation:
– Procedures and rules are often written down in a manual and these are a good source of
data about the steps involved in an activity and any regulations governing a task.

Use All of the above In Combination :

Constraints of Time and Money

18
Task Classification
 Is the Task a set of sequential steps or is it a rapidly overlaying series of
sub-tasks?

 Does the task involve high information content :

– High information content or low --- is it complex or simple to interpret visual
displays.

 Is the task intended to be performed by a layman without much training or

by a practitioner skilled in the task domain?

19
Data Gathering Guidelines

 Focus on identifying the stakeholders

 Involve all the stakeholder groups

 Need more than on person from stakeholder group(s)

 Use a combination of data gathering techniques

For example: use observation to understand the context, interviews to target
specific user groups, questionnaires to reach a wider population, and focus
groups to build a consensus view

20
Data Gathering Guidelines
 Support the data-gathering sessions with suitable props, such as task
descriptions and prototypes if available.
 Run a pilot session if possible to ensure that your data-gathering session is
likely to go as planned

 In an ideal world, you would understand what you are looking for and what
kinds of analysis you want to do, and design the data-capture exercise to
collect the data you want. However, data gathering is expensive and
often a tightly constrained resource.

21
Data interpretation and analysis

 What: structure and record description of requirement

 When: Start soon after data gathering session

22
Data interpretation and analysis

 Main Requirement analysis models in object-oriented systems

– Use cases diagrams:
consists of actors and user cases, discussed later
– Class diagrams
– More…
 How to develop those diagrams?
UML tools( useful in practice)

23
Requirement Validation
 Correct?
 Consistent?
 Complete?
– Externally - all desired properties are present.
– Internally - no undefined references.
 Each requirement describes something actually needed by the
customer.
 Requirements are verifiable (testable)?
 Requirements are traceable.

24
Requirements management

25
Requirements management

 What is it?
– a systematic approach to eliciting, organizing, and documenting the
requirements of the system,
– a process that establishes and maintains changing requirements.
– Important and helpful for real projects
 Common problems
– No.1: Can’t track change
– No.2: Difficult to write
– More…

26
How to Manage changing requirements
• Single channel of change control
• Change Control Board (CCB).

• Keep track history of

requirements
• Maintain version
control

27
How to document requirement?

 Requirement of description documents

– Natural language and graphical
– Widely accepted, consistent format

 Use tools to help

– Software<IBM Rational RequisitePro>
automating effective tool, template

28
Requirement Analysis

29
Analysis Principles

 Information domain of problem must be presented & understood.

 Models depicting system information, functions, and behavior should be
developed.
 Models and problems must be partitioned in a manner that uncovers detail
in layers.
 Analysis proceeds from essential information toward implementation detail
 Must be traceable.

30
Requirements Analysis

 Software engineering task bridging the gap between system requirements

engineering and software design.
 Provides software designer with a model of:
– system information
– function
– behavior
 Model can be translated to data, architectural, and component-level
designs.
 Expect to do a little bit of design during analysis and a little bit of analysis
during design.

31
Analysis Objectives

 Identify customer’s needs.

 Evaluate system for feasibility.
 Perform economic and technical analysis.
 Allocate functions to system elements.
 Establish schedule and constraints.
 Create system definitions.

32
Software Requirements Analysis Phases
 Problem recognition
 Evaluation and synthesis
– focus is on what not how
 Modeling
 Specification
 Review

33
Management Questions

 How much effort put towards analysis?

 Who does the analysis?
 Why is it so difficult?
 Bottom line - who pays for it?

34
Feasibility Study

 Economic feasibility
– cost/benefit analysis
 Technical feasibility
– hardware/software/people, etc.
 Legal feasibility
 Alternatives
– there is always more than one way to do it

35
System Specification

 Introduction.
 Functional data description.
 Subsystem description.
 System modeling and simulation results.
 Products.
 Appendices.

36
Modeling

 Data model
– shows relationships among system objects
 Functional model
– description of the functions that enable the transformations of system
objects
 Behavioral model
– manner in which software responds to events from the outside world

37
Partitioning

 Process that results in the elaboration of data, function, or

behavior.
 Horizontal partitioning
– breadth-first decomposition of the system function, behavior, or
information, one level at a time.
 Vertical partitioning
– depth-first elaboration of the system function, behavior, or information,
one subsystem at a time.

38
Requirements Views

 Essential view
– presents the functions to be accomplished and the information to be
processed while ignoring implementation
 Implementation view
– presents the real world realization of processing functions and
information structures
 Avoid the temptation to move directly to the implementation
view and assuming that the essence of the problem is obvious.

39
Specification Review

 Conducted by customer and software developer.

 Once approved, the specification becomes a contract for software
development.
 The specification is difficult to test in a meaningful way.
 Assessing the impact of specification changes is hard to do.

40
Requirements Review

 Goals & objectives review.

 Compare requirements to goals & objectives.
 Consider system operating environment.
 Assess and document all risks in system developmental operation.
 Discuss testing procedure.

41