UNIT 2:Requirement Engineering

Requirement Engineering,
Collaborative Requirements Gathering,
Quality Function Deployment,
Elicitation Work Product,
Developing use cases,
Building the requirement model,
Validating requirements,
Analysis: Scenario Based Modeling,
UML Models, Class-Based Modelling,
Requirements Modeling Strategies: Flow oriented modelling,
SRS plan, Case study
 Requirement Engineering
• Requirements engineering provides the appropriate mechanism for
understanding what the customer wants, analyzing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the
requirements as they are transformed into an operational system.
• Def1: Requirement Engineering is a process of discovery,
refinement, modeling, and specification.
• Def2: Requirements engineering is the systematic use of proven
principles, techniques, languages, and tools for the cost effective
analysis, documentation, and on-going evolution of user needs and
the specification of the external behavior of a system to satisfy those
user needs.
 The requirements engineering process can be described
in six distinct steps
1. Requirements Elicitation — determining what the customer requires
2. Requirements Analysis & negotiation — understanding the relationships among
various customer requirements and shaping those relationships to achieve a
successful result
3. Requirements specification — building a tangible model of requirements
4. System Modeling — building a representation of requirements that can be
assessed for correctness, completeness, and consistency
5. Requirements Validation — reviewing the model
6. Requirements Management — identify, control and track requirements and the
changes that will be made to them
 What Are the Real Problems?

• The customer has only a vague idea of what is required

• The developer is willing to proceed with the "vague idea"
on the assumption that "we'll fill in the details as we go"
• The customer keeps changing requirements
• The developer is "racheted" by these changes making errors
in specifications and development,and so it goes dificult.
 REQUIREMENTS ELICITATION FOR SOFTWARE
1. Requirements Gathering
1. Initiating the Process: conduct a meeting or interview asking
context-free questions (informal)
• 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?
2. better understanding of the problem
• How would you characterize "good" output that would be generated
by a successful solution?
• What problems will this solution address?
• Can you describe the environment in which the solution will be used?
• Will special performance issues or constraints affect the way the
solution is approached?
3. 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 problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
Facilitated Application Specification Techniques (FAST)
• Communicates through a series of memos, formal position
papers, documents, and question and answer sessions-
Doesnot work very well
• FAST- Creation of a joint team of customers and developers
who work together to
- identify the problem,
-propose elements of the solution,
- negotiate different approaches ,
-specify a preliminary set of solution requirements.
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) controls
the meeting.
• A "definition mechanism" (can be work sheets, flip charts, or wall
stickers or an electronic bulletin board, chat room or virtual forum) is
used.
 Example: Safe home system

• Initial meetings between the developer and customer occurs.

-to establish the scope of the problem and overall perception of a solution.
-the developer and customer write a one- or two-page "product request."
-A meeting place, time, and date for FAST are selected and a facilitator is chosen.
-Attendees from development and customer organizations are invited to attend.
-The product request is distributed.
each FAST attendee is asked to make a
- list of objects that are part of the environment that surrounds the system, other
objects that are to be produced by the system, and objects that are used by the system
to perform its functions.
- list of services (processes or functions) that manipulate or interact with the objects.
- lists of constraints (e.g., cost, size, business rules) and performance criteria (e.g.,
 Product description
• Our research indicates that the market for home security systems is
growing at a rate of 40 percent per year.
We would like to enter this market by building a microprocessor-based
home security system that would protect against and/or recognize a
variety of undesirable "situations" such as illegal entry, fire, flooding, and
others.
The product, tentatively called SafeHome, will use appropriate sensors to
detect each situation, can be programmed by the homeowner, and will
automatically telephone a monitoring agency when a situation is
detected.
• List of Objects: SafeHome might include smoke detectors, window and door
sensors, motion detectors, an alarm, an event (a sensor has been activated), a
control panel, a display, telephone numbers, a telephone call.
• The list of services : setting the alarm, monitoring the sensors, dialing the phone,
programming the control panel, reading the display.
• Lists of constraints : manufactured cost of less than Rs 5000, must be user-
friendly, must interface directly to a standard phone line and performance criteria
( a sensor event should be recognized within one second)
• Everyone should agree that the product is justified(Need )
• Each participant presents his lists for discussion.
• The lists can be pinned to the walls of the room using large sheets of paper, stuck
to the walls using adhesive backed sheets, or written on a wall board. Alternatively,
the lists may have been posted on an electronic bulletin board or posed in chat
room environment for review prior to the meeting.
combined list is created by the group. The combined list eliminates redundant
entries, adds any new ideas that come up during the discussion.
 Mini-Specifications

Elaboration of the word or phrase contained in list

• SafeHome object control panel_x0002_
• mounted on wall
• size approximately 9 x 5 inches
• contains standard 12-key pad and special keys
• contains LCD display
• all customer interaction occurs through keys
• used to enable and disable the system
• software provides interaction guidance, echoes, and the like
• connected to all sensors
Each FAST attendee makes a list of validation criteria for the product/system
and presents list to the team.
 Quality Function Deployment(QFD)
• A quality management technique that translates the needs of the
customer into technical requirements for software.
• Emphasizes an understanding of what is valuable to the customer and
then deploys these values throughout the engineering process.
• QFD identifies three types of requirements
1. Normal 2. Expected 3. Exciting
• Normal requirements.
If these requirements are present, the customer is satisfied.
Ex-requested types of graphical displays, specific system functions, and
defined levels of performance.
QFD....

• Expected requirements. These requirements are implicit to the

product . So fundamental that the customer does not explicitly state
them.Their absence will be a cause for significant dissatisfaction.
Examples: ease of human/machine interaction, overall operational
correctness and reliability, and ease of software installation.
• Exciting requirements. These features go beyond the customer’s
expectations and prove to be very satisfying when present.
For example, word processing software is requested with standard
features. The delivered product contains a number of page layout
capabilities that are quite pleasing and unexpected .
 Use-Cases
• A set of scenarios that identify a thread of usage for the system to be constructed.
Provide a description of how the system will be used.
• Identify the different types of people (or devices) that use the system or product.
These actors actually represent roles that people (or devices) play as the system
operates.
• An actor is anything that communicates with the system or product and that
is external to the system itself.
• User may plays no of roles while using system. while actor plays single role.
Ex- consider a machine operator (a user) who interacts with the control computer
for a manufacturing cell that contains a number of robots and numerically controlled
machines.
Software for the control computer requires four different modes (roles) for
interaction. Programming mode, test mode, monitoring mode, and troubleshooting
mode.
• Once actors have been identified, use-cases can be developed.
• The use-case describes the manner in which an actor interacts with the
system.
What are 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?
The three actors:
• The home owner (the user),
• Sensors (devices attached to the system),
• The monitoring and response subsystem (the
central station that monitors SafeHome).
The home owner interacts with the product in a
number of different ways:
• enters a password to allow all other
interactions
• inquires about the status of a security zone
• inquires about the status of a sensor
• presses the panic button in an emergency
• activates/deactivates the security system
 A use-case for system activation

1. The homeowner observes a prototype of the 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;
i.e., that a door or window is open.]
2. The homeowner uses the keypad to enter 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 stay or away to activate the system. Stay
activates only perimeter sensors (inside motion detecting sensors are
deactivated). Away activates all sensors.
4. When activation occurs, a red alarm light can be observed by the
homeowner.
 Software Requirements Analysis
• Identify the “customer” and work together to negotiate
“product-level” requirements
• Build an analysis model
focus on data
define function
represent behavior
• Prototype areas of uncertainty
• Develop a specification that will guide design
• Conduct formal technical reviews
 The Analysis Process
build a
prototype

requirements develop
the problem elicitation Specification Review

create
analysis
models
 Requirement Analysis 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.
 Requirements Analysis Guidelines (Davis’ Principles)
• Understand the problem before you begin to create the
analysis model.
• Develop prototypes that enable a user to understand how
human-machine interaction will occur.
• Record the origin of and the reason for every requirement.
• Use multiple views of requirements(Models).
• Prioritize(rank) requirements.
• Work to eliminate ambiguity.
 Analysis Modeling
1. The Information Domain
• software applications can be collectively called data
processing.
• process data, to transform data from one form to another; that is,
to accept input, manipulate it in some way, and produce output.
• key to our understanding of software requirements.
• Software also processes events.
• An event represents some aspect of system control and is really
nothing more than Boolean data—it is either on or off, true or
false.
 Analysis Modeling
1. Functional models.

Software transforms information,

- it must perform at least three generic functions: input, processing, and
output.
-functional models the software engineer focuses on problem specific
functions.
-The functional model begins with a single context level model (i.e., the
name of the software to be built).
Over a series of iterations, more and more functional details are provided,
until all system functionality is represented.
 Modeling

2. Behavioral models.
• Most software responds to events from the outside world.
• This stimulus/response characteristic forms the basis of the behavioral model.
• A computer program always exists in some state—(e.g., waiting, computing,
printing, polling) that is changed only when some event occurs.
For example, software will remainin the wait state until
(1) an internal clock indicates that some time interval has passed,
(2) an external event (e.g., a mouse movement) causes an interrupt, or
(3) an external system signals the software to act in some manner.
A behavioral model creates a representation of the states of the software and the
events that cause a software to change state.
Use of Models created during requirements analysis
• The model aids the analyst in understanding the information,
function, and behavior of a system, thereby making the
requirements analysis task easier and more systematic.
• The model becomes the focal point for review and,
therefore, the key to a determination of completeness,
consistency, and accuracy of the specifications.
• 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.
• Hierarchical representation
• Partition the uppermost element by (1) exposing increasing detail by
moving vertically in the hierarchy (2) functionally decomposing the
problem by moving horizontally in the hierarchy .
 Essential and Implementation Views
An essential view:
• Presents the functions to be accomplished and information to be
processed without regard to implementation details.
• SafeHome function read sensor status does not concern itself with the
physical form of the data or the type of sensor that is used.
The implementation view:
• presents the real world manifestation of processing functions and
information structures.A SafeHome input device is a perimeter sensor
(not a watch dog, a human guard).
• The sensor detects illegal entry by sensing a break in an electronic
circuit.
• The general characteristics of the sensor should be noted as part of a
software requirements specification.
 SOFTWARE PROTOTYPING
• 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 other situations, requirements elicitation (via FAST, QFD, use-cases,
techniques is conducted, analysis principles are applied, and a model of
the software to be built.Prototype
• Prototype is constructed for customer and developer assessment.
• In some Circumtances ,construction of a prototype at the beginning of
analysis, since the model is the only means through which
requirements can be effectively derived.
 Prototyping Approach

• The prototyping paradigm can be either close-ended or open-ended

• The close-ended approach is often called throwaway prototyping.
• Rough demonstration of requirements.It is then discarded.
• An open-ended approach, called evolutionary prototyping, uses the
prototype as the first part of an analysis activity that will be
continued into design and construction.
• The prototype of the software is the first evolution of the finished
system.
 Selecting the appropriate prototyping approach

Question Throwaway Evolutionary Additional

prototype prototype preliminary
work required
Is the application domain Yes Yes No
understood?
Can the problem be modeled? Yes Yes No
Is the customer certain of basic Yes/No Yes/No No
system requirements?
Are requirements established and No Yes Yes
stable?
Are any requirements ambiguous? Yes No Yes
Are there contradictions in the Yes No Yes
requirements?
 Prototyping Methods and Tools
• Software prototyping to be effective, a prototype must be developed
rapidly.
1. Fourth generation techniques(4GT):
-Enable the software engineer to generate executable code quickly.
-Encompass a broad array of database query and reporting languages,
program and application generators, and other very high-level
nonprocedural languages.
2. Reusable software components:
-To assemble, rather than build, the prototype by using a set of existing
software components.
-Program component reuse will work only if a library system is
developed.
-Existing software product can be used as a prototype for a "new,
improved" competitive product.
 Prototyping Methods and Tools......

• Formal specification and prototyping environments:

-Number of formal specification languages and tools have been
developed as a replacement for natural language specification
techniques.
-formal languages and Interactive environments
(1) Enable an analyst to interactively create language-based
specifications of a system or software.
(2) Invoke automated tools that translate the language-based
specifications into executable code.
(3) Enable the customer to use the prototype executable code to refine
formal requirements.
 Requirements Validation
• Requirements are assessed for quality during a validation step.
• To ensure that all system requirements have been stated
unambiguously.
• Inconsistencies, omissions, and errors have been detected and
corrected.
Validation mechanism is the formal technical review.
The review team includes stakeholders (system engineers,
customers, users) who examine the system specification.
 Checklist Questions......

• Are requirements stated clearly? Can they be misinterpreted?

• Is the source of the requirement identified?
• Has the final statement of the requirement been examined by or
against the original source?
• Is the requirement bounded in quantitative terms?
• What other requirements relate to this requirement? Are they clearly
noted via a cross-reference matrix or other mechanism?
• Does the requirement violate any domain constraints?
 Checklist Questions......

• Is the requirement testable? If so, can we specify tests (sometimes

called validation criteria) to exercise the requirement?
• Is the requirement traceable to any system model that has been
created?
• Is the system specification structured in a way that leads to easy
understanding, and easy translation into more technical work
products?
• Has an index for the specification been created?
• Have requirements associated with system performance, behavior,
and operational characteristics been clearly stated? What requirements
 Software Requirement Specification
• Representation guidelines :software requirements may be specified in a variety of
ways.
1. Representation format and content should be relevant to the problem.
-representation forms contained within the specification are likely to vary with the
application area.
For example, a specification for a manufacturing automation system might use
different symbology, diagrams and language than the specification for a programming
language compiler.
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 schemes should indicate the level of detail that is
being presented.
 Representation guidelines.......

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 a specification will change. Ideally, CASE tools
should be available to update all representations that are
affected by each change.
 Software Requirement Specification Formats

• Introduction:
- States the goals and objectives of the software.
-Software scope of the planning document.
• The Information Description
-provides a detailed description of the problem to be solved.
-Information content, flow, and structure are documented.
-Hardware, software, and human interfaces are described for external
system elements and internal software functions.
 SRS Format.......

• Functional Description
-A description of each function required to solve the problem is
presented.
-A processing narrative is provided for each function.
-design constraints are stated and justified, performance characteristics
are stated.
-diagrams are included to graphically represent the overall structure of
the software
• Behavioral Description
- examines the operation of the software as a consequence of external
events and internally generated control characteristics.
 SRS Format
• Validation Criteria
-Most important and, the most often neglected section
-How do we recognize a successful implementation?
-What classes of tests must be conducted to validate function,
performance, and constraints?
• Bibliography and Appendix.
-contains references to all documents that relate to the software.
-These include other software engineering documentation, technical
references, vendor literature, and standards.
- The appendix contains information that supplements the
specifications.
-Tabular data, detailed description of algorithms, charts, graphs, and
other material are presented as appendixes.
 Software Requirement Specification Review
• Conducted by both the software developer and the customer.
• To ensure that the specification is complete, consistent, and
accurate.
• Specifications contain “vague terms” (e.g., some, sometimes, often,
usually,mostly), the reviewer should flag the statements for further
clarification.
• The specification becomes a "contract" for software development.
• Requests for changes in requirements after the specification is
finalized will not be eliminated. But Change increase cost and/or
protract the schedule.
 Model : A picture is worth a thousand words!

• Imagine you were driving to a destination, but missed a

turn on your way. Would you prefer to reconfigure your
route with the help of a map, or ask for directions?
Perhaps, a map would be better, as you would be able
to figure out roads and places based on images.
• A map could thus be called as a 'model', because it
represents the actual places and areas you would come
across while driving. Similarly, in software
engineering, a model represents a software product.
Model : A picture is worth a thousand words!

UML Models
 The Unified Modeling Language (UML)
• The UML is a standard language that is used to effectively describe a
model, using both visual elements and text, just as in your map.
• General purpose modelling language
• The main aim of UML is to define a standard way to visualize the way
a system has been designed.
• UML is not a programming language.
• Rather it is a pictorial language consisting of symbols, diagrams, text,
pseudo-code or anything that describes a software system.
• UML combines techniques from data modeling, business
modeling,object modeling and component modeling.
 UML Models
A UML model is a representation of a software in terms of it's structure,
behavior and interactions, before the actual coding process begins.
This model is usually used to describe an object oriented programming
approach.
Considering the complexity of a software product, a UML model is
made up of different types of diagrams.
Elements of UML model diagrams
Class: You would use this element to describe all the classes your
software system would have.
Contain an object's attributes and behavior.
 UML Model Components....

• Object: You would use this element to describe all the objects
you would create inside your classes.
• Interface: You would use this element to create method
signatures without implementing any code, i.e you would just
describe the functions of a method. A class would then be able
to implement the interface by implementing its functionality.
• Collaboration: Using this element, you would describe the
interaction between various elements.
• Use case: Here, you would describe how a user interacts with
the software system.
 UML Model Components....

• Node: This element is use to represent any physical parts of

the system , for example , a server.

• Package: You would use this element to group similar

classes or components together under a namespace.

• Note: You would use this element to add comments or

explanations in your diagrams.
UML diagrams represents two different views of system model

1. Static (Structural View): Emphasizes static 2. Dynamic (Behavioural view):Emphasizes

structure of system using objects, attributes, dynamic behaviour of system by showing
operations and relationship collaboration amoungst objects and changes
to the internal states of objects.
• all objects have the similar attributes and operations.
• Inheritance: from the base class you can
inherit a derived class.
-Allows to define a new class(derived class)
by extending an existing class(base class)
-Represents generalization-specialization
-Allows redinition of the existing
method(overriding)
Association Multiplicity
 Class Diagram
• Static Relation ship between classes
• Association Teacher 1 1..*
Student
Teaches to

• Dependancy
Consumer supplier

• Aggregation
(No dependancy of conained Library
1..* Books
class on container class)
container class contained class

A B
• Composition(Strong dependancy
of conained class on container class) whole part

• Generalization
Generalization

Person
specilization
Generalization

student teacher
The Analysis Model

Data Model

Functional
Model
Behavioral
Model
 Analysis Principle I
Model the Data Domain
• Define data objects
• Describe data attributes
• Establish data relationships
 Analysis Principle II
Model Function
• Identify functions that transform data objects
• Indicate how data flow through the system
• Represent producers and consumers of data
 Analysis Principle III
Model Behavior

• indicate different states of the system

• specify events that cause the system to change state
 Analysis Principle IV
Partition the Models
• refine each model to represent lower levels of abstraction

• refine data objects

• create a functional hierarchy

• represent behavior at different levels of detail

 Analysis Principle V
Essence
• begin by focusing on the essence of the problem without regard to

implementation details
• Prototyping Other Topics
• Specification
• Principles
• Representation
• Software Requirements Specification (SRS)
• Intro
• Information description
• Functional description
• Behavioral description
• Validation criteria
• Bibliography and index
• Review the SRS