System Analysis

1
System Analysis
2
Outline

• Requirement Analysis
• Analysis Principles
• Specification
• Analysis Modeling
• Structured Analysis

3
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 will fill
  in the details as we go
• the customer keeps changing requirements
• the developer is confused by these changes,
  making errors in specifications and development

as so it goes
4
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

5
Software Requirements Analysis (cont.)
System Engineering
Software Requirement Analysis
Software Design
6
Software Requirements Analysis (cont.)

• Result in the specification of softwares
  operation characteristics (function, data, and
  behavior)
• Indicate softwares interface with other system
  elements establish constraints that software must
  meet
• Provide software designer with a representation
  of information, function, and behavior that can
  be translated to data, architectural, interface,
  and component-level design
• provide the developer and the customer with the
  means to assess quality once software is built

7
Five Areas of Efforts in SRA

• Problem recognition
• Evaluation and synthesis
• Modeling
• Specification
• Review

8
Focus of Software Requirement Analysis

• What ?
• What data does the system produce and consume?
• What function must the system perform?
• What behaviors does the system exhibit?
• What interfaces are defined?
• What constraints apply?

9
Requirements Gathering
Facilitated Application Specification Techniques
Software
Customer
Engineering
Group
Group
10
FAST Guidelines

• Participants must attend entire meeting
• All participants are equal
• Preparation is as important as meeting
• All pre-meeting documents are to be viewed as
  proposed
• Off-site meeting location is preferred
• Set an agenda and maintain it
• Dont get mired in technical details

11
Requirement List before FAST meetings

• Preparation items of each FAST attendee
• A list of objects
• A list of services
• A list of constraints
• A list of performance criteria

12
Case Study SafeHome
Product description Our research indicates
that the market for home security systems is
growing at a rate of 40 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.
13
Case Study SafeHome (cont.)

• Objects
• Smoke detectors, window and door detectors, an
  alarm, an event, a control panel, a display,
  telephone numbers, a telephone call,
• Services
• Setting the alarm, monitoring the sensors,
  dialing the phone, programming the control panel,
  reading the display
• Constraints
• Manufactured cost of less than 80,
  user-friendly, interfacing with a standard phone
  line
• Performance criteria
• A sensor event recognized within one second

14
Case Study SafeHome (cont.)

• Example of small specifications
• mounted on wall
• size approximately 9 X 5 inches
• contains standard 12-key pad and special keys
• contains LCD display of the form shown in sketch
• 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

15
Quality Function Deployment (QFD)

• Maximizing customer satisfaction from software
  engineering process
• An understanding of what is valuable to the
  customer and then deploying these values
  throughout the engineering process
• With three types of requirements identified
• Normal requirements
• Expected requirements
• Exciting requirements

16
Quality Function Deployment (cont.)

• Function deployment determines the value (as
  perceived by the customer) of each function
  required of the system
• Information deployment identifies data objects
  and events
• Task deployment examines the behavior of the
  system
• Value analysis determines the relative priority
  of requirements

17
Use Cases

• A collection of scenarios that describe the
  thread of usage of a system
• Each scenario is described from the
  point-of-view of an actora person or device
  that interacts with the software in some way
• Each scenario answers the following questions
• What are the main tasks of functions performed by
  the actor?
• What system information will the actor acquire,
  produce or change?
• Will the actor inform the system about
  environmental changes?
• What information does the actor require of the
  system?
• Does the actor wish to be informed about
  unexpected changes

18
Case Study SafeHome (cont.)

• Actor homeOwner
• Possible ways that the homeowner interacts with
  the product
• 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

19
The Analysis Process
build a prototype
requirements elicitation
develop Specification
the problem
review
create analysis models
20
Analysis Principle I Model the Data Domain

• Define data objects
• Describe data attributes
• Establish data relationships

21
Analysis Principle II Model Function

• Identify functions that transform data objects
• Indicate how data flow through the system
• Represent producers and consumers of data

22
Analysis Principle III Model Behavior

• Indicate different states of the system
• Specify events that cause the system to change
  state

23
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

24
Analysis Principle V Essence

• Begin by focusing on the essence of the problem
  without regard to implementation details

25
Principles for Requirements Engineering

• 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
• Prioritize requirements
• Work to eliminate ambiguity

26
Data Model

• information content and relationships
• information flow
• information structure

27
Modeling

• Models should be capable of representing
• the information that software transforms
• the functions that enable the transformation to
  occur
• the behavior of the system as the transformation
  is taking place
• functional models
• behavior models

28
Importance of Modeling

• Help the analyst understand the information,
  function and behavior of a system
• Become the focal point for review and the key to
  a determination of completeness, consistency,
  and accuracy of the specifications
• Become the foundation of design

29
Partitioning

• Exposing increasing detail by moving vertical in
  the hierarchy
• Functionally decomposing the problem by moving
  horizontally in the hierarchy

30
Case Study Horizon Partitioning
SafeHome software
Configure system
Monitor sensors
Interact with user
Horizontal Partitioning
31
Case Study Vertical Partitioning
32
Essential and Implementation Views

• Also as logical and physical views
• Essential view presenting the functions to be
  accomplished and information to be processed w/o
  regard to implementation details
• Implementation view presenting the real world
  manifestation of processing functions and
  information structures

33
Software Prototyping

• Throwaway prototyping
• Evolutionary prototyping
• Prototyping candidacy depending on application
  area, application complexity, customer
  characteristics, project characteristics
• Candidate for prototyping
• creating dynamic visual displays
• interacting heavily with a user
• demanding algorithms or combinatorial processing
  that must be developed in an evolutionary fashion

34
Selection of Software Prototyping
35
Prerequisite of Success of Prototyping

• Customer resources be committed to the evaluation
  and refinement of the prototype
• The customer is capable of making requirements
  decisions in a timely fashion
• The project has a strong bearing on the efficacy
  of prototyping

36
Prototyping Methods and Tools

• fourth generation techniques
• reusable software components
• formal specification and prototyping environment

37
Specification Principles

• Separate functionality from implementation
• Develop a model of the desired behavior of a
  system
• Establish the context
• Define the environment
• Create a cognitive model rather than a design or
  implementation model
• Recognize that the specifications must be
  tolerant of incompleteness and augmentable
• Establish the content and structure enabling it
  to be amenable to change

38
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

39
Software Requirement Specification

• A complete information description
• A detailed functional description
• A representation of system behavior
• An indication of performance requirements and
  design constraints
• Appropriate validation criteria
• Other information pertinent to requirements

40
The Analysis Model
Data Model
Functional Model
Behavioral Model
41
Analysis ModelingWhere to Begin?

• A statement of scope can be acquired from
• The FAST working document
• A set of use-cases
• The statement of scope must be parsed to
  extract data, function and behavioral domain
  information

42
Statement of Scope

• A relatively brief description of the system to
  be built
• Indicates data that are input and output and
  basic functionality
• Indicates conditional processing (at a high
  level)
• Implies certain constraints and limitations

43
Identifying Objects and Operations

• Define objects by underlining all nouns in the
  written statement of scope
• Producers/consumers of data
• Places where data are stored
• Composite data items
• Define operations by italicizing all active
  verbs
• Processes relevant to the application
• Data transformations
• Consider other services that will be required
  by the objects

44
Case Study Identify Objects and Operations
SafeHome software enables the homeowner to
configure the security system when it is
installed, monitors all sensors connected to the
security system, and interacts with the homeowner
through a keypad and function keys connected in
the SafeHome control panel.
45
Why Data Modeling?

• Examines data objects independently of processing
• Focuses attention on the data domain
• Creates a model at the customers level of
  abstraction
• Indicates how data objects relate to one another

46
What is a Data Object?

• Object
• A set of attributes (data items)and that will be
  manipulated within the software (system)
• Each instance of an object (e.g., a book) can be
  identified uniquely (e.g., ISBN)
• Each plays a necessary role in the system, i.e.,
  the system could not function w/o access to
  instances of the object
• Each is described by attributes that are
  themselves data items

47
Typical Objects

• External entities (printer, user, sensor)
• Things (reports, displays, signals)
• Occurrences or events (interrupt, alarm)
• Roles (manager, engineer, salesperson)
• Organizational units (division, team)
• Places (manufacturing floor)
• Structures (employee record)

48
Data Objects and Attributes

• A data object contains a set of attributes that
  act as an aspect, quality, character-intrinsic,
  or descriptor of the object

object automobile attributes make model
body type price options code
49
What is a Relationship?

• Relationship
• Indicating connectedness
• A fact that must be remembered by the system
  and cannot or is not computed or derived
  mechanically
• Several instances of a relationship can exist
• Objects can be related in many different ways

50
ERD Notation
One common form
(0, m)
object
object
relationship
1
2
(1, 1)
attribute
Another common form
relationship
object
object
1
2
(1, 1)
(0, m)
51
Cardinality and Modality

• Cardinality
• The specification of the number of occurrences of
  one that can be related to the number of
  occurrences of another
• Define the maximum number of objects that can
  participate in a relationship
• Modality
• Binary notation of a relationship
• 0 there is no explicit need for the relationship
  or optional
• 1 an occurrence of the relationship is mandatory

52
Building an ERD

• Level 1model all data objects (entities) and
  their connections to one another
• Level 2model all entities and relationships
• Level 3model all entities, relationships, and
  the attributes that provide further depth

53
The ERD An Example
request for service
Customer
places
(1,1)
(1,m)
(1,1)
standard task table
(1,n)
work order
generates
(1,1)
(1,1)
(1,1)
(1,w)
work tasks
selected from
consists of
(1,w)
(1,i)
materials
lists
54
The Flow Model
Every computer-based system is an information
transform ....
computer based system
input
output
55
Flow Modeling Notation
external entity
process
data flow
data store
56
External Entity
A producer or consumer of data
Examples a person, a device, a sensor
Another example computer-based system
Data must always originate somewhere and must
always be sent to something
57
Process
A data transformer (changes input to output)
Examples compute taxes, determine area, format
report, display graph
Data must always be processed in some way to
achieve system function
58
Data Flow
Data flows through a system, beginning as input
and be transformed into output.
base
compute triangle area
area
height
59
Data Stores
Data is often stored for later use.
sensor
sensor , type, location, age
look-up sensor data
report required
type, location, age
sensor number
sensor data
60
Data Flow Diagramming Guidelines

• All icons must be labeled with meaningful names
• The DFD evolves through a number of levels of
  detail
• Always begin with a context level diagram (also
  called level 0)
• Always show external entities at level 0
• Always label data flow arrows
• Do not represent procedural logic

61
Constructing a DFDI

• Review ERD to isolate data objects and
  grammatical parse to determine operations
• Determine external entities (producers and
  consumers of data)
• Create a level 0 DFD

62
Level 0 DFD Example
63
Constructing a DFDII

• Write a narrative describing the transform
• Parse to determine next level transforms
• Balance the flow to maintain data flow
  continuity
• Develop a level 1 DFD
• Use a 15 (approx.) expansion ratio

Magic number 7 /- 2
64
The Data Flow Hierarchy
a
b
P
x
y
level 0
c
p2
a
f
p1
b
p4
d
5
g
p3
e
level 1
65
Flow Modeling Notes

• Each bubble is refined until it does just one
  thing
• The expansion ratio decreases as the number of
  levels increase
• Most systems require between 3 and 7 levels for
  an adequate flow model
• A single data flow item (arrow) may be expanded
  as levels increase (data dictionary provides
  information)

66
DFDs A Look Ahead
analysis model
Maps into
design model
67
Behavioral Modeling
events
behavior
Outside world
Application
68
The States of a System

• Statea set of observable circum-stances that
  characterizes the behavior of a system at a given
  time
• State transitionthe movement from one state to
  another
• Eventan occurrence that causes the system to
  exhibit some predictable form of behavior
• Actionprocess that occurs as a consequence of
  making a transition

69
Behavioral Modeling

• Make a list of the different states of a system
  (How does the system behave?)
• Indicate how the system makes a transition from
  one state to another (How does the system change
  state?)
• Indicate event
• Indicate action
• Draw a state transition diagram

70
State Transition Diagram Notation
state
event causing transition
action that occurs
new state
71
State Transition Diagram
full and start
reading
invoke manage-copying
operator
commands
full
invoke read-op-input
copies done
invoke read-op-input
making copies
reloading paper
empty
invoke reload paper
jammed
invoke problem-diagnosis
not jammed
invoke read-op-input
problem state
72
The Control Model

• The control flow diagram is superimposed on the
  DFD and shows events that control the processes
  noted in the DFD
• Control flows events and control items are
  noted by dashed arrows
• A vertical bar implies an input to our output
  from a control spec (CSPEC) a separate
  specification that describes how control is
  handled
• A dashed arrow entering a vertical bar is an
  input to the CSPEC
• A dashed arrow leaving a process implies a data
  condition
• A dashed arrow entering a process implies a
  control input read directly by the process
• Control flows do no physically activate/deactivate
  the process this is done via the CSPEC

73
(No Transcript)
74
Control Specification (CSPEC)

• The CSPEC can be
• State transition diagram (sequential spec)
• State transition table
• Decision tables
• Activation tables

75
(No Transcript)
76
Guidelines for Building a CSPEC

• List all sensors that are read by the software
• List all interrupt conditions
• List all switches that are actuated by the
  operator
• List all data conditions
• Recalling the noun-verb parse that was applied to
  the software statement of scope, review all
  control items as possible CSPEC inputs/outputs
• Describe the behavior of a system by identifying
  its states identify how each state is reached
  and defines the transitions b/w states
• Focus on possible omissions a very common error
  in specifying control, e.g., ask Is there
  any other way I can get to this state or exit
  from it?

77
Process Specification (PSPEC)
bubble
PSPEC
narrative

Pseudo code (PDL)
equations

tables
diagrams and/or charts


78
A Design Note
PSPEC
one or more components"
in the software design
79
Creating Mini-Specs
Software
Specification
80
The Data Dictionary

• A quasi-formal grammar for describing the content
  of data that the software will process and create
• A notation for describing control data and the
  values that control data can take, e.g., on or
  off
• A repository that also contains where-used /
  how used information
• A notation that can be represented manually, but
  is best developed using CASE tools

81
Building a Data Dictionary
82
Data Dictionary Notation
83
Data Dictionary Example
84
Writing the Software Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!
85
Specification Guidelines
86
Specification Guidelines (Cont.)
87
Specification Guidelines