CSC%20205:%20Software%20Engineering%20I

1
CSC 205 Software Engineering I

• Dr. Franz J. Kurfess
• Computer Science Department
• Cal Poly

2
Course Overview

• Introduction
• Requirements Engineering
• Requirements Elicitation
• Requirements Management
• Project Management
• System Design Methods and Notations

• Design Models and Object-Oriented Design
• Design Analysis and Formal Specification
• Design Analysis and Verification
• Conclusions

3
Chapter OverviewRequirements Management

• Motivation
• Objectives
• Evaluation Criteria
• Information Flow Models
• Data Dictionary

• Data Flow Diagrams
• Important Concepts and Terms
• Chapter Summary

4
Logistics

• Introductions
• Course Materials
• textbook
• handouts
• Web page
• CourseInfo/Blackboard System
• Term Project
• Lab and Homework Assignments
• Exams
• Grading

5
Bridge-In
6
Pre-Test
7
Motivation

• after requirements are elicited, it is important
  to document them carefully
• natural language is usually not sufficient for a
  good documentation and organization of
  requirements
• graphical notations and other more formal methods
  are frequently very helpful for the organization
  of requirements in a systematic manner

8
Objectives

• understand the importance of documenting
  requirements
• become familiar with methods and tools for the
  documentation and management of requirements
• consider external factors that may influence the
  management of requirements

9
Evaluation Criteria
10
Documenting Requirements

• on some projects minimal specifications may be
  appropriate
• for our CSC 205 project a thorough specification
  is required
• detailed specifications provide a thorough basis
  for planning and tracking a project
• they provide developers with a secure foundation
  for their design and code
• for more fluid projects they have disadvantages

Kearns 00
11
Minimal Specification

• contains the minimal amount to specify a product
• pros
• developers gain control and ownership
• shorter requirements phase
• opportunistic specification - fewer constraints
• cons
• omission of key requirements
• unclear goals
• gold plating
• lack of support for parallel activities

Kearns 00
12
Requirements Analysis

Kearns 00
13
Concise Understandable

• summarize
• use standard, structured templates
• use a uniform voice (active)
• use a uniform vocabulary
• use information-structuring mechanisms
• figures, diagrams, tables, math,
• use references
• never, ever deliver incorectly spelt or text with
  improperly grammar

Kearns 00
14
Unambiguous

• quantify requirements whenever possible
• supplement natural language with formal
  specifications
• mathematics or other formalisms with a
  well-defined semantics, as appropriate
• be redundant
• to avoid misunderstandings
• redundant ? repetitive

Kearns 00
15
Analyze

• classify requirements
• identify system boundaries
• use checklists
• identify interactions
• assess risks
• prioritize

Kearns 00
16
The Elements of the Analysis Model

• core data dictionary
• data object description
• entity relationship diagram
• process specification
• data flow diagram
• control specification
• state transition diagram

Kearns 00
17
Data Dictionary

• an organized approach for representing the
  characteristics of each data object and control
  item
• data dictionary definition (Yourdan)
• an organized listing of of all data elements that
  are pertinent to the system, with precise,
  rigorous definitions so that both user and system
  analyst will have a common understanding of
  inputs, outputs, components of stores and (even)
  intermediate calculations

Kearns 00
18
Data Dictionary Contents

• name
• alias
• what other names are used to refer to this
  element
• where-used/how-used
• what external agents, processes use this data
• format and content description
• what are the syntax and semantics of this element
• supplementary information
• what else is relevant for the correct use and
  storage of this data element

Kearns 00
19
Content Description

• similar to BNF notation

Data Construct Notation Meaning descriptio
n is composed of sequence
and selection either-or repetition
n n repetitions of optional (
) optional data comments comment
delimiters
Kearns 00
20
Functional Modeling

• represent system as an information transforming
  system
• concerned with modeling an information system in
  terms of processes (activities) and information
  flow among them
• Data Flow Diagram (DFD), data flow graph, or
  bubble chart
• external entity
• process
• data objects
• data store (Data Dictionary)

Kearns 00
21
Information Flow

• processing specification
• specifies the processing details implied by a
  bubble in the data flow diagram
• includes any restrictions, performance, design
  constraints that affect how the process will be
  implemented
• refinement into a hierarchical sequence of
  diagrams
• depicts more detail
• information flow continuity or balancing

Kearns 00
22
Data Flow Diagrams

• made popular by DeMarco (1978), Gane and Sarson
  (1979)
• used in Object-Modeling Technology (OMT)
• Rumbaugh et. al., 1991
• intended as tool for functional analysis
• used in database design
• generating data requirements
• verifying database design
• complement to ER diagrams by adding dynamic
  content

Kearns 00
23
Process Modeling

• SW engineering view
• technique for organizing and documenting a
  systems processes, inputs, outputs, and data
  stores
• software engineering technique
• but the usefulness of process models extends far
  beyond describing software processes
• note
• SW engineering emphasis
• input-process-output model
• documentation focus
• e.g., justify our system...

Kearns 00
24
Why Were DFDs Developed?

• controlling complexity
• isolate flows and processing
• uncover structure of information flow
• communication/summarization tool
• not tied to existing process
• organizational separation of skills

Kearns 00
25
DFD Elements
A

r
e
p
o
s
i
t
o
r
y

o
f

i
n
f
o
r
m
a
t
i
o
n
.

I
t

c
a
n

b
e

a
n
y

t
y
p
e

o
f
D
a
t
a

S
t
o
r
e
p
e
r
m
a
n
e
n
t

s
t
o
r
a
g
e


f
i
l
e
s
,

d
a
t
a
b
a
s
e
s
,

p
a
p
e
r
/
e
l
e
c
t
r
o
n
i
c

f
o
r
m
s
,

e
t
c
.
I
n

d
a
t
a
b
a
s
e

d
e
s
i
g
n
,

t
h
e

d
a
t
a

s
t
o
r
e

i
s

a

c
o
l
l
e
c
t
i
o
n

o
f
d
a
t
a

i
t
e
m
s

(
p
o
s
s
i
b
l
y

o
r
g
a
n
i
z
e
d

a
s

a
n

e
n
t
i
t
y

o
r

a
n

E
R
s
u
b
-
m
o
d
e
l
)
.
Kearns 00
26

L
o
g
i
c
a
l
C
a
r
r
i
e
s

w
i
t
h

i
t

a

s
e
t

o
f

d
a
t
a

i
t
e
m
s
.
D
a
t
a

F
l
o
w
S
i
g
n
i
f
i
e
s

a

t
r
a
n
s
f
e
r

o
f

i
n
f
o
r
m
a
t
i
o
n

b
e
t
w
e
e
n



-

a
n

a
g
e
n
t

a
n
d

a

p
r
o
c
e
s
s
,


-

a

p
r
o
c
e
s
s

a
n
d

a

d
a
t
a

s
t
o
r
e
,

a
n
d


-

b
e
t
w
e
e
n

p
r
o
c
e
s
s
e
s
.
D
a
t
a

f
l
o
w
s

d
o

n
o
y
s
i
c
a
l

i
t
e
m
s



(
e
.
g
,

m
a
t
e
r
i
a
l
s
,

p
a
r
t
s
,

e
t
c
.
)
Kearns 00
27
D
a
t
a

C
r
e
a
t
i
o
n
U
s
e
d

b
e
t
w
e
e
n

a

p
r
o
c
e
s
s

a
n
d

a

d
a
t
a

s
t
o
r
e
.
F
l
o
w
S
i
g
n
i
f
i
e
s

t
h
e

c
r
e
a
t
i
o
n

o
f

a

n
e
w

o
b
j
e
c
t

i
n

t
h
e
d
a
t
a

s
t
o
r
e

(
e
q
u
i
v
a
l
e
n
t

t
o

a

d
a
t
a
b
a
s
e

i
n
s
e
r
t
)
.
Kearns 00
28
DFD Analysis

• abstracting
• from the process to processing
• summarization
• one-stop picture of the process, overview
  details
• test for completeness
• know all the code youll need to write
• all the data is accounted for
• eyeball the picture for discrepancies
• data stores assist identifying entities and
  relationships

Kearns 00
29
DFDs Are Not Flowcharts

• DFD processes can operate in parallel
• but would not include conditional branching
• data flow, not looping or branching
• no explicit decision-making
• timing factors
• looking for flows not time scale

Kearns 00
30
Data Flow Details

• only essential processing
• processing that changes data
• decoupling processing steps from each other
• controlling complexity
• processing steps are verb/object
• arrow names are nouns noun phrases
• composite vs. primitive flows

Kearns 00
31
Root or Context DFD

• shows the context of the system
• top level of DFD model
• consists of
• any number of agents
• only one process
• any number of data flows
• no data stores

Kearns 00
32
Sample DFD
Gray Hole
Black Hole
Miracle
Kearns 00
33
A Sample DFD...not finished

• black hole data disappear
• miracle data appear out of nowhere
• gray hole unclear what happens to data

Kearns 00
34
DFDs in Practice

• In practice
• manage the detail(s)
• input, output, module code
• generalizing from examples
• sign off on this now...
• do it better?
• fits functional hierarchy

• In theory
• controlling complexity
• isolate flows and processing
• uncover structure of information flow
• communication/summarization tool
• not tied to existing process
• organizational separation of skills

Kearns 00
35
An Order Processing System Context DFD
Kearns 00
36
Data Items for Data Flows 1
Kearns 00
37
Data Items for Data Flows 2
- Repeating Group
Kearns 00
38
Root Process Decomposition
Kearns 00
39
Add Data Stores
Kearns 00
40
Decompose Process Order
Kearns 00
41
Process Order Refinement

• Take order, Verify order, Make shipment
• New flows Order to be Verified (Order No) Order
  to be Shipped (Order No)

Kearns 00
42
Add Synonyms for Readability
Kearns 00
43
Verify order, Make shipment

• Verify Order
• validates the order
• approves or rejects it based on customer credit
  rating and order amount
• checks and updates the inventory
• sends the order confirmation to customer
• including an estimated ship date
• Make Shipment
• prepares the invoice
• computes shipping charges
• updates the order total and the customer balance
• ships the merchandise

Kearns 00
44
Kearns 00
45
Another Example Loan Application
Kearns 00
46
Decomposition
Kearns 00
47
Exercise

• Model two additional systems and integrate them
  with the above example.
• Make Loan
• After a loan is approved, the lender must
  actually make the loan. This includes, drafting
  the loan documents, signing them and opening the
  loan account.
• Process Loan Payments
• This system receives and processes loan payments
  from the borrower. It must properly credit
  principal, and interest, to the loan account.
  Must process late payments, "short payments"
  (payment amounts that are less than the amount
  due)

Kearns 00
48
Decomposition

• numbering of processes
• process tree
• data flow balancing
• data flows entering or exiting a process must be
  the same as those entering or leaving the
  decomposed DFD (migration of data flow)
• data stores locality
• external agents
• you should not introduce new agents in process
  decomposition (but see example above)
• number of levels
• seven plus or minus two

Kearns 00
49
Social and Organisational Factors

• software systems are used in a social and
  organisational context
• this can influence or even dominate the system
  requirements
• social and organisational factors are not a
  single viewpoint
• have influences on all viewpoints
• good analysts must be sensitive to these factors
• currently no systematic way to tackle their
  analysis

Sommerville 01
50
Example

• consider a system which allows senior management
  to access information without going through
  middle managers
• managerial status
• senior managers may feel too important to use a
  keyboard
• this may limit the type of system interface used
• managerial responsibilities
• managers may have no uninterrupted time to learn
  the system
• organisational resistance
• middle managers who will be made redundant may
  deliberately provide misleading or incomplete
  information so that the system will fail

Sommerville 01
51
Ethnography

• a social scientists spends a considerable time
  observing and analysing how people actually work
• people do not have to explain or articulate their
  work
• social and organisational factors of importance
  may be observed
• ethnographic studies have shown that work is
  usually richer and more complex than suggested by
  simple system models

Sommerville 01
52
Focused Ethnography

• developed in a project studying the air traffic
  control process
• combines ethnography with prototyping
• prototype development results in unanswered
  questions which focus the ethnographic analysis
• a problem with ethnography is that it studies
  existing practices
• may have some historical basis which is no longer
  relevant

Sommerville 01
53
Ethnography and Prototyping
Sommerville 01
54
Scope of Ethnography

• requirements that are derived from the way that
  people actually work rather than the way i which
  process definitions suggest that they ought to
  work
• requirements that are derived from cooperation
  and awareness of other peoples activities

Sommerville 01
55
Definitions and Specifications
Kearns 00
56
Requirements Readers
Kearns 00
57
Requirements Engineering Process
Kearns 00
58
Requirements Document

• the requirements document is the official
  statement of what is required of the system
  developers
• should include both a definition and a
  specification of requirements
• it is not a design document
• as far as possible, it should set of what the
  system should do rather than how it should do it

Kearns 00
59
Requirements Document Requirements

• specify external system behavior
• specify implementation constraints
• easy to change
• serve as reference tool for maintenance
• record forethought about the life cycle of the
  system
• i.e. predict changes
• characterize responses to unexpected events

Kearns 00
60
Requirements Document Structure

• typical structure
• may vary for different purposes or organizations

Introduction describe need for the system and how
it fits with business objectives Glossary define
technical terms used System Models define models
showing system components and relationships Functi
on-oriented Requirements Definition describe the
services to be provided
Non-function-oriented Requirements
Definition Define constraints on the system and
the development process System Evolution Define
fundamental assumptions on which the system is
based and anticipated changes Requirements
Specification Detailed specification of
functional requirements Appendices Index
Kearns 00
61
Requirements Validation

• Concerned with demonstrating that the
  requirements define the system that the customer
  really wants
• Requirements error costs are high so validation
  is very important
• Fixing a requirements error after delivery may
  cost up to 100 times the cost of fixing an
  implementation error

Sommerville 01
62
Requirements Checking

• validity
• does the system provide the functions which best
  support the customers needs?
• consistency
• are there any requirements conflicts?
• completeness
• are all functions required by the customer
  included?
• realism
• can the requirements be implemented given
  available budget and technology
• verifiability
• can the requirements be checked?

Sommerville 01
63
Requirements Validation Techniques

• requirements reviews
• systematic manual analysis of the requirements
• prototyping
• using an executable model of the system to check
  requirements
• test-case generation
• developing tests for requirements to check
  testability
• automated consistency analysis
• checking the consistency of a structured
  requirements description

Sommerville 01
64
Requirements Reviews

• regular reviews should be held while the
  requirements definition is being formulated
• both client and contractor staff should be
  involved in reviews
• reviews may be formal (with completed documents)
  or informal
• good communications between developers, customers
  and users can resolve problems at an early stage

Sommerville 01
65
Review Checks

• verifiability
• is the requirement realistically testable?
• comprehensibility
• is the requirement properly understood?
• traceability
• is the origin of the requirement clearly stated?
• adaptability
• can the requirement be changed without a large
  impact on other requirements?

Sommerville 01
66
Automated Consistency Checking
Sommerville 01
67
Requirements Management

• process of managing changing requirements during
  the requirements engineering process and system
  development
• requirements are inevitably incomplete and
  inconsistent
• new requirements emerge during the process
• business needs change
• a better understanding of the system is developed
• different viewpoints have different requirements
• these are often contradictory

Sommerville 01
68
Requirements Change

• the priority of requirements from different
  viewpoints changes during the development process
• system customers may specify requirements from a
  business perspective that conflict with end-user
  requirements
• the business and technical environment of the
  system changes during its development

Sommerville 01
69
Requirements Evolution
Sommerville 01
70
Enduring and Volatile Requirements

• enduring requirements
• stable requirements derived from the core
  activity of the customer organisation
• e.g. a hospital will always have doctors, nurses,
  etc.
• may be derived from domain models
• volatile requirements
• requirements which change during development or
  when the system is in use
• in a hospital, requirements derived from
  health-care policy

Sommerville 01
71
Classification of Requirements

• mutable requirements
• requirements that change due to the systems
  environment
• emergent requirements
• requirements that emerge as understanding of the
  system develops
• consequential requirements
• requirements that result from the introduction of
  the computer system
• compatibility requirements
• requirements that depend on other systems or
  organisational processes

Sommerville 01
72
Requirements Management Planning

• during the requirements engineering process, you
  have to plan
• requirements identification
• how requirements are individually identified
• a change management process
• the process followed when analysing a
  requirements change
• traceability policies
• the amount of information about requirements
  relationships that is maintained
• CASE tool support
• the tool support required to help manage
  requirements change

Sommerville 01
73
Traceability

• relationships between requirements, their sources
  and the system design
• source traceability
• links from requirements to stakeholders who
  proposed these requirements
• requirements traceability
• links between dependent requirements
• design traceability
• links from the requirements to the design

Sommerville 01
74
A Traceability Matrix
U row utilizes column requirement R other
relationship
Sommerville 01
75
CASE Tool Support

• requirements storage
• requirements should be managed in a secure,
  managed data store
• change management
• the process of change management is a workflow
  process whose stages can be defined and
  information flow between these stages partially
  automated
• traceability management
• automated retrieval of the links between
  requirements

Sommerville 01
76
Requirements Change Management

• should apply to all proposed changes to the
  requirements
• principal stages
• problem analysis
• discuss requirements problem and propose change
• change analysis and costing
• assess effects of change on other requirements
• change implementation
• modify requirements document and other documents
  to reflect change

Sommerville 01
77
Requirements Change Management
Sommerville 01
78
Post-Test
79
Evaluation

• Criteria

80
Important Concepts and Terms

• natural language
• product
• process
• process modeling
• project
• refinement
• requirements checking
• requirements documentation
• requirements management
• requirements reviews
• requirements validation
• specification
• system model
• traceability

• change management
• consistency checking
• control flow
• data creation flow
• data dictionary
• data flow diagram (DFD)
• data store
• decomposition
• ethnography
• external agent
• formal specification
• functional modeling
• glossary
• graphical notations
• logical data flow

81
Chapter Summary

• the documentation of requirements relies on
  natural language descriptions and on more formal
  methods
• social and organisation factors influence system
  requirements
• requirements validation is concerned with checks
  for validity, consistency, completeness, realism
  and verifiability
• business changes inevitably lead to changing
  requirements
• requirements management includes planning and
  change management

Sommerville 01
82
(No Transcript)