Requirements Analysis Concepts and Principles

- Requirements Analysis

- Communication Techniques
- Initiating the Process
- Facilitated Application Specification Techniques
- Analysis Principles
- Information Domain
- Modeling
- Partitioning
- Software Prototyping
- Selecting the Prototyping Approach
- Prototyping Methods and Tools
- The Software Requirements Specification
- Specification Principles
- Representation

Stages in RE

Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Management
2

Inception
ask a set of questions that establish

basic understanding of the problem

the people who want a solution
the nature of the solution that is desired
the effectiveness of preliminary communication
and collaboration between the customer and the
developer

Elicitation
elicit requirements from all stakeholders
address problems of scope
address problems of understanding
customers are not sure about what is needed, skip
obvious issues, have difficulty communicating
with the software engineer, have poor grasp of
problem domain

address problems of volatility (changing

requirements)
4

Elaboration and negotiation

Elaboration: create an analysis model that identifies data,
function, features, constraints and behavioral requirements
Negotiation: agree on a deliverable system that is realistic
for developers and customers
rank requirements by priority (conflicts arise here )
identify and analyze risks assoc. with each requirement
guestimate efforts needed to implement each
requirement
eliminate, combine and / or modify requirements to
make project realistic
5

Specification
can be any one (or more) of the following:

A written document
A set of models
A formal mathematical model
A collection of user scenarios (use-cases)
A prototype

Validation
a review mechanism that looks for:

errors in content or interpretation

areas where clarification may be required
missing information
inconsistencies (a major problem when large
products or systems are engineered)
conflicting or unrealistic (unachievable)
requirements
tests for requirements

Management
involves managing change:
Feature traceability: how requirements relate to
observable system/product features
Source traceability: identifies source of each
requirement
Dependency traceability: how requirements are
related to each other
Subsystem traceability: categorizes requirements by
the sub system (s) they govern
Interface traceability: how requirements relate to both
external and internal system interfaces
8

Requirements Analysis
A process of discovery, refinement, modeling, and specification.
The software scope initially established by system engineer and refined during
software project planning is refined in detail.
During the process, both the developers and customers take an active role.
Focus on:

what instead of how

Input of the requirements analysis process:

- Software Project Plan
- System specification (if one exists)
Output:

Software requirements specification document

- provides the software engineer with models that can be translated
in to data, architectural, interface, and procedure design.
- customer and developer can check the quality of the software
and provide the feedback.

Who perform requirements analysis:

system analysts

Requirement Analysis specify

- Softwares operational characteristics(data,functional & behavioral)
- Softwares interface with other system elements
- Establish constraints that software must meet

Requirements Analysis
Major tasks and efforts:
- Problem recognition (or system understanding)
- Discover and understand the system requirements
- Refine the requirements
- Evaluation and synthesis:
- what are the alternative solutions
- focus on what solution should be selected or used
instead of how to implement a solution.
-focuses on what not how
- Modeling: to represent the various aspects of the system
- the required data
- information and control flow
- operation behavior
- Specification of:
- software functions, and performance
- interfaces between system elements
- system constraints
-Review

Requirements Analysis Process

- Domain understanding:
- Understanding of application domain.
- Requirements collections:
- The process of interacting with customers, users to discover
the requirements for the system.
- Requirements classification:
- Group and classify the gathered requirements.
- Conflict resolution:
- Resolve the conflict requirements.
- Prioritization:
- Identify and list requirements according to their importance
- Requirements validation:
- Check and validate the gathered requirements to see
if they are complete, correct, and sound.

Requirements Analysis Process

Requirements
definition and
specification
Requirements
validation

Domain
understanding
Prioritization

Requirements
collection

Conflict
resolution

Classification

Communication Techniques
Requirement Analysis always begins with communication
Initiating the Process
Facilitated Application Specification Techniques(FAST)
Quality Function Deployment

Initiating the Process

Analysis technique to bridge communication gap between customer &
developer.
Starts with preliminary meeting or interview
First meeting neither person knows what to say & what they say will be
interpreted.
But communication initiated.
Starts with context free questions.(set of questions will lead to basic
understanding of the problem.
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution?
Is there another source for the solution they need?
Next set of questions(better understanding)
How would you characterize good output that would be generated by
a successful solution
What problems will this solution address
Can you show the environment in which the solution is used?
Are there special performance issues or constraints?

Final set of questions(meta questions-focus on effectiveness of the

meeting)
Are you the right person to answer these questions? Are your
answers official?
Are my questions relevant to the problem that you have?
Am I asking too many questions?
Is there anyone else who can give additional information?
Is there anything else that I should be asking you?

Facilitated Application Specification Techniques (FAST)

Customers and software engineers often have an unconscious us and them
mind set.
This may cause: misunderstandings, miss important information,.
To solve the problem, FAST approach is proposed.
FAST encourages the creation of a joint team of customers and developers.
They work together
- to identify the problem
-propose elements of the solution
- to negotiate the different elements of solutions and approaches
-specify preliminary set of solution requirements
The basic guidelines of FAST:
- hold a meeting at a neutral site
- establish rules for preparation and participation
- have a formal meeting agenda that cover all important points but
informal enough to encourage free flow of ideas
- control the meeting by a facilitator(customer , developer or
outsider)
- use a definition mechanisms (work sheets,flip charts,wall
stickers)
- have a common goal to identify the problem , propose elements of
solutions and requirements, negotiate different approaches

Initial meeting with developer and customer

Basic question & answers help to establish scope of the problem
Outcome is a one-two page product request
A meeting place,time and date for FAST are selected and a facilitator is
chosen
Representatives from both development & customer organization are invited to
attend
Product Request is distributed to all attendees.
Each attendees must make a list of objects that are part of environment that
surround the system, other objects that are to be produced by system, objects
used by the system to perform its functions.
Make a list of services that manipulate and interact with objects
Make a list of constraints (size,cost,weight) and performance criteria(speed &
accuracy)
The list reflects each persons perception of the system.
As meeting begins first topic is the need and justification for the new product.
Once agreement is reached, each participant presents his lists for discussion
The list can be pinned to the walls of the room.
List can be combined, entries can be deleted and additions can be made.
Combined list is created by the group without redundant entries
Once the list have been completed the team is divided into smaller teams to
develop mini specification(elaboration of word or phrase in the list)

Each subteam presents its mini specification to all FAST attendees for
discussion.
Development of mini specification may lead to new objects that will be added
to the original list.
Team may raise an issue that cannot be resolved. An issue list is maintained.
Validation criteria list is created by each attendee and give to the team
Finally one or more participant is assigned the job to complete the draft
specification.

Quality Function Deployment

Quality function deployment (QFD) is quality management technique
- Translate the needs of the customer into technical requirements for software.
QFD identifies three types of requirements:
- Normal requirements:
Objectives and goals that are stated for product during meeting.If these are
present customer is satisfied.
examples: types of graphic displays, specific system functions

- Expected requirements:
implicit requirements . Customer may not specify during meeting. But their
absence will cause dissatisfaction.
examples: ease of human-machine interaction
ease of software installation
- Exciting requirements:
Features go beyond the customers expectations

In meetings with customer

Function Deployment-determine the value of each function that is
required for the system.
Information Deployment-identifies both data objects & events that the
system must consume and produce.
Task Management- examines the behavior of the system.
Value Analysis- to determine the relative priority of requirements during
each of above requirements.

Customer voice table-Raw data collected from customer during

interview, observations, surveys and examination of historical data is
translated into a table

Analysis Principles
Each analysis method has a unique point of view.
All analysis methods are related by a set of operational principles:
- represent and understand the information domain
- define the functions that the software is to perform
- represent the behavior of the software
- use models to depict information, function, and behavior
--> uncover the details in a layered fashion.
- move from essential information toward to details

A set of guidelines for requirement engineering:

- understand the problem before beginning to create the analysis model
- develop prototypes to help user to understand how human-machine interactions
- record the origin of and the reasons for every requirement
- use multiple views of requirements
- prioritize requirements
- work to eliminate ambiguity

The Information Domain

Software is built to process data, to transform data from one form to another.
Software also process events.
The first operational analysis principle requires to exam the information domain.
Information domain contains three different views of the data and control:
- information content and relationship:
information content --> represent the individual data and control objects
there are different relationships between data and objects
- information flow:
represents the manner in which data and control change as each moves through
a system. Data and control moves between two transformations (functions)
- information structure:
represent the internal organization of various data and control items
- data tree structure
- data table (n-dimension)

Modeling
During software requirements analysis, we create models of the system to be
built.
When entity to be built is software it must be capable of modeling the
information the software transforms , functions that enable transformations and
behavior.
The models focus on:
- what the system must do, not how it does it.
The models usually have a graphic notation to represent:
- information, processing, system behavior, and other features
The second and third operational analysis principles require:
- build models of function and behavior
- Functional models
Software transforms information. Three generic functions:
- input, processing, output
Begin with a single context level model. Over series of iterations more
functional
detail is provided.
- Behavior models
Most software responds to events from the outside world.
A behavior model creates a representation of the states of the software
and events that cause software to change state

Important roles of models:

- The model aids the analyst in understanding the information,
function, and behavior of a system.
- The model becomes the focal point for review in the aspects of
completeness, consistency, and accuracy of the specification.
- The model becomes the foundation for design, providing the
designer with an essential representation of software that can
be translated into an implementation context.

Modeling approaches

26

Partitioning
Partitioning decomposes a problem into its constituent parts and establish interfaces
between parts
Establish a hierarchical representation of information (or function):
- exposing increasing detail by moving vertically in the hierarchy
- decomposing the problem by moving horizontally in the hierarchy.
Horizontal partition

SafeHome Software

Configure system

Vertical partition

Monitor sensors

Poll for sensor event

Interact with user

Activate alarm functions

Activate audible alarm

Dial phone number

Essential & Implementation Views

Essential views- presents the functions to be accomplished &
information to be processed without regard to implementation details
Implementation View-presents the real world manifestation of
processing functions and information structures.

Software Prototyping
Analysis should be conducted regardless of software engineering paradigm. But form of
analysis will vary.
In some cases, it is possible to apply operational analysis principles and derive a model of
software from which a design can be developed.
In some cases requirement gathering or other brainstorming techniques is conducted and
model of software is built called prototype is constructed for customer & developer
assessment.
In some cases prototype is constructed at the beginning of the analysis since model is the
only means through which requirements can be effectively derived. The model then evolves
into production software.

Selecting the prototyping approach

Prototyping paradigm can be either closed ended or open ended.
The closed-ended approach is called throwaway prototyping.
- a prototype serves only as a rough demonstration of
requirements. It is then discarded and software is engineered using
different paradigm.
The open-ended approach is called evolutionary prototyping.
- a prototype serves as the first evolution of the finished system.
Before a closed ended or open ended approach is chosen it is necessary
to determine whether the system to be built is amenable to prototyping.
Prototyping candidacy factors: application area, application complexity,
customer characteristics and project characteristics.

Questions assisting in the selection of the prototyping approach

Is the application domain for which software is to be built understood by the customer and
the developer?
Does the problem to be solved lend itself to modeling?
Is the customer fairly certain of basic system requirements
Are requirements fairly well established and likely to be reasonably stable?
Are any requirements ambiguous?
Are there contradictions in the requirements?

Prototyping Methods and Tools:

To conduct rapid prototyping
- Fourth Generation Techniques
- Reusable Software Components
- Formal Specification and Prototyping Environments

Software Specification
Specification principles:
- Separate functionality from implementation
- Develop a model of the desired behavior of a system
- Establish the context in which software operates
- Define the environment in which the system operates
- Create a cognitive model rather than a design or implementation
model
- Specification is an abstract model of a real system, so can be
incomplete.
- Establish the content and structure of a specification (easy to be
changed)
Guidelines for representation:
- Representation format and content should be relevant to the problem
- Information contained within the specification should be nested
-Diagrams and other notational forms should be restricted in number and
consistent in use.
- Representations should be revisable

Software Requirements Specification

Is the result (final stage) of analysis task.

Framework for the specification

I. Introduction
A. System Reference
B. Overall Description
C. Software Project Constraints
II. Information Description
A. Information Content Representation
B. Information Flow Representation
1. Data Flow
2. Control Flow
III. Functional Description
A. Functional partitioning
B. Functional Description
1. Processing Narrative
2. Restrictions/Limitations
3.Performance Requirements
4. Design Constraints
Supporting Diagrams

34

Software Requirements Specification

C. Control Description
1. Control Specification
2. Design Constraints
IV. Behavioral Description
A. System States
B. Events and actions
V. Validation and Criteria
A. Performance bounds
B. Classes of tests
C. Expected Software response
D. Special considerations
VI. Bibliography
VII. Appendix

35

Introduction states goals and objectives of the software. Nothing more than
software scope of the planning document.
Information description- detailed description of the problem. Information
content & relationships, flow and structure are documented.
Functional description- description of each function
Behavioral description-examines the operation of the software as a
consequence of external events and internally generated control characteristics
Bibliography contains references to all documents that is related to the
software.

Specification Review
Review done by both customer & developer
Since specification forms the foundation for design & subsequent software
engineering activities
Review is first conducted at a macroscopic level.
Ensure that specification is complete, consistent and accurate.

Detailed level- to answer many of the questions that arise during the first
level.
Once review is complete SRS is signed off by customer & developer.
SRS becomes the contract for software development.
The specification is difficult to test in a meaningful way
Assessing the impact of specification changes is hard to do

37