1. Computing and SE II Chapter 5: Requirements Analysis
Er-Yu Ding
Software Institute, NJU

2. Main Contents Models of Requirement Analysis
Structural Analysis: Entity-Relationship Diagram
Structural Analysis: Data Flow Diagram
Structural Analysis: State Transition Diagram
Object-Oriented Analysis: Use Case Diagram
Object-Oriented Analysis: Class Diagram
Object-Oriented Analysis: Behavioral Diagram
Object-Oriented Analysis: CRC Card
Writing the Software Specification

3. 1. Models of Requirement Analysis ——Requirements analysis
Outcome of Analysis
现实世界
计算世界
用户模型
分析模型
计算模型
Analysis

4. 1. Models of Requirement Analysis —— The Analysis Model
The analysis model consists of a wide variety of diagrammatic forms used to bridge an important gap.
System
Description
Design
Model
Analysis
System information
System function
System behaviors
Purpose:
Describe what the customer wants built
Establish the foundation for the software design
Provide a set of validation requirements

5. 1. Models of Requirement Analysis —— Model
What is a model?
a model is a simplification of reality
Why do we model?
we build models so that we can better understand the system we are developing
we build models of complex systems because we cannot comprehend such a system in its entirety
four aims to achieve
help us to visualize a system
permit us to specify the structure/behavior of a system
give us a template that guides us in constructing systems
document the decisions we have made

6. 1. Models of Requirement Analysis —— Software Model
A model is an abstract representation of a system that enables us to answer questions about the system.
When we represent it with real world language, it’s user model
When we represent it with computing world language, it’s design model
When we represent it with codes, it’s program model
When we represent it with a neutral, formal language, it’s analysis model …

7. 1. Models of Requirement Analysis —— How to represent software model?
Describes necessary and complete knowledge
Stakeholders can get what they want
Decision makers
Users ,clients…
Developers
Analyst
Designer
Programmer
Integrator
Developers can develop software according to software model
Data, behavior, business rules…

9. 1. Models of Requirement Analysis —— Model and View
Model, views, viewpoints, and stakeholders
A model is a simplification of reality, created in order to better understand the system being created; a semantically closed abstraction of a system
A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or viewpoints relative to, a system
A content type is an kind of information needed for software development

10. 1. Models of Requirement Analysis —— Viewpoints, perspectives and views
Viewpoint is defined as a standing position used by an individual when examining a universe of discourse (Stakeholders Roles)
A perspective is defined as a set of facts observed and modelled according to a particular aspect of reality (Certain type content observed from some viewpoint)
A view is defined as an integration of related perspectives, usually using two kinds of methods
According to viewpoint (all perspectives observed by some stakeholders role on different content types)
According to content type (all perspectives observed by different stakeholders on some content types)

11. 1. Models of Requirement Analysis —— Describing Perspectives
A perspective language is used to represent the observed information of the perspectives
Text, Diagram (semi-formal language), Formal Language…
The language defines the set of units and their associations that can be used to describe perspectives
Languages N:M perspectives
There is no semi-formal or formal language can describe all kinds of perspectives

12. 1. Models of Requirement Analysis —— Common Perspectives Languages
UML
Object diagram
Classification model
Behavioral diagram
OCL
Use case diagram
Entity-Relationship Diagram
Composition( semantic data) model
Process Model (DFD)
Data processing model
State Machine Model
Stimulus/response model
Fact Model
Entity-event model
Object Role Model
Organization model
Petri Nets ……

13. 1. Models of Requirement Analysis —— Analysis Model – Structural
Data dictionary
ERD
DFD
STD
Control Specification (CSPEC)
Data Object
description
Process
specification
(PSPEC)
Data
Behavior
Function

14. 1. Models of Requirement Analysis —— OO Analysis Model - UML
Object
State-chart diagram
Interaction diagram
Class diagram
Object diagram
Use case diagram
Activity diagram
Data
Behavior
Function

15. 2. Structural Analysis: Entity-Relationship Diagram ——Data Modeling
Examines data objects independently of processing
Focuses attention on the data domain
Creates a model at the customer’s level of abstraction
Indicates how data objects relate to one another
Automobile
Person
Make
Model
Body type
Price
Color
Birthday
Height
Weight
Expertise

16. 2. Structural Analysis: Entity-Relationship Diagram —— What is a Data Object?
—something that is described by 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 without
access to instances of the object
each is described by attributes that are
themselves data items

17. 2. Structural Analysis: Entity-Relationship Diagram —— Typical Objects
external entities (printer, user, sensor)
things
(e.g, reports, displays, signals)
occurrences or events (e.g., interrupt, alarm)
roles
(e.g., manager, engineer, salesperson)
organizational units
(e.g., division, team)
places
(e.g., manufacturing floor)
structures (e.g., employee record)
Automobile
Person

18. 2. Structural Analysis: Entity-Relationship Diagram —— Data Objects and Attributes
A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object
Automobile
Person
Make
Model
Body type
Price
Color
Birthday
Height
Weight
Expertise

19. 2. Structural Analysis: Entity-Relationship Diagram ——Relationship
Connectedness
A fact that must be remembered by the system and cannot or is not computed or derived
Several instance of a relationship can exist
Entity can be related in many ways
own

20. 2. Structural Analysis: Entity-Relationship Diagram ——Cardinality and Multiplicity
own
Automobile
Person
Make
Model
Body type
Price
Color
Birthday
Height
Weight
Expertise

21. 2. Structural Analysis: Entity-Relationship Diagram —— ERD Notation
One common form:
(0, m)
object
relationship
object 1 2
(1, 1)
attribute
Another common form:
object
relationship
object 1 2
(0, m)
(1, 1)
attribute

22. 2. Structural Analysis: Entity-Relationship Diagram —— 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)
selected
from
work
tasks
(1,w)
consists of
(1,w)
(1,i)
materials
lists

23. 2. Structural Analysis: Entity-Relationship Diagram —— Building an ERD
Level 1—model all data objects (entities) and their “connections” to one another
Level 2—model all entities and relationships
Level 3—model all entities, relationships, and the attributes that provide further depth

24. 2. Structural Analysis: Entity-Relationship Diagram ——ERD- Let’s try it

25. 3. Structural Analysis: Data Flow Diagram ——Flow Oriented Model
Represents how data objects are transformed at they move through the system
A data flow diagram (DFD) is the diagrammatic form that is used
Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the system that is unique—it should be used to supplement other analysis model elements

26. 3. Structural Analysis: Data Flow Diagram —— The Flow Model
Every computer-based system is an
information transform ....
computer
based
system
input
output

27. 3. Structural Analysis: Data Flow Diagram —— Flow Modeling Notation
external entity
process
data flow
data store

28. 3. Structural Analysis: Data Flow Diagram —— 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

29. 3. Structural Analysis: Data Flow Diagram —— 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

30. 3. Structural Analysis: Data Flow Diagram —— Data Flow
Data flows through a system, beginning
as input and be transformed into output.
base
compute
triangle
area
area
height

31. 3. Structural Analysis: Data Flow Diagram —— 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

32. 3. Structural Analysis: Data Flow Diagram —— Data Flow Diagramming
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

33. 3. Structural Analysis: Data Flow Diagram ——Level 0 (Context Diagram)
user
video
source
monitor
processing
request
NTSC
video signal
requested
video
signal
digital
video
processor

34. 3. Structural Analysis: Data Flow Diagram —— Constructing a DFD—I
review the descriptions and use a grammatical parse to determine “operations”
determine external entities (producers and consumers of data)
create a level 0 DFD

35. write a narrative describing the transform
3. Structural Analysis: Data Flow Diagram —— Constructing a DFD—Refine Process
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

36. 3. Structural Analysis: Data Flow Diagram —— Level 1b x P y
level 0 p1 p2 p3 p4 5 a b c d e f g
level 1

37. 3. Structural Analysis: Data Flow Diagram —— 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

38. 3. Structural Analysis: Data Flow Diagram —— Using PSPEC
Process Specification (PSPEC) can be used to specify the processing details implied by a process within a DFD
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts

39. 3. Structural Analysis: Data Flow Diagram —— Using PSPEC
Check &
convert
pressure
PSPEC
If absolute tank pressure > max pressure
then
set above pressure to “true”;
else
set above pressure to “false”;
begin conversion algorithm x-01a;
compute converted pressure;
end
end if

40. 3. Structural Analysis: Data Flow Diagram —— Mapping to design model
analysis model
Maps into
design model

41. 3. Structural Analysis: Data Flow Diagram —— DFD- Let’s try it
用DFD描述ATM机的功能

42. 4. Structural Analysis: State Transition Diagram ——Behavioral modeling
The behavioral model indicates how software will respond to external events or stimuli.
events
behavior
Outside
world
Application
How do I model the software's reaction to some
external event?

43. 4. Structural Analysis: State Transition Diagram —— Basic concept
a set of observable circum-stances that characterizes the behavior of a system at a given time
State transition:
the movement from one state to another
Event:
an occurrence that causes the system to exhibit some predictable form of behavior
Action:
process that occurs as a consequence of making a transition

44. 4. Structural Analysis: State Transition Diagram —— State 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

45. 4. Structural Analysis: State Transition Diagram ——Notation and Example
Event
button1&2Pressed
button1Pressed
button2Pressed
Increment
Minutes
Hours
Blink
Seconds
Stop
Blinking
Initial state
Transition
button1&2Pressed
Final state

46. 4. Structural Analysis: State Transition Diagram —— State Diagram - Lets Try It!
North
You are designing a traffic light system for this intersection.
Draw a state diagram showing the different states and how they transition.
West
East
South

47. 5. Object-Oriented Analysis: Use Case Diagram —— Use-Cases
“[Use-cases] are simply an aid to defining what exists outside the system (actors) and what should be performed by the system (use-cases).”
–Ivar Jacobson
Key Points:
A scenario that describes a thread of usage for achieving a functional requirement
Actors represent roles people, devices, or external systems play
System internals are ignored
Example:
See Pressman Chapter 8, Section 8.5.1

48. Remember why we’re interested in use-cases!
5. Object-Oriented Analysis: Use Case Diagram —— The Key Elements of a Use-Case
A descriptive name for the scenario
e.g., “Customer Checkout”, “Browse Products”
The primary actor in the scenario
Who is interacting with the system?
The primary actor’s goal
What is the actor trying to accomplish?
Scenario pre-conditions
What assumptions are being made?
Scenario trigger
How was the scenario initiated?
The “sunny day” scenario
In the best case, how does the user interact with the system?
Exceptions
What might go wrong?
Remember why we’re interested in use-cases!

49. 5. Object-Oriented Analysis: Use Case Diagram —— Developing a Use-Case
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?
What are the main tasks or functions that 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?
Does the actor wish to be informed about unexpected changes? …

50. 5. Object-Oriented Analysis: Use Case Diagram ——Use Case Diagram - Let’s Try It
The Online Bookstore
The Online Bookstore System (OBS) will be a web-based application that allows customers to browse and purchase online product offerings. The application will support the notion of an online shopping cart, similar to other online retailers such as Amazon.com. The checkout features of the system will be integrated with our credit card transaction processor, as well as our internal billing system. The system will also provide an administrator-view that will allow authorized employees to view and administer products, customers, and orders.
Based on this description, what are the key use-cases?
Select one key use-case, describes it.

51. 5. Object-Oriented Analysis: Use Case Diagram —— Use-Case Diagrams
You’ll probably have a lot of use-cases!
Use case diagrams (UCD) provide a diagrammatic table of contents, and a high-level overview of the system.
Diagrams Show:
Actors
Use-cases
Relationships among them
Example UCD

52. 6. Object-Oriented Analysis: Class Diagram ——Object Models
Object models describe the system in terms of object classes
An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object
Key concepts:
Classes and objects
Attributes and operations
Encapsulation
Association and Link
Inheritance
Aggregation (Composition)
Polymorphism

53. 6. Object-Oriented Analysis: Class Diagram —— Objects
Natural ways of reflecting the real-world entities manipulated by the system
Object class identification is recognised as a difficult process requiring a deep understanding of the application domain
Object classes reflecting domain entities are reusable across systems

54. 6. Object-Oriented Analysis: Class Diagram ——Attributes and operations
Class name
attributes
operations

55. 6. Object-Oriented Analysis: Class Diagram —— Encapsulation/Hiding
The object encapsulates
both data and the logical
procedures required to
manipulate the data
method
# 1
method
# 2
data
method
# 3
method
# 6
method
# 5
method
# 4
Achieves “information hiding”

56. 6. Object-Oriented Analysis: Class Diagram —— Associations and Dependencies
Two analysis classes are often related to one another in some fashion
In UML these relationships are called associations
Associations can be refined by indicating multiplicity (the term cardinality is used in data modeling
If there are associations between classes, then there are links between instances of the classes

57. 6. Object-Oriented Analysis: Class Diagram —— Association

58. 6. Object-Oriented Analysis: Class Diagram ——Inheritance
Organise the domain object classes into a hierarchy
Classes at the top of the hierarchy reflect the common features of all classes
Object classes inherit their attributes and services from one or more super-classes. these may then be specialised as necessary

59. User class hierarchy

60. 6. Object-Oriented Analysis: Class Diagram —— Object Aggregation
Aggregation model shows how classes which are collections are composed of other classes
Similar to the part-of relationship in semantic data models

61. Object Aggregation

62. 6. Object-Oriented Analysis: Class Diagram —— Class-Based Modeling
Identify analysis classes by examining the problem statement
Use a “grammatical parse” to isolate potential classes
Identify the attributes of each class
Identify operations that manipulate the attributes

63. 6. Object-Oriented Analysis: Class Diagram —— Identifying Analysis Classes
occurrences
roles
things
organizational units
places
external entities
structures
class name
attributes:
operations:

64. 6. Object-Oriented Analysis: Class Diagram —— Class Selection Criteria
Retained information
Needed services
Multiple attributes
Common attributes
Common operations
Essential requirements

65. 6. Object-Oriented Analysis: Class Diagram ——Class Selection
The SafeHome security function 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 the Internet, a PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until a telephone connection is obtained.
The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form…

66. 6. Object-Oriented Analysis: Class Diagram —— Identifying Classes
Retained information
Needed services
Multiple attributes
Common attributes
Common operations
Essential requirements
Potential class
Classification
Accept / Reject
homeowner
role; external entity
reject: 1, 2 fail
sensor
external entity
accept
control panel
installation
occurrence
reject
(security) system
thing
number, type
not objects, attributes
reject: 3 fails
master password
telephone number
sensor event
audible alarm
accept: 1 fails
monitoring service
organizational unit; ee

67. 6. Object-Oriented Analysis: Class Diagram —— Let’s Try It
6. Object-Oriented Analysis: Class Diagram —— Let’s Try It. Class Diagram
University Bank will be opening in Oxford, Mississippi, in January, We plan to use a full service automated teller machine (ATM) system.The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system.Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction.In the future, we would also like to support routine operations such as a change of address or phone number using the ATM
Nouns are your classes
Verbs are your methods

68. 7. Object-Oriented Analysis: Behavioral Diagram ——Behavioral Diagram
State Chart
State Transition Diagram
Interaction Diagram
Sequence Diagram
Communication Diagram
Activity Diagram

69. 7. Object-Oriented Analysis: Behavioral Diagram ——System behaviour modelling with States Chart
The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps:
Evaluate all use-cases to fully understand the sequence of interaction within the system.
Identify events that drive the interaction sequence and understand how these events relate to specific objects.
Build a state diagram for the system.
Review the behavioral model to verify accuracy and consistency.

70. 7. Object-Oriented Analysis: Behavioral Diagram —— Identifying Events
A use-case is examined for points of information exchange.
The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password in incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.

71. 7. Object-Oriented Analysis: Behavioral Diagram —— State Diagram
State diagram for the ControlPanel class

72. 7. Object-Oriented Analysis: Behavioral Diagram —— System behaviour modelling with Sequence Diagram
A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case
Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects

73. 7. Object-Oriented Analysis: Behavioral Diagram —— Sequence Diagram

74. 7. Object-Oriented Analysis: Behavioral Diagram ——Let’s Try It!
Give a correct version for figure 8-21.

75. 7. Object-Oriented Analysis: Behavioral Diagram —— System behaviour modelling with Activity Diagram
Supplements the use-case by providing a diagrammatic representation of procedural flow
How might we make this better?

76. 7. Object-Oriented Analysis: Behavioral Diagram —— System behaviour modelling with Activity Diagram
Swimlane Diagrams
Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle

77. 8. Object-Oriented Analysis: CRC Card ——CRC Modeling
CRC : Class-Responsibility- Collaborator
Analysis classes have “responsibilities”
Responsibilities are the attributes and operations encapsulated by the class
Analysis classes collaborate with one another
Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility.
In general, a collaboration implies either a request for information or a request for some action.

78. 8. Object-Oriented Analysis: CRC Card ——CRC Card

79. 9. Writing the Software Specification
Everyone knew exactly what had to be done until someone wrote it down!

80. The End
Next Lecture
Software Design

81. Reviews
为选课系统建立ERD描述
用DFD描述ATM机的功能
用STD描述十字路口红绿灯

82. A First Level DFD System Customer clock Database Printer 1.0 3.0 4.0
ATM card no
System
clock
Customer
Requested
transaction
service
PIN
prompts
1.0
Verify
Customer ID
3.0
Process
Transaction
4.0
Perform
accounting
2.0
Initial
Transaction
Database
Lost-stolen_list
Printer

83. Back

84. State Diagrams (Traffic light example)
Start
Traffic Light
State
Red
Transition
Yellow timer expires
Yellow
Car trips sensor
Green timer expires
Green
Event

85. Back

86. Back