Requirement Analysis

Analysis Concepts and Principles

• Requirements Engineering

• The systematic use of proven principles,

techniques ,languages and tools for the cost-effective
analysis ,documentation and on-going evolution of the
external behavior of a system to satisfy those user
needs.
 Analysis Concepts and Principles
• Requirement Analysis
• This task is done to understand the specific requirements
that must be achieved to build high quality software.

• One who perform this task is called System Analyst.

• If analysis is not done properly, then it may result in a

software which is a solution of a wrong problem.

• It will lead to waste of money and time,personal

frustration and unhappy customers.
 Analysis Concepts and Principles
• Requirement analysis is a software engineering task that
bridges the gap between system level requirements
engineering and software design.
 Analysis Concepts and Principles
• Requirements engineering activities results in:

• the specification of software’s operational

characteristics (function,data and behavioural).

• Indicate software’s interface with other system elements

and

• establish constraints that the software must meet.

 Analysis Concepts and Principles
• Requirement analysis :

– allows the software engineer(system analyst) to refine software

allocation and build models of the data ,functional and behavioral
domains that will be treated by software.

– Provides the software designer with a representation of

information ,function and behavior that can be translated to
data ,architectural, interface and component level designs.

– The requirement specification provides the developer and the customer

with the means to assess quality once software is built.
 Analysis Concepts and Principles
• Software requirement analysis may be divided into five areas
of effort:
– Problem recognition
– Evaluation and Synthesis
– Modeling
– Specification
– Review
 Analysis Concepts and Principles
1. Problem recognition:
a) Initially ,the system analyst studies the system specification and the software
project plan.
b) Next, communication must be established for analysis so that problem
recognition is ensured. The goal is recognition of the basic problem elements as
perceived by the customers/users.

2. Problem Evaluation and Solution synthesis:

a) Problem Evaluation
i. The analyst must define all externally observable data objects .
ii. Evaluate the flow and content of information .
iii.Define and elaborate all software functions .
iv. understand software behavior in the context of events that
affect the system
v. Establish system, interface characteristics
vi. Uncover additional design constraints.
 Analysis Concepts and Principles
b) Solution synthesis:
Upon evaluating current problems and desired information
(input and output),the analyst begins to synthesize one or
more solutions.
1. First, data objects ,processing functions and behavior
of the system are defined in detail.
2. Second, the basic architecture for implementation are
considered.

– The process of evaluation and synthesis continues until

both analyst and customer feel confident that software can
be adequately specified for subsequent development steps.
 Analysis Concepts and Principles
– Throughout evaluation and synthesis ,the analyst‘s primary focus is on
“what” and not “how”.

– i.e. what does the system produce and consume, what functions must the
system perform, what behaviors does the system exhibit, what interfaces
are defined and what constraints apply.

3. Modeling
– the analyst creates models of the system in an effort to better understand
data and control flow ,functional processing ,operational behavior and
information content.

4. Specification
- Modeling serves as the foundation of specification.

5. Review
– Specification is reviewed by both analyst and customers
 Requirement Elicitation for Software
• Before the requirements can be analyzed, modeled or specified
,they must be gathered through an elicitation process.

• A customer will have a problem that is amenable to a

computer-based solution.

• The developer will respond to the customer’s request for help.

• Thus communication between customer and developer begins.

 Requirement Elicitation for Software
• Initiating the process
• Most commonly used requirement elicitation technique
is to conduct a meeting or interview.

• First meeting may not lead to get a clear idea, so they

should continue the communication.

• Analyst should ask some context-free questions.

• i.e. a set of questions that lead to a basic understanding

of the problem, the people who want a solution, the
nature of the solution that is desired and the
effectiveness of the first encounter itself.
 Requirement Elicitation for Software
• The first set of questions focuses on the customer, the
overall goals and the benefits.
• 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 that you need?

 Requirement Elicitation for Software
• The next set of questions enables the analyst to gain better
understanding of the problem and the customer to voice his
or her perceptions about a solution:
• How could you characterize “good” output that would be
generated by a successful solution?

• What problem(s) will this solution address?

• Can you show me the environment in which the solution will be

used?

• Will special performance issues or constraints affect the way the

solution is approached?
 Requirement Elicitation for Software
• The final set of questions focuses on the effectiveness
of the meeting:
• Are you the right person to answer these questions? Are
your answers official?
• Are my questions relevant to the problems that you may
have?
• Am I asking too many questions?
• Can anyone else provide additional information.
• Should I be asking you anything else?
 Requirement Elicitation for Software
• These questions will help to initiate the
communication that is essential to successful analysis.

• The question and answer meeting is not always

successful .

• It is useful for first encounter only.

• Then it is replaced by a meeting format that combines

elements of problem solving, negotiation and
specification.
Facilitated Application Specification Technique(FAST)

• Using question and answer meeting to identify and refine

requirements ,there may be misunderstandings, omissions of
information and a successful working relationship is never
established.

• Therefore a team-oriented approach is used to requirements

gatherings that is applied during early stages of analysis and
specification.

• FAST is a technique used for that accomplish a team-oriented

approach.
 Facilitated Application Specification
Technique(FAST)
• FAST is an approach that encourages :
– the creation of a joint team of customers and developers, who works
together to identify the problem,
– propose elements to the solution
– negotiate different approaches and
– specify a preliminary set of solution requirements.

Many different approaches to FAST have been proposed,each

using a different scenario.
 Facilitated Application Specification
Technique(FAST)
• Basic guidelines followed by FAST:

– A meeting is conducted at a neutral site and attended by both

software engineers and customers.

– Rules for preparation and participation are established.

– An agenda is suggested that is formal enough to cover all

important points, but informal enough to encourage the free flow
of ideas.

– A facilitator (can be a customer ,a developer or an outsider) is

chosen.
 Facilitated Application Specification
Technique(FAST)
– A “definition mechanism”(can be a worksheets ,flip charts
or wall stickers or an election bulletin board, chat room or
virtual forum) is used.

– The goal is to :
• identify the problem
• propose elements of the solution
• negotiate different approaches and
• specify a preliminary set of solution requirements in an
atmosphere that is conductive to accomplishment of the goal
 Facilitated Application Specification
Technique(FAST)
• Sequence of events in FAST include:
1. Initial meetings between the developer and customer occur
and basic questions and answer help to establish the scope
of the problem and the overall perception of a solution.

2. Out of these initial meetings ,the developer and customer

write a one-or –two page “product request”.

3. A meeting place ,time and date for FAST are selected and
facilitator is chosen.
 Facilitated Application Specification
Technique(FAST)
4. Attendees from both the development and customer/user
organizations are invited to attend.

5. The product request is distributed to all attendees before the

meeting date.

6. While reviewing the request in the days before the

meeting ,each FAST attendee is asked to make a list of :
i. objects that are part of environment that surrounds the
system,
ii. other objects that are produced by the system and
iii. objects that are used by the system to perform its
functions.
 Facilitated Application Specification
Technique(FAST)
7. In addition, each attendee is asked to make another list of
services (processes or functions) that manipulate or interact
with the objects.

8. Finally ,list of constraints (e.g. cost,size ,business rules ) and

performance criteria (e.g.speed ,accuracy) are also
developed.
 Facilitated Application Specification
Technique(FAST)
• E.g. Product: "Safe Home”( to avoid and protect undesirable situations
such as illegal entry, fire ,flooding etc.)

– Here FAST team may contain representation from marketing,

software and hardware engineering and manufacturing.

– An outside facilitator is to be used.

– Objects may include:

• smoke detectors
• window and door sensors
• motion detectors,
• an alarm
• an event,
• a control panel
• a display, telephone numbers
 Facilitated Application Specification
Technique(FAST)
– List of services include:
• setting the alarm
• monitoring the sensors
• dialing the phone
• programming the control panel
• reading the display etc.
– List of constraints include:
• Cost of manufacture should be less than $80.
• Must be user-friendly.
• Must interface directly to a standard phone line.
– Performance criteria include:
• Sensor event should be recognized within one second.
• An event priority scheme should be implemented.
 Facilitated Application Specification Technique(FAST)
• As the FAST meeting begins ,the first topic of discussion is
the need and justification for the new product-everyone should
agree that the product is justified.

• Once the agreement has been established each participant

presents his/her list for discussion.

• It is pinned on the walls of the room using large sheets of

paper, or written on a wall board or posted on a electronic
bulletin board for review prior to the meeting.

• Each list should be capable of being manipulated separately so

that lists can be combined, entries can be deleted and additions
can be made.
• At this stage critique and debate are strictly prohibited.
 Facilitated Application Specification Technique(FAST
• After individual lists are presented in one topic area, a
combined list is created by the group.

• The combined group eliminates redundant entries, adds any

new ideas that come up during discussion ,but does not delete
anything.

• After combined lists for all topic areas have been

created ,discussion coordinated by the facilitator ensues.

• The combined list is shortened ,lengthened or reworded to

properly reflect the product/system to be developed.
 Facilitated Application Specification Technique(FAST
• The objective is to develop a consensus list in each topic area.
(objectives , services , constraints and performance)

• The lists are then set aside for later action.

• Once the consensus list have been completed ,the team is

divided into smaller sub-teams ; each work to develop mini-
specifications for one or more entries on each of the lists.
 Facilitated Application Specification Technique(FAST

• E.g.For Safe Home Project ,mini-specification for control

panel

– Mounted on the wall

– Size approximately 9×5 inches
– Contain standard 12-key pad and special keys
– Contain LCD display
– Customer interaction through keys
– Connected to all sensors.
 Facilitated Application Specification Technique(FAST
• Each sub team then presents each of its mini-specs to all FAST
attendees for discussion. Additions ,deletions and further
elaboration are made.

• After the mini-specs are completed ,each FAST attendee make a

list of validation criteria for the product/system and present
his/her list to the team.

• A consensus list of validation criteria is then created.

• Finally one or more participants is assigned to task of writing the

complete draft specification using all inputs from the FAST
meeting.
 Quality Function Deployment(QFD)

• QFD is a quality management technique that translates the

needs of the customer into technical requirements for
software.

• QFD concentrates on maximizing customer satisfaction from

the software engineering process.

• QFD emphasizes an understanding of what is valuable to the

customer and then displays these values throughout the
engineering process.
 Quality Function Deployment(QFD)

• QFD identifies three types of requirements:

1. Normal Requirements
• The objectives and goals that are stated for a
product or system during meetings with the
customer.
• If these requirements are present ,customer is
satisfied.
• examples of normal requirements might be
requested type of graphical displays ,specific
system functions and defined level of
performance.
 Quality Function Deployment(QFD)

2. Expected Requirements
• These requirements are implicit to the product or
system and may be so fundamental that the
customer does not explicitly state them.
• Their absence will be a cause of significant
dissatisfaction.
• Examples of expected requirements are:
• Human/machine interaction
• Overall operational correctness
• Reliability and ease of software installation.
 Quality Function Deployment(QFD)

3. Exciting Requirements
• These features go beyond the customer’s expectations
and prove to be very satisfying when present.
• For e.g. word processing software is requested with
standard features.
• The delivered product contains a no. of page layout
capabilities that are quite pleasing and unexpected.

QFD spans the entire engineering process.

 Quality Function Deployment(QFD)
• Concepts adapted for a computer software during the
meeting with the customer are:
• Function deployment:
• Used to determine the value of each function that is required
for the system
• Information deployment
• Identifies both the data objects and events that the system
must consume and produce. These are tied to functions.
• Task deployment
• Examines the behavior of the system or product within the
context of its environment.
• Value Analysis
• Is conducted to determine the relative priority of
requirements determined during each of the three
deployments
 Quality Function Deployment(QFD)
• QFD uses customer interviews and observations ,surveys and
examination of historical data(e.g Problem report) as raw data
for requirements gathering activity.

• These data are the translated into a table of requirements –

called customer voice table –that is reviewed by the customer.

• A variety of diagrams ,matrices and evaluation methods are

the used to extract expected requirements and to attempt to
derive exciting requirements.
 USE-CASES
• As the requirements are gathered as a part informal
meeting ,FAST or QFD ,the software engineer (analyst) can
create a set scenarios that identify a thread of usage for the
system to be constructed .

• The scenarios ,called as use-cases provide a description of

how the system will be used.

• To create a use-case ,the system analyst must first identify the

different types of people or device that use the system or
product and are called actors.
 USE-CASES
• These actors usually represent roles that people play as the
system operates.

• Actor:is anything that communicates with the system or

product and that is external to the system itself.

• Actor and user are not the same thing.

• A user may play a no. of different roles when using a system,

while an actor plays only one role.
 USE-CASES
• E.g. Consider a machine operator (a user) who interacts with a
control computer for a manufacturing cell, that contain no. of
robots and numerically controlled panels.

• Software for the control computer has four different modes (roles)
of interaction: programming mode, testing mode, monitoring mode
and troubleshooting mode..

• Therefore four actors can be defined: programmer,tester,monitor

and troubleshooter

• In some cases ,the machine operator may play all these roles or in
other different people may play the role of each actor.
 USE-CASES

• Requirements elicitation can be evolutionary .

• So all actors are not identified during the first iteration
• i.e. primary actors in the first iteration, secondary in the next
and so on
• Once the actors have been identified ,use-cases can be
developed.
• The use-cases describes the manner in which an actor interacts
with the system.
 USE-CASES
• Some questions that are to be answered by the use-cases:

– What main tasks or functions are performed by the actor?

– What system information will the actor acquire, produce or

change?

– Will the actor have to inform the system about changes in the
external environment?

– What information does the actor desire from the system?

– Does the actor wish to be informed about unexpected changes?

 USE-CASES
• Use-case
– Is a written narrative that describes ,the role of an actor as
interaction with the system occurs.

– Each use-case provides an unambiguous scenario of

interaction between the actor and the software.

– It can also be used to specify timing requirements or other

constraints for the scenario.
 USE-CASES
• Eg:SafeHome
• Three actors:
• Homeowner(user)
• Sensors(devices attached to the system)
• Monitoring and response subsystem

Homeowner actor:interacts with the system in number of

different ways:
– Enters a password to all other interactions
– Inquires about the status of a security zone
– Inquires about the status of a sensor
– Presses a panic button in emergency
– Activates /deactivates the security system
Use-Case
 USE-CASES
• A use-case for system activation follows:
1. Home owner observes a prototype of a SafeHome control panel to determine if
the system is ready for input.if the system is not ready,the homeowner must
physically close windows/doors so that the ready indicator is present.A not
ready indicator implies that a sensor is open ie the door or window is open

2. The homeowner uses the keypad to key in a four –digit password.The password
is compared with the valid password stored in the system.If the password is
incorrect ,the control panel will beep once and reset itself for additional input.If
the password is correct ,the control panel awaits further action

3. The homeowner selects and keys in stay or away to activate the system.Stay
activates only parameter sensors(inside motion detecting sensors are
deactivated).Away activate all sensors

4. When activation occurs ,a red alarm light can be observed by the homeowner
 Analysis Principles
• Large no. of analysis modeling methods have been developed.
• All methods are related by a set of operational principles:
1. The information domain of a problem must be represented and
understood.

2. The functions that the software is to perform must be defined.

3. The behavior of the software (as a consequence of external events)

must be represented.

4. The models that depict information ,function and behavior must be

partitioned in a manner that uncovers detail in a layered or hierarchical
fashion.

5. The analysis process should move from essential information toward

implementation detail.
 Analysis Principles

Some guiding principles for requirements engineering are:

1. Understand the problem before you begin the analysis model.
• Rushing to a solution before understanding the problem
leads to an elegant software that solves a wrong problem.
2. Develop prototypes that enable a user to understand how
human/machine interaction will occur.
3. Record the origin and the reason for every requirements.
4. Use multiple views of requirements
• Building data, functional and behavioral model
provide three different views
5. Rank requirements
6. Work to eliminate ambiguity
 The Information Domain
• Software applications are called data processing.
• It accept input, manipulate it in some way and produce output.
• Software also processes events .
• An event represents some aspect of system control and is a
Boolean data.
• For e.g. ,a pressure sensor detects that the pressure exceeds a
safe value and sends an alarm signal to monitoring software.
• The alarm signal is an event that controls the behavior of the
system.
• The data (text,number,image etc. )and control (events) both
reside within the information domain of a problem.
 The Information Domain
• The information domain contain three different views of data
and control as each is processed by a computer program:

1. Information content and relationships(data model)

2. Information flow
3. Information structure
 The Information Domain
1. Information content and relationship:
• information content --> represent the individual data and
control objects
• there are different relationships between data and objects

2. Information flow:
• represents the manner in which data and control change as
each moves through a system.
• Input objects are transformed to intermediate information
(data and /or control),which is further transformed to
output.
• Along this transformation path ,additional information can
be introduced from an existing data store(e.g. a disk file or
memory buffer)
• Data and control that moves between two transformations
(functions) define the interface for each function.
 The Information Domain

3. Information structure:
• represent the internal organization of various data and
control items and tell whether it is organized as
- data tree structure
- data table (n-dimension)
 Modeling
• Models are created to gain a better understanding of the actual
entity to be built.

• For a physical thing ,we can build model with identical form
and shape but smaller scale.

• But for software it takes a different form.

• It must be capable of representing:
– the information that software transforms, the functions(and
sub functions)
– Events that enable the transformation to occur and
– the behavior of the system as the transformation is taking
place.
 Modeling

• Types of models include:

– Functional Models
– Behavioral Models
 Modeling
 Functional models
o Software transforms information , and for that it has to
perform at least three functions: input ,processing and
output.

o While creating functional models, software engineer

focuses on problem specific functions.

o The functional model begins with a single context level

model(name of the software)

o Over a series of iterations ,more and more functional

detail is provided until complete functionality is
presented.
 Modeling
• Behavioral model
– Most software responds to events from the outside world.

– This stimulus/response characteristic forms the basis of

behavioral model.

– Software states(waiting , computing , printing)is changed

when some event occurs.
 Modeling
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 mapped into an implementation context.
 Partitioning

• Partitioning decomposes a problem into its constituent parts.

• Establish a hierarchical representation of information (or
function) and then partition the uppermost element by:

- exposing increasing detail by moving vertically in the

hierarchy

- functionally decomposing the problem by moving

horizontally in the hierarchy.
 Partitioning

Horizontal partition

SafeHome Software

Configure system Monitor sensors Interact with user

Vertical partition Poll for sensor event Activate alarm functions

Activate audible alarm Dial phone number

 Software Prototyping
• After requirement elicitation an applying analysis principles, a model
of the software to be built ,called a prototype is constructed for
customer and developer assessment.

• This model then evolves into production software.

• The prototyping approach can be either close-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 the software is engineered using a
different paradigm.

• The open-ended approach is called evolutionary prototyping.

- a prototype serves as the first evolution of the finished system.
 Software Prototyping
• Before choosing the approach it is necessary to determine whether
the system to be built is amenable to prototyping .

• This is done based on the factors like application area ,application

complexity, customer characteristics and project characteristics.

• If the software application demands dynamic visual displays or if

it interacts heavily with the user ,then the evolutionary fashion is
used.

• If the software has tens of thousands of lines of code, then

prototyping the software becomes complex.

• It can be done in parts by partitioning the complexity.

 Prototyping Methods and Tools

• Software prototyping to be effective ,a prototype must be developed

rapidly so that the customer may assess results and recommend changes.

• Prototyping Methods and Tools:

- Fourth Generation Techniques

» Encompass a broad array of database query and
reporting languages, program and application
generators and other very high level non procedural
languages.

- Reusable Software Components

» Prototyping can be done by a assembling rather than
building by using a set of existing software
components.

-
 Prototyping Methods and Tools
– Formal Specification and Prototyping Environments
» Formal specification languages and tools have been
developed .
» It provides interactive environments that
1. Enable an analyst to interactively create
language-based specifications of a system or a
software.

2. Invoke automated tools that translate the

language-based specifications into executable
code.

3. Enable the customer to use prototype

executable code to refine formal requirements.
 Specification
Specification principles include:

1. Separate functionality from implementation

2. Develop a model of the desired behavior of a system

3. Establish the context in which software operates

4. Define the environment in which the system operates

5. Create a cognitive model rather than a design or implementation

model

6. Specification is an abstract model of a real system

7. Establish the content and structure of a specification (easy to be

changed)
 Representation
Guidelines for representation:
1. Representation format and content should be relevant to the
problem

– A general format for SRS can be developed

– Vary with application area.
– i.e .symbology,diagrams and language used for specification
may differ.

2. Information contained within the specification should be nested

– Representations should reveal layers of information so that a

reader can move to the level of detail required.
– Paragraph and diagram numbering should indicate the level
of detail required.
 Representation

3. Diagrams and other notational forms should be restricted

in number and consistent in use

– Confusing or inconsistent . Notation ,whether graphical or

symbolic ,degrades understanding and fosters errors

4. Representations should be revisable

– The content of specification will change .

– Ideally CASE tools should be available to update all
representations that are affected by each change.
 Software Requirement Specification
• A Software Requirement Specification is produced at the
culmination of the analysis task.

• Organization of Software Requirement Specification :

• Introduction
• Information description
• Functional description
• Behavioral description
• Validation criteria
• Bibliography and Appendix
Software Requirement Specification
1. Introduction
– States the goals and objectives of the software.
– It is the software scope of the planning document.
2. Information description
– Provides the detailed description about the problem
that the software must solve.
– Information content,flow and structure are
documented .
– Hardware ,software and human interfaces are
described for external system elements and internal
software functions
 Software Requirement Specification
3. Functional description
– Description of each function required to solve the
problem
– A processing narrative is provided for each function
– Design constraints are stated and justified.
– Performance characteristics are stated
– Graphically representation of the overall structure of
the software and interplay among software functions
and other system elements.
4. Behavioral description
– Examines the operations of the software as a
consequence of external events and internally
generated control characteristics.
 Software Requirement Specification
3. Validation criteria
– How do we recognize a successful implementation?
– What classes of tests must be conducted to validate
function, performance and constraints?
4. Bibliography and Appendix
– Bibliography Contains references to all documents
that relate to the software.
– Include other software engineering documentation,
technical references, vendor literature and standards.
– Appendix contains information that supplements the
specifications.
– Tabular data ,detailed description of
algorithms,charts,graphs and other materials.
 Software Requirement Specification
• In many cases ,the Software Requirement Specification may be
accompanied by an executable prototype or a paper prototype
or a Preliminary User’s Manual .

• The manual is a valuable tool for uncovering problems at the

human/machine interface.
 Specification review
• A review of Software Requirement Specification is conducted by
both software developer and the customer.

• Review is first conducted at the macroscopic level.

• Reviewers must first ensure that specification is complete,

consistent and accurate.

• In detailed review ,vague terms are specified for further

clarification.

• Once the review is complete , “Software Requirement

Specification “ is signed off by both customer and developer.

• The specification becomes a “contract” for software development.