Object-Oriented Analysis and Design

Lecture 2

Requirements and Specification

Last Time

   Functional

vs.

requirements nonfunctional 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

Customer order invoice package data package details process orders customer status customer data

A Stepwise Refinement

Customer order package data Software Suplier package details details of package to be ordered verify order is valid credit status address pending orders place order at software supplier customer data invoice assemble orders details of package on hand

Fragment of Next Refinement

Customer payment apply payment to invoice package data order package details verify order is valid details of package to be ordered credit status customer data details of package on hand delivery note assemble address orders invoice create invoice delivery details details of package received from software agency payment details invoice details accounts rec’v

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

p 1

A Simple Petri Net

t 1 p 2 t 2 Places P = {p 1 ,…,p 4 } Transitions T = {t 1 , t 2 } Input functions I(t 1 ) = {p 2, p 4 } I(t 2 ) = {p 2 } p 3 p 4 Output functions O(t 1 ) = {p 1 } O(t 2 ) = {p 3 , p 3 }

Petri Net With Tokens

p 2 Marking : (1,2,0,1) t 1 and t 2 can fire p 1 t 1 t 2 p 3 p 4 If t 1 fires, the marking becomes (2,1,0,0)

After Firing t

1

and t

2 p 2 Marking: (2,0,2,0) p 1 t 1 t 2 p 3 p 4

Petri Net With Inhibitor

p 2 t 1 can fire, since p 2 is empty, and p 3 has a token p 1 t 1 p 3

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 1 st (up and down) and m th ) has 2 buttons  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 F f , 1

First Constraint: Elevator Buttons

  We need more “places”: EB f,e with 1  f  m, 1  e  n To keep things simpler, just use EB f with 1  f  m EB f pressed EB f Elevator in action F f F g

Second Constraint: Floor Buttons

FBU f pressed FBU f Elevator in action F f F g FBD f pressed FBD f F f 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 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.

1.

Normal course: 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

 1.

Alternate course: If the user is not registered, ask if she would like to register. If so, send the registration page.

2.

3.

4.

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, 2 nd 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,” Fourth Int. Workshop on Software Specification and Design , pp. 225-30.

Proc.