Requirements Analysis

Commonly cited root causes of failure

one third of the software projects
(Standish Group, 1994)

• Lack of user input

• Incomplete requirements and
specifications
• Changing requirements and specifications
 Relative cost to repair a
requirements error

100

Cost of
repairing a
requirements 10
error

0.1
Analysis Design Coding Testing Implementation
 User Needs, Software Features,
and Software Requirements
• Software requirements reflect specific
features of user needs.
Arise when business or technical problems are faced

A service that the system provides to fulfill

Problem
Domain Needs stakeholders’ need

Features •A software capability needed by the user

Solution to solve a problem to achieve an
Domain objective.
Software •A software capability that must be met or
Requirements possessed by the system or system
component to satisfy a contract, standard,
specification or other formally imposed
documentation.
 Classes of User Requirements
(Sommerville, 1999)

• Enduring Requirements: Core and stable

• Volatile Requirements: Change during
development or operation of the s/w
– Mutable requirements: change due to changes in the
environment
– Emerging requirements: appear as users begin using
the s/w
– Consequential requirements: appear when a
computer system replaces a manual one.
– Compatible requirements: appear when business
processes change
 Classes of User Requirements
(Robertson, 2000)

• Conscious (users are aware of them)

• Unconscious (users assume everyone
knows them)
• Undreamt of (user asks them when he
realizes it is possible)
 Sub-phases of Requirements
Phase
• Requirement gathering
• Systems analysis

Requirement
gathering

Effort
Systems analysis

Time
Endemic Syndromes in requirement
elicitation process
• The “Yes, But” syndrome
– stems from human nature and the users'
inability to experience the software as they
might a physical device
• The “Undiscovered Ruins” syndrome
– the more you find, the more you know remain
• The “User and Developer” syndrome
– reflects the profound differences between the
two, making communication difficult
 Difficulty in Understanding User
Information Requirements
• Limited rationality of human mind
• The variety and complexity of information
requirements
• Complex pattern of interaction among user
and analyst
• Unwillingness of some users to provide
requirements for political and behavioral
reason
Limited Rationality of Human Mind
• Humans are not very good information
processors.
• Limits on human short-term memory
• Bias in selecting and using data
– Anchoring and adjustment
– Concreteness
– Recency
– Intuitive statistical analysis
– Placing value on unused data
 Strategies for Determining
Information Requirements
• Asking
– Interviewing each user separately
– Group meetings
– Questionnaire Survey (Delphi Techniques)
• Deriving from an Existing Information System
– Existing information system
– System that is in operation in another, similar
organization
– System that is standardized and it exists in a package
that can be adopted and customized
– Systems described in textbooks, handbooks and alike
 Strategies for Determining
Information Requirements
• Synthesis from the characteristics of
utilized system
– Input-process-output analysis
– Decision analysis
• Discovering from Experimentation with an
existing Information System
– Prototyping
 Selecting an Appropriate Strategy
• Characteristics of the utilized system
• Complexity of the Information System
• Ability of the user to specify requirements
• Ability of the analysts to elicit and evaluate requirements
Prototyping

Synthesis

derived

Asking
Low High

Level of overall uncertainty

 Requirement Gathering
Sub-phases
• Set the project scope
• Search for requirement
• Write requirements
• Verify and validate requirements
• Review the requirement specifications
• Prototype the requirement
• Reuse requirements
 Work Context
Requirements
Set the project for Prototype Prototype the
scope requirement
Potential
Search for Requirement
requirements

Formalized
Requirement
Write the
requirements

Verify and
validate Reqmt

Reuse Requirements
Requirements Specification

Reviewed
Activities in Requirements Set the project
Specification scope
Gathering Sub-phases
 Set the Project Scope
• Recognize the stakeholders of the project
– The Client : Who pays for the development of the
product
– The Customer : Who is going to buy the product
– The User : Who is going to operate the product
– Management – The functional manager, the project
sponsor, the project leaders.
– Domain Analyst – Business consultant and analyst
who has some specialized knowledge about the
domain
– Developers – System analysts, product designer,
programmer, testers, database designers, technical
writers.
– Marketing Personnel: (If the product is for sale)
– Legal Personnel: Lawyers
– Oppositions – People who do not want the product
– Professional bodies - who sets guidelines and norms
– Public – In case the product is for the general public
– Government Agencies – In case some information
passes to the government
– Special Interest Groups – Environmental groups,
affected groups like workers, Senior citizens, religious
and ethnic groups.
– Technical Experts – Hardware and software experts
 Set the Project Scope
• Brainstorm the appropriate stakeholder
• Determine the work context and the product scope
– Product Purpose
• Statement of purpose, business advantage, reasonableness,
feasibility
– Requirement constraints
• Solution Constraints : Specific h/w, s/w, design, interfacing with
some existing product
• Project constraints : Time and Cost
– Names, aliases, and definitions
– The product scope
• The activity that the user needs
• Adjacent external systems and events they generate
• Response of the system under study to these events
– Preliminary estimates of time cost and risks involved
– Go / no-go decision
 Search for Requirement
• Understand how the work responses are generated
• Apprenticing
• Observe abstract repeating pattern
• Interviewing the users
• Getting essence of the system
• Business event workshops
• Requirements workshops
• Brainstorming
• Study of documents
• Making Videos
• Using electronic media
• Storyboards
• Scenario Models
 Prototyping the Requirements
• Need not be a s/w
– Drawings on a paper
– Clip-charts
– Use-cases on paper, white board or clip-
charts
• With reference to adjacent external system
events
• With reference to major tasks the product
is suppose to do
 Write the requirements
• Requirement template
– Product constraints
– Functional requirements
– Non-functional requirements
– Project issues
 Functional Requirements
• Functional requirements specify what the
product must do to satisfy the basic reason for
its existence. They are
– Specification of the products functionality
– The actions the product must take
– Derived from the basic purpose of the product
– Normally business oriented rather than technical
– Derived mostly from use case scenarios
– Not measurable or testable at this stage
– To be free from ambiguity
 Non-functional requirements
• The properties or the characteristics the
software product must have to perform a task
(functional requirements)
– Look and feel requirement
– Usability requirement
– Performance requirements
– Operational requirements
– Maintainability requirements
– Security requirements
– Cultural and political requirements
– Legal requirements
 Project Issues
• Off-the-self solutions
• New problems
• Tasks
• Risks
• Costs
• User Documentation
 Verify and Validate Requirements
• Examining the requirements listed in
requirement template to decide whether it
should be included in the Requirement
Specifications
– Establish fit criteria (measurable scales) for
each requirement
– Test each requirement for completeness
relevance and viability
 Establish Fit Criteria
• Fit criteria for
– Functional Features
Ex. The computed value shall agree with the specified scheme
provided by the user
– Non-functional features
Description: The product should not be offensive to Japanese
Fit Criterion: The cartoons used should be certified by the
Department of Japanese Studies
– Each use-case
Description: Generate master production schedule
Fit Criterion: The schedule will be made for a year and will be made
for the refrigeration division and air conditioning division only.
– Each constraints
Description: The product should be run on the windows operating
system
Fit Criterion: The product should be upward compatible from
Windows 2000 onwards
 Testing Requirements
• Completeness : Tests to find out missing requirements
– Data Models: DFDs, ER diagrams, Class Diagrams
– Object life history (or state) diagrams
• Traceability : Tests for finding features to enhance traceability
– Unique Identifier for each requirement
– An indicator for the type of requirements
– References to all business events and use cases
– References to dependant requirements
– References to conflicting requirements
• Consistent Requirements
– Defining Terms
– Using a term in a manner consistent with its specified meaning
– Looking for inconsistencies
• Relevance
– To the purpose of the product
 Testing Requirements
• Viability
– With specified constraints
• Solution boundedness
– Should not be described in terms of a solution
• Gold Plating
– Cost for providing a piece of information should not outweigh its
value
• Creep
– Searching for missed requirements
– Review of the requirements process
• Conflicting
– Requirements that are impossible or difficult to be implemented
simultaneously
• Ambiguity
– Making different interpretation of the same requirement
 Reviewing the requirements
specification
• By the customer, the user, the analyst etc.
• Individually and jointly
• Doubts must be mitigated
• Resulting Document
– User Requirements Specification (URS)
 Reusing Requirements
• Library of Generic Requirements
 Traditional Tools for
Requirements Gathering
 Document flow charts
• A document flow chart indicates the flow of
documents from one department to the other. It
brings light the following:
– The number of copies of a document
– The place (and/or the person) of origin of the
document
– The destination of the document (place and/or
person)
– The decisions and actions taken at various places (or
by various persons) where the document is sent.
 Why to use Document flow charts
• Documenting the existing information system
• Understanding the existing procedure of
decision making
• Convincing the client that the analyst has fully
understood the system
• Analyzing the good or bad points of the existing
system
– Identifying unnecessary movement of the documents
– Identifying wasteful and time-consuming procedures
– Suggesting new procedures
 Symbols used in
Document Flow Charts

Document Document and its copies Related Documents

Flow of document Storage of Document Annotation giving

textual explanation
 User Deputy Director DR F/A Suppliers Purchase
Department Department
Letter of
Letter of
Interest
Interest

Sanction for the

Letter of purchased obtained
Letter of
Interest
Interest

Sanction Sanction
Letter Letter

Funds Booking Done

Call for Mailed to
Quotation suppliers

Quotation
Quotation

Comparative
Statement

Sanction
Letter
 Tools for Representing
Condition-Action Combination
• Logic Flow Charts
• Structured English
• Decision Table
• Decision trees
• …
 Logic flow chart
Start

Yes No
Is it a textbook

Are funds available Are funds available

No Yes Yes No

Waitlist the book for Buy the books Buy the books Return the Reco to
next year HOD

Finish
 Structured English
In the book is a textbook
then if the funds are available
then buy the book
else waitlist the book for the next year
endif
else if the funds are available
then buy the book
else return the recommendation to the HOD
endif
endif
 Decision tables
• A compact way Conditions Decision Rules
• Conditions defined in a Text Books? Y Y N N
binary way Funds Available? Y N Y N
• Condition entries are
Actions
yes/no type
• The list of actions Buy X X
• Action entries are cross
Waitlist for next year X
marked to indicate the
appropriate action Return to HOD X
when a set of
conditions are satisfied.
 Removing Redundancies from the
Decision tables
• Identify two rules with Conditions Decision
Rules
same action.
Text Books? - Y N
• If they differ in their
Funds Available? Y N N
condition entries in
one row. They can be Actions

merged Buy X

Waitlist for next year X

Return to HOD X
 Identifying Misspecification Using
Decision Table
• More than one cross Conditions Decision
Rules
mark for decision a C1 Y Y N N
rule (ambiguity) C2 Y N Y N
• No cross mark for a Actions
decision rule (missing
A1 X X
action)
A2 X

A3 X

Ambiguity

Missing Action
 Conditions Decision Rules
Product is refrigerator? Y N

Decision Actions

Go to refrigerator Table X
Table
Go to air conditioner Table X
Hierarchy

Conditions Decision Conditions Decision

Rules Rules
Order Quantity > 10 Y Y N Order Quantity > 5 Y Y N
Delivery Time > 2 wks Y N - Delivery Time > 4 wks Y N -
Actions Actions

Give 20 % discount X Give 10 % discount X

Give 10 % discount X Give 5 % discount X

Do not give discount X Do not give discount X

Decision table vis-à-vis Logic Chart
Start
Y
N N
Math > 90% Phy > 90%

Y Y
N
Phy > 90%

Y
N
Total > 80%

Y
Admit on Do not
Admit probation Admit

Stop