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 3estimate.

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

Data Flow

Data StoreExternalEntity

Transformsinputs to outputs

Movementof data

Disk, tape,voice mail...

Person or organizationproviding data

Process

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

Customer

customer data

package data

processorders

order

invoicecustomer status

package details

A Stepwise Refinement

Customer

package data

verifyorder isvalid

order

customer data

credit status

packagedetails

assembleorders

invoice

details ofpackageon hand

pending orders

details ofpackage tobe ordered

place orderat softwaresupplier

SoftwareSuplier

address

Fragment of Next Refinement

verifyorder isvalid

package data

customer data

credit status

package details

Customer order

assembleorders

createinvoice

applypayment toinvoice accounts rec’v

address

delivery details

invoice details

delivery note

invoice

payment details

payment

details of packageto be ordered

details of packageon hand

details of packagereceived fromsoftware 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

bottom-up. 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

p1

p2

p3

p4

Places P = {p1,…,p4}Transitions T = {t1, t2}Input functions I(t1) = {p2, p4}

I(t2) = {p2}

Output functionsO(t1) = {p1}O(t2) = {p3, p3}

t1t2

Petri Net With Tokens

p1

p2

p3

p4

t1t2

Marking: (1,2,0,1)t1 and t2 can fire

If t1 fires, themarking becomes(2,1,0,0)

After Firing t1 and t2

p1

p2

p3

p4

t1t2

Marking: (2,0,2,0)

Petri Net With Inhibitor

p1

p3

t1

t1 can fire, since p2

is empty, and p3

has a token

p2

The Elevator Problem n elevators in a building with m floors Each elevator has m buttons

light on when pressed, light off when elevator gets there

Each floor (except 1st and mth) has 2 buttons (up and down) 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 Ff

Fg

Elevator in actionEBf pressed

Second Constraint: Floor Buttons

FBDf Ff

Elevator in action

FBDf pressed

FBUf Ff

Fg

Elevator in actionFBUf pressed

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 analyst-

friendly? 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, bug-free, fast recovery): hard to measure at design-time

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. The user selects the base table (census,

business, health, etc.), then selects attributes.

3. The user submits the request by clicking OK.4. The query is checked by the pre-processing

filters.5. The query is submitted to the database.6. The result is checked by the post-processing

filters.7. 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. If the user is not registered, ask if she would like to register. If so, send the registration page.

2. If the query doesn’t pass pre-processing, return a page giving the bad news.

3. If the query will take more than 15 minutes to process, advise the user, and ask whether to continue.

4. 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:

Pretty stupid, eh?

Request tabulationWeb user

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:

Request tabulationRegister

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.