Transcript Document

Lecture 6

Requirement analysis




Functional Modeling
Object Modeling
Dynamical Modeling
Non-functional requirements
Slides adopted from the book and lecture
material for the “Object oriented software
engineering” by Bruegge & Dutroit
SW Development Process

Requirement analysis


System Analysis


Describes how the system is realized.
Implementation


Identifies the structure of the system.
Design


Describes what the system is supposed to do.
Implements the system and performs unit testing
Testing

Verifies system
Requirement Analysis: Overview

Three types of modeling




Functional modeling
Object modeling
Dynamic modeling
Functional Modeling: What are the
transformations?
 Create scenarios and use case diagrams

Talk to client, observe, get historical records, do
thought experiments
Requirement Analysis: Overview

Object Modeling: What is the structure of the system?
 Create class diagrams




Identify objects. What are the associations between them?
What is their multiplicity?
What are the attributes of the objects?
What operations are defined on the objects?
Dynamic Modeling: What is its control structure?
 Create sequence diagrams



Identify senders and receivers
Show sequence of events exchanged between objects.
Identify event dependencies and event concurrency.
Create state diagrams

Only for the dynamically interesting objects.
How to do Analysis




Analyze the problem statement
 Identify functional requirements
 Identify non-functional requirements
 Identify constraints (pseudo requirements)
Build the functional model:
 Develop use cases to illustrate functionality requirements
Build the dynamic model:
 Develop sequence diagrams to illustrate the interaction
between objects
 Develop state diagrams for objects with interesting behavior
Build the object model:
 Develop class diagrams showing the structure of the system
Problem Statement:
Direction Control for a Toy Car





Power is turned on
 Car moves forward and car
headlight shines
Power is turned off
 Car stops and headlight goes
out.
Power is turned on
 Headlight shines
Power is turned off
 Headlight goes out.
Power is turned on
 Car runs backward with its
headlight shining.




Power is turned off
 Car stops and
headlight goes out.
Power is turned on
 Headlight shines
Power is turned off
 Headlight goes out.
Power is turned on
 Car runs forward
with its headlight
shining.
Find the Functional Model:
Do Use Case Modeling


Use case 1: System Initialization
 Entry condition: Power is off, car is not moving
 Flow of events:
 Driver turns power on
 Exit condition: Car moves forward, headlight is on
Use case 2: Turn headlight off
 Entry condition: Car moves forward with headlights on
 Flow of events:
 Driver turns power off, car stops and headlight goes
out.
 Driver turns power on, headlight shines and car does
not move.
 Driver turns power off, headlight goes out
 Exit condition: Car does not move, headlight is out
Use Cases continued


Use case 3: Move car backward
 Entry condition: Car is stationary, headlights off
 Flow of events:
 Driver turns power on
 Exit condition: Car moves backward, headlight on
Use case 4: Stop backward moving car
 Entry condition: Car moves backward, headlights on
 Flow of events:
 Driver turns power off, car stops, headlight goes out.
 Power is turned on, headlight shines and car does not
move.
 Power is turned off, headlight goes out.
 Exit condition: Car does not move, headlight is out.
Use cases continued

Use case 5: Move car forward
 Entry condition: Car does not move, headlight is
out
 Flow of events
 Driver turns power on
 Exit condition:
 Car runs forward with its headlight shining.
Use Case Pruning

Do we need use case 5?

Use case 1: System Initialization


Entry condition: Power is off, car is not moving
Flow of events:



Driver turns power on
Exit condition: Car moves forward, headlight is on
Use case 5: Move car forward



Entry condition: Car does not move, headlight is out
Flow of events
 Driver turns power on
Exit condition:
 Car runs forward with its headlight shining.
Find the Dynamic Model:
Create sequence diagram


Name: Drive Car
Sequence of events:








Billy turns power on
Headlight goes on
Wheels starts moving forward
Wheels keeps moving forward
Billy turns power off
Headlight goes off
Wheels stops moving
...
Sequence Diagram for Drive
Car Scenario
:Headlight
:Wheel
Billy:Driver
Power(on)
Power(off)
Power(on)
Power(on)
Power(off)
Power(on)
Toy Car: Dynamic Model
State-Chart Diagram
Wheel
Headlight
Off
power
off
Forward
power
off
power
on
power
on
Stationary
Stationary
On
power
on
power
off
Backward
Toy Car: Object Model
Car
Power
Headlight
Wheel
Status: (On, Off)
Status: (On, Off)
TurnOn()
TurnOff()
Switch_On()
Switch_Off()
Motion:( Forward
Backward,
Stationary)
Start_Moving()
Stop_Moving()
For which system is a particular
model most relevant?

Object model: The system has non-trivial data
structures.


Dynamic model: The model has many different
types of events: Input, output, exceptions, errors,
etc.
Functional model: The model performs
complicated transformations such as difficult
computations consisting of many steps.
For which system is a particular
model most relevant?

Examples:



Compiler: Functional model most important. Dynamic
model is trivial because there is only one type input and
only a few outputs.
Database systems: Object model most important.
Functional model is trivial, because their purpose is
usually only to store, organize and retrieve data.
Spreadsheet program: Functional model most
important. Object model is trivial, because the
spreadsheet values are trivial and cannot be structured
further. The only interesting object is the cell.
Why Scenarios and Use Cases?

Comprehensible by the user


Use cases model a system from the users’ point of view
(functional requirements)
 Define every possible event flow through the system
 Description of interaction between objects
Use cases can form basis for whole development
process





User manual
System design and object design
Implementation
Test specification
Client acceptance test
Identifying Use Cases

Engage in a dialog, use an evolutionary,
incremental approach
 You help the client to formulate the
requirements
 The client helps you to understand the
requirements
 The requirements evolve while the use
cases are being developed
How to Specify a Use Case


Name of Use Case
Actors


Precondition


Free form, informal natural language
Exceptions


Use a phrase such as “This use case starts when…”
Flow of Events


Description of actors involved in use case
Describe what happens if things go wrong
Special Requirements

List nonfunctional requirements and constraints
From Use Cases to
Requirement Analysis Model



Both focus on the requirements from the user
point of view.
Use cases use natural language (derived from
problem statement)
 Written scenarios
Requirements analysis model uses formal or
semi-formal notation (UML)
 System sequence diagrams
 Domain model
Identify Conceptual Classes

Candidate classes are possible class names
that are being considered as candidates for
inclusion in the system.
Techniques:
 noun phrase identification from use case
model or documentation
 Brainstorming
 CRC cards
 Design patterns
Noun Phrase Identification




Read and understand the use case scenarios.
Look for noun phrases, mark the nouns
Divide into three categories
 Definite object
 Possible object
 Nonsense object
Discuss “possible objects” and assign them to either
of the two other categories
Example







Computer system for library:
Books and Journals: The library contains books and
journals. There can be multiple copies a particular book.
Books can be borrowed by a library user for a period of
six weeks.
Loans: The system needs to keep track of which books
are on loan and when they are due.
Possible candidates for conceptual classes: library,
system, book, journal, copy, user, period, week, loan
Nonsense objects: week, system
Possible objects: library, period
Definite objects: book, journal, copy, loan, user
Definition: Object Modeling


Main goal: Find the important abstractions
Steps during object modeling





1. Class identification
 Based on the fundamental assumption that we can
find abstractions
2. Find the attributes
3. Find the methods
4. Find the associations between classes
Order of steps



Goal: get the desired abstractions
Order of steps secondary, only a heuristic
Iteration is important
Class Identification




Identify the boundaries of the system
Identify the important entities in the system
Class identification is crucial to objectoriented modeling
Basic assumption:


1. We can find the classes for a new software
system (Forward Engineering)
2. We can identify the classes in an existing
system (Reverse Engineering)
Class Identification



Objects are not just found by taking a picture
of a scene or domain
The application domain has to be analyzed.
Depending on the purpose of the system
different objects might be found



How can we identify the purpose of a system?
Scenarios and use cases
Another important problem: Define system
boundary.

What object is inside, what object is outside?
Pieces of an Object Model


Classes
Associations (Relations)



Attributes



Part of- Hierarchy (Aggregation)
Kind of-Hierarchy (Generalization)
Detection of attributes
Is something an attribute or a class (e.g. money)
Methods



Detection of methods
Generic methods: General world knowledge, design
patterns
Domain Methods: Dynamic model, Functional model
Object vs Class





Object (instance): Exactly one thing

The lecture on Wednesday 19/9 from 8-10 on Analysis
A class describes a group of objects with similar properties

Sale, Customer, Item, Lecture…
Object diagram: A graphic notation for modeling objects,
classes and their relationships ("associations"):
Class diagram: Template for describing many instances of
data. Useful for taxonomies, patters, schemata...
Instance diagram: A particular set of objects relating to
each other. Useful for discussing scenarios, test cases and
examples
Class and Instance Diagrams
Inspector
joe:
Inspector
mary:
Inspector
Class Diagram
anonymous:
Inspector
Instance Diagram
Attributes and Values
Inspector
name:string
age: integer
joe:Inspector
mary: Inspector
name = “Joe”
age = 24
name = “Mary”
age = 18
Links and Associations



Links and associations establish relationships among
objects and classes.
Link:
 A connection between two object instances. A link
is like a tuple.
 A link is an instance of an association
Association:
 Basically a bidirectional mapping.
 One-to-one, many-to-one, one-to-many,
 An association describes a set of links like a class
describes a set of objects.
1-to-1 and 1-to-N Associations
Country
has-capital
name
City
name
1-1 association
Order
date
contains
1-N association
Item
* price
productID
Object Instance Diagram
Example for 1-to-N
:Item
:Order
:Item
Price:5,50
ItemID : 23
Price:9,90
ItemID : 105
:Item
Price:105,00
ItemID : 98
Many-to-Many Associations
Customer
*
places
*
Order
Aggregation



Models "part of" hierarchy
Useful for modeling the breakdown of a product
into its component parts
UML notation: Like an association but with a
small diamond indicating the assembly end of
the relationship.
Aggregation
Automobile
serial number
year
manufacturer
model
color
weight
drive
purchase
Engine
horsepower
volume
on
off
3,4,5
Wheel
diameter
number of bolts
*
Brakelight
on
off
2,4
Door
open
close
Battery
amps
volts
charge
discharge
Inheritance



Models "kind of" hierarchy
Powerful notation for sharing similarities among classes
while preserving their differences
UML Notation: An arrow with a triangle
Cell
BloodCell
Red
White
MuscleCell
Smooth
Striate
NerveCell
Cortical
Pyramidal
Aggregation vs Inheritance



Both associations describe trees (hierarchies)
 Aggregation tree describes “a-part-of
“relationships (also called and-relationship)
 Inheritance tree describes "kind-of"
relationships (also called or-relationship)
Aggregation relates instances (involves two or
more different objects)
Inheritance relates classes (a way to structure
the description of a single object)
Other Associations




Uses:
 An object uses another object : Player moves Token
Contains:
 Sometimes called “spatial aggregation”
 ... contains ...
 Example: an order contains items
Parent/child relationship:
 ... is father of ...
 ... is mother of ...
Seniority:
 ... is older than ...
 ... is more experienced than ...
Requirement Analysis


Challenging activity
Requires collaboration of people with different
backgrounds



User with application domain knowledge
Developer with implementation domain knowledge
Bridging the gap between user and developer:


Scenarios: Example of the use of the system in terms
of a series of interactions with between the user and
the system
Use cases: Abstraction that describes a class of
scenarios
System Model

Scenarios
- As-is scenarios, visionary scenarios

Use case model
- Actors and use cases

Object model
- Data dictionary
- Class diagrams (classes, associations, attributes
and behaviors)

Dynamic model
- State diagrams for classes with significant dynamic
behavior
- Sequence diagrams for collaborating objects
(protocol)
System Identification


Development of a system is not just done by
taking a snapshot of a scene (domain)
Definition of the system boundary



What is inside, what is outside?
How can we identify the purpose of a system?
Requirement Process:


Requirements Elicitation: Definition of the system in
terms understood by the customer (use cases)
Analysis: Technical specification of the system in terms
understood by the developer (sequence diagrams, class
diagrams)
Why different kinds of models?





Use case model (user oriented view of the domain)
Domain model (analysis model, analyst oriented view of
the domain)
Design model (view of software concepts in the domain)
Each type of model describes the same system but from a
different perspective and at a different level of abstraction.
They provide different kinds of information (e.g. dynamic,
static view of the system, or functionality oriented vs.
solution oriented)
Types of Requirements



Functional requirements: Describe the interactions
between the system and its environment independent from
implementation

The system must record sales.
Nonfunctional requirements: User visible aspects of
the system not directly related to functional behavior.
 The response time must be less than 5 second
 The display should be readable from 1 meter.
Constraints (“Pseudo requirements”): Imposed by the
client or the environment in which the system will operate
 The implementation language must be JAVA.
Nonfunctional Requirements







Usability
Reliability
Performance
Supportability
Implementation
Interface
Operations
Nonfunctional Requirements
Usability: User interface and human factors






What type of user will be using the system?
Will more than one type of user be using the system?
What sort of training will be required for each type of
user?
Is it particularly important that the system be easy to
learn?
Is it particularly important that users be protected
from making errors?
What sort of input/output devices for the human
interface are available, and what are their
characteristics?
Nonfunctional Requirements
Usability : Documentation


What kind of documentation is required?
What audience is to be addressed by each
document?
Implemenation: Hardware considerations


What hardware is the proposed system to be used
on?
What are the characteristics of the target
hardware, including memory size and auxiliary
storage space?
Nonfunctional Requirements

Performance characteristics



Are there any speed, throughput, or response time
constraints on the system?
Are there size or capacity constraints on the data
to be processed by the system?
Reliability: Error handling and extreme
conditions


How should the system respond to input errors?
How should the system respond to extreme
conditions?
Nonfunctional Requirements

Interface




Is input coming from systems outside the
proposed system?
Is output going to systems outside the proposed
system?
Are there restrictions on the format or medium
that must be used for input or output?
Supportability : System Modifications

What parts of the system are likely candidates for
later modification?
Nonfunctional Requirements

Reliability : Quality issues
What are the requirements for reliability?
 Must the system trap faults?
 Is there a maximum acceptable time for
restarting the system after a failure?
 What is the acceptable system downtime per
24-hour period?
 Is it important that the system be portable
(able to move to different hardware or
operating system environments)?
 What sorts of modifications are expected?

Nonfunctional Requirements

Physical Environment



Where will the target equipment operate?
Will the target equipment be in one or
several locations?
Will the environmental conditions in any
way be out of the ordinary (for example,
unusual temperatures, vibrations, magnetic
fields, ...)?
Nonfunctional Requirements

Reliability : Security Issues



Must access to any data or the system itself be
controlled?
Is physical security an issue?
Operation : Resources and Management Issues




How often will the system be backed up?
Who will be responsible for the back up?
Who is responsible for system installation?
Who will be responsible for system maintenance?
Pseudo Requirements

Pseudo requirement:


Any client restriction on the solution domain
Examples:






The target platform must be a SUN/SPARC
The implementation language must be JAVA
The documentation standard X must be used
A data-glove must be used
ActiveX must be used
The system must interface to a barcode reader
Prioritizing requirements



High priority (“Core requirements”)
 Must be addressed during analysis, design, and
implementation.
 A high-priority feature must be demonstrated successfully
during client acceptance.
Medium priority (“Optional requirements”)
 Must be addressed during analysis and design.
 Usually implemented and demonstrated in the second
iteration of the system development.
Low priority (“Fancy requirements”)
 Must be addressed during analysis (“very visionary
scenarios”).
 Illustrates how the system is going to be used in the
future if not yet available technology enablers are
Requirements Validation

Requirements validation criteria:



Correctness:
 The requirements represent the client’s view.
Completeness:
 All possible scenarios through the system are
described, including exceptional behavior by
the user or the system
Consistency:
 There are functional or nonfunctional
requirements that contradict each other
Requirements Validation


Clarity:
 There are no ambiguities in the
requirements.
Realism:


Requirements can be implemented and delivered
Traceability:

Each system function can be traced to a
corresponding set of functional requirements