Requirement

Engineering
Review of Last Lecture

Problems with requirement Requirement Engineering

Inception (Set of Questions)
Elicitation (Collaborative requirement gathering,
QFD)
Outline

ELABORATION / ANALYSIS OVERVIEW OF DIFFERENT

MODELING ANALYSIS MODELING TECHNIQUES
 Provides the first technical representation of a system

Is easy to understand and maintain

Goals of Analysis
Deals with the problem of size by partitioning the system

Uses graphics whenever possible

Modeling

Differentiates between essential information versus

implementation information

Helps in the tracking and evaluation of interfaces

Provides tools other than narrative text to describe software logic

and policy
 Analysis Rules of Thumb

• The analysis model should focus on requirements that are visible within the problem or business domain
• The level of abstraction should be relatively high
• Each element of the analysis model should add to an overall understanding of software requirements and provide
insight into the following
• Information domain, function, and behavior of the system
• The model should delay the consideration of infrastructure and other non-functional models until the design
phase
• First complete the analysis of the problem domain
• The model should minimize coupling throughout the system
• Reduce the level of interconnectedness among functions and classes
• The model should provide value to all stakeholders
• The model should be kept as simple as can be
 Structured analysis

• Considers data and the processes that

transform the data as separate entities
• Data is modeled in terms of only attributes and
Analysis relationships (but no operations)
• Processes are modeled to show the 1) input
Modeling data, 2) the transformation that occurs on that
Approaches data, and 3) the resulting output data

Object-oriented analysis

• Focuses on the definition of classes and the

manner in which they collaborate with one
another to fulfill customer requirements
Elements of the Analysis Model
Object-oriented Analysis Structured Analysis

Scenario-based Flow-oriented
modeling modeling
Use case text Data structure diagrams
Use case diagrams Data flow diagrams
Activity diagrams Control-flow diagrams
Swim lane diagrams Processing narratives

Class-based Behavioral
modeling modeling
Class diagrams
State diagrams
Analysis packages
Sequence diagrams
CRC models
Collaboration diagrams
 Scenario- • Describe the system from the user's point of view using
based scenarios that are depicted in use cases and activity
diagrams
elements

Elements of Class-based • Identify the domain classes for the objects manipulated by
the actors, the attributes of these classes, and how they
elements interact with one another; they utilize class diagrams to do

the Analysis
this

Model Behavioral • Use state diagrams to represent the state of the system, the
events that cause the system to change state, and the
elements actions that are taken as a result of a particular event; can
also be applied to each class in the system

Flow-oriented • Use data flow diagrams to show the input data that comes
into a system, what functions are applied to that data to do
elements transformations, and what resulting output data are
produced
Scenario-Based
Modeling
Developing Use Cases

• Step One – Define the set of actors that will be involved in the story
• Actors are people, devices, or other systems that use the system or product within
the context of the function and behaviour that is to be described
• Actors are anything that communicates with the system or product, and that is
external to the system itself
• Step Two – Develop use cases, where each one answers a set of questions
Questions Commonly Answered by a Use Case
• Who is the primary actor(s), the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the scenario begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the scenario is described?
• What variations in the actor’s interaction are possible?
• 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-case Diagram

Use-case diagram for surveillance function

Alternative Actions

• Can the actor take some other action at this point?

• Is it possible that the actor will encounter some error condition at this point?
• Is it possible that the actor will encounter behavior invoked by some event outside the
actor’s control?
Activity diagram for
Access camera
surveillance—display
camera views function
Swimlane
diagram
Summary Analysis Modeling

• Structured analysis
• Object oriented analysis

Object Oriented Analysis

• Scenario Based Modeling (Use

Cases, Swim lane Diagrams,
Activity Diagrams)