Object-Oriented
Analysis and Design
Lecture 2
Requirements and
Specification
Last Time



Functional vs. nonfunctional
requirements
Eliciting requirements
Examples
This Time





More detail on functional and
nonfunctional requirements
Some ideas on quality requirements
Comments on textual specifications
A little on IEEE 830
Use cases
Functional Requirements


“What the system is supposed to do, but
not how to do it.”
Basic problems:
How do we go about determining
requirements?
 How do we go about documenting
requirements?

Functional Requirements



We hope for a foolproof (?) way of specifying a
system.
Natural language may be too vague.
Over the years, we have seen various methods




data oriented
process oriented
behavior oriented
Formal techniques (Petri nets, Z)
Structured Systems Analysis






Oriented toward automating existing
procedures.
Initiated when we discovered that ½ of all
business systems never completed, other ½
cost 3estimate.
Abstract a “logical system” from the current
physical system by removing implementation
details.
Look for inadequacies.
Find solutions to them.
Implement
Modeling the Current System





Look for “data flows” - information
coming in, leaving, or passed from one
worker to another.
Look for “processes” - places where data
are transformed.
Look for “data stores.”
Try to diagram all this.
Look for inconsistencies.
Abstracting a Logical Model

Ignore how things are done; eliminate







who performs what
the data medium
duplication of data
temporary data storage
technology dependencies
processes that could be changed without
affecting the overall outcome
Document
Identifying Deficiencies







Where are the bottlenecks in the current
system?
Where can inconsistencies occur?
Are there better processing schemes?
What new features?
Drop old features?
Document again.
Design new system.
Data Flow Diagrams
Process
Transforms
inputs to outputs
Data Store
Disk, tape,
voice mail...
Data Flow
Movement
of data
External
Entity
Person or organization
providing data
Sally’s Software Shop




(from Schach)
Sally buys software from vendors & sells
to the public.
Sally stocks popular software packages,
and special orders others.
Sally extends credit to businesses and
some individuals.
Sally has been doing well, but has been
advised to computerize.
An Initial DFD
package data
package details
Customer
order
process
orders
invoice
customer status
customer data
A Stepwise Refinement
Software
Suplier
package data
Customer
order
package
details
verify
order is
valid
details of
package to
be ordered
credit status
pending orders
customer data
invoice
assemble
orders
address
details of
package
on hand
place order
at software
supplier
Fragment of Next Refinement
Customer
package data
package details
details of package
verify
to be ordered
order
order is
valid
credit status
delivery note
invoice
payment
apply
payment to
invoice
payment details
customer data
address
details of package
on hand
assemble
orders
delivery details
create
invoice
invoice details
accounts rec’v
details of package
received from
software agency
More SSA Steps








(Gane & Sarsen)
Decide what sections to computerize
Determine the details of the data flows
Define the logic of the processes
Define the data stores
Define the physical resources (e.g., DBMS)
Determine the I/O spec (user interface)
Determine the sizing
Determine the hardware requirements
Comments



This is a tedious, time-consuming
process. Stepwise refinement helps.
Following it blindly (as many have done)
ignores many opportunities for
innovation.
For existing automated systems, it may
involve reverse engineering (ugh!).
Essential Systems Analysis


A reaction to shortcomings of earlier
methods.
A cleaner approach:
identify the system’s purpose in terms of
events and responses
 identify essential activities comprising the
responses
 identify data flows necessary for the
responses

Information Engineering





A greater focus on data structures.
E-R models and process models.
Diagrams, diagrams, diagrams!
A combination of top-down and bottomup.
CASE support exists.
Object-Oriented Analysis





Objects, messages, methods.
Data and process combined into objects.
Objects grouped into classes; classes
arranged hierarchically.
A fusion of earlier methods.
We’ll have lots more to say about this!
Petri Nets





(Schach, Guha et al.)
Invented in 1962 by Carl Petri
Used lots of places in computer science
Good for describing synchronization of
concurrent activities
First, a description, then
specify the elevator problem
A Simple Petri Net
Places P = {p1,…,p4}
Transitions T = {t1, t2}
Input functions
p2
p1
t1
I(t1) = {p2, p4}
I(t2) = {p2}
t2
p3
Output functions
p4
O(t1) = {p1}
O(t2) = {p3, p3}
Petri Net With Tokens
Marking: (1,2,0,1)
t1 and t2 can fire
p2
p1
t1
t2
p3
p4
If t1 fires, the
marking becomes
(2,1,0,0)
After Firing t1 and t2
p2
p1
t1
Marking: (2,0,2,0)
t2
p3
p4
Petri Net With Inhibitor
p2
p1
t1
p3
t1 can fire, since p2
is empty, and p3
has a token
The Elevator Problem


n elevators in a building with m floors
Each elevator has m buttons


Each floor (except 1st and mth) has 2 buttons
(up and down)


light on when pressed, light off when elevator gets
there
light on when pressed, light off when elevator gets
there, going in correct direction
If no requests, an elevator remains at the
current floor with doors closed
Elevator Problem w/ Petri Nets



Each floor represented by a place Ff,
1<f<m
An elevator is represented by a token
A token in Ff means that an elevator is
at floor f
First Constraint: Elevator
Buttons

We need more “places”:
EBf,e with 1  f  m, 1  e  n

To keep things simpler, just use
EBf with 1  f  m
EBf pressed
EBf
Elevator in action
Fg
Ff
Second Constraint: Floor
Buttons
FBUf pressed
FBUf
Elevator in action
Ff
Fg
FBDf pressed
FBDf
Ff
Elevator in action
Third Constraint

If no buttons are illuminated, no
transition can fire
Documenting Functional
Requirements


Prose, obviously, but this can be ambiguous.
Diagrams of every sort:






DFDs
E-R diagrams
Process diagrams
State diagrams
Context diagrams
Petri nets
Documenting Functional
Requirements (cont.)





CASE tools; often built around one
methodology.
Make drawing and storing diagrams easier.
Are they user-friendly, as well as analystfriendly?
Can they integrate various views (data,
process, behavior)?
Do they compile?
Quality Requirements

Defining quality:
Measured conformance with specs
 Quality as satisfied users




What does the user expect?
Expectations vs. specifications.
How can we measure quality in advance
of implementation?
Measured Conformance

The old days:
You made a gear
 Someone measured it
 Kept it, scrapped it, or reworked it



Then: notion of process defect
Later:
Feedback
 Quality circles

Conformance (cont.)


Continuous process improvement
requires statistical quality control: the
process is stable.
Manufacturing is different than IS:
Objective measures harder to come by
 How to tie dissatisfaction with the
development process?
 Quality improvement is not usually
institutionalized.

Meeting User Expectations

Expectations include
meeting contractual agreements
 meeting functional specs
 quantified and unquantified goals for
usability, reliability, availability,
performance, security, maintainability
 “no surprises”
 benefits justify cost

Quality Metrics & Assessment





Budget and schedule: easy
Performance (response times, hardware
resources, throughput): fairly easy to “design
in,” if realistic
Reliability (accurate & complete, available, bugfree, fast recovery): hard to measure at designtime
Usability (ease of learning, ease of use): relies
on an “architectural metaphor”; prototypes can
help
Flexibility: modern design ideas (O-O) help
Measurement of Quality



Quality requirements are either met or not met
(just like any other).
Metrics are necessary, otherwise the
requirement is academic.
Some metrics are easy to come by


“response time less than 2 seconds for 95% of
transactions”
Some aren’t so easy

4 hours training, then novice can do transaction X
in 30 seconds
Shrink-Wrapped Products






No client + no sponsor = no rules?
Developers need to think like upper
management: what’s the “Technology
Plan”?
Think in terms of multiple releases.
What is the competition doing?
McCarthy speaks of these features:
strategic, competitive, customer
satisfaction, investment, and paradigmatic.
Wouldn’t this attitude work everywhere?
Textual Specifications



The requirements document may be the
most important thing you write.
Define exactly what the software will do;
if it “shall” have some property, how will
you determine if it does?
There are many “standards” for SRS,
and your organization may have one of
its own.
Textual Specs (cont.)

Questions:
What is the function of the spec?
 What is the uncertainty in the project?
 What is the management view of the spec?
 Who are the readers?
 Are there local conventions?

IEEE 830




A standard devised by volunteers (good
ones!)
1983, but many revisions.
See http://standards.ieee.org for the
details
Basically, it looks like...
IEEE 830 (cont.)



Intro
General Description
Specific Requirements






Functional Requirements
External Interface Requirements
Performance Requirements
Design Constraints
Attributes
Other Requirements
A Requirements Template


A nice outline, provided by Philip
Johnson of U. Hawaii
Here is a little bit of it...
Use Cases



One way to describe a system is by defining its
intended uses.
A “use case” is a sequence of steps (a
scenario) for completing a required task.
A use case is initiated by an “actor”




Course enrollment: an actor might be a student
Nightly report: the actor is the system itself
Banking: an actor is an ATM
An actor is anything that needs to interact with
the system.
What Good Are Use Cases?





Validate requirements, make sure
nothing is missed
View system from an external viewpoint
Help identify system objects
Basis for test plan
Basis for user manual
How to Find Use Cases?

Any of the methods described previously






Interviews
JAD
System context model
Examining current systems & practice
Prototypes
A “user” may have many roles, i.e., be many
different actors. Identify roles and activities.
Example: American FactFinder
Use case name: Request tabulation
Actor: Web user
Description: Describes the process of
submitting a request, processing it, and
responding to the actor.
Normal course:




1.
This use case is initiated when the user clicks the
Request Tabulation button on our Web site.
Use Case (cont.)
2.
3.
4.
5.
6.
7.
The user selects the base table (census,
business, health, etc.), then selects attributes.
The user submits the request by clicking OK.
The query is checked by the pre-processing
filters.
The query is submitted to the database.
The result is checked by the post-processing
filters.
The result is returned to the user.
Use Case (cont.)



Precondition: The user has registered.
Post-condition: The query details have
been logged.
Assumptions: The user has cookies
enabled; session remains open during
processing.
Alternate Courses of Events



Things don’t always go smoothly!
Exceptional conditions are recorded in
one or more “Alternate Course” blocks.
These describe reasons why the normal
course isn’t followed, and what alternate
actions are performed.
American FactFinder

Alternate course:
1.
2.
3.
4.
If the user is not registered, ask if she would like
to register. If so, send the registration page.
If the query doesn’t pass pre-processing, return a
page giving the bad news.
If the query will take more than 15 minutes to
process, advise the user, and ask whether to
continue.
If the query results don’t pass the post-processing
filters, return a page with the bad news.
Use Case Notation

A simple diagram, like this:
Web user

Request tabulation
Pretty stupid, eh?
Use Case Dependencies


Pre-conditions may force some use
cases to be performed before others are
legal.
This should be apparent from the textual
descriptions, but if you love diagrams:
Register
Request tabulation
Use Case Hierarchies



If there is commonality among several
use cases, the common parts can be
extracted.
Looking the other way `round, one use
case can extend another.
Reminiscent of abstract classes and
subclasses.
Finding Potential Objects




A use case may suggest objects that are
relevant to the system.
These will be “analysis-level” objects, not all
that will eventually be written.
Look for nouns in the use case description;
these are “potential” objects.
Screen these for




Relevance
Attribute?
Out of scope?
Keep the rest for design time.
When are you done?
 When you have named all actors
 When you have captured all the user goals with
respect to the system
 When each use case is clear enough that:
 the customer can understand them and agree on
the behaviour
 the developers can understand them and agree
that they can design against the behaviour
specified
 Remember that is is an incremental process
Sources For This Lecture




P.O. Flaatten, D.J. McCubbrey, P.D. O’Riordan,
K. Burgess, Foundations of Business Systems,
2nd ed., The Dryden Press, 1992.
S. Schach, Object-Oriented and Classical
Software Engineering, McGraw-Hill, 2002.
C. Gane and T. Sarson, Structured Systems
Analysis, Prentice Hall, 1979
J. Martin and J.J. Odell, Object-Oriented
Methods: A Foundation, Prentice Hall, 1995.
More Sources




Jacobson, I., Object-Oriented Software
Engineering, Addison-Wesley 1992.
Booch, G., Object-Oriented Analysis and
Design, 2nd ed., Addison-Wesley 1994.
Whitten, J.L. and L.D. Bentley, Systems
Analysis and Design Methods, McGraw-Hill,
1998.
R. Guha, S. Lang, M. Bassiouni, “Software
specification and design using Petri nets,” Proc.
Fourth Int. Workshop on Software Specification
and Design, pp. 225-30.