Slide 10A.1

© The McGraw-Hill Companies, 2005

Object-Oriented and Classical Software

Engineering

Sixth Edition, WCB/McGraw-Hill, 2005

Slide 10A.2

© The McGraw-Hill Companies, 2005

CHAPTER 10 — Unit A

REQUIREMENTS

Slide 10A.3

© The McGraw-Hill Companies, 2005

REQUIREMENTS- Overview

Determining what the client needs Overview of the requirements workflow Understanding the domain The business model Initial requirements Initial understanding of the domain: The Osbert

Oglesby case study Initial business model: The Osbert Oglesby case

study Initial requirements: The Osbert Oglesby case

study

Slide 10A.4

© The McGraw-Hill Companies, 2005

Overview (contd)

Continuing the requirements workflow: The Osbert Oglesby case study

The test workflow: The Osbert Oglesby case study The classical requirements phase Rapid prototyping Human factors Reusing the rapid prototype CASE tools for the requirements workflow Metrics for the requirements workflow Challenges of the requirements workflow

Slide 10A.5

© The McGraw-Hill Companies, 2005

The Aim of the Requirements Workflow

To answer the question:

What must the product be able to do?

Slide 10A.6

© The McGraw-Hill Companies, 2005

10.1 Determining What the Client Needs

Misconception We must determine what the client wants

“I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!”

We must determine what the client needs

Slide 10A.7

© The McGraw-Hill Companies, 2005

Determining What the Client Needs (contd)

It is hard for a systems analyst to visualize a software product and its functionalityThe problem is far worse for the client

A skilled systems analyst is needed to elicit (bring out) the appropriate information from the client

The client is the only source of this information

Slide 10A.8

© The McGraw-Hill Companies, 2005

Determining What the Client Needs (contd)

The solution:Obtain initial information from the client Use this initial information as input to the Unified

ProcessFollow the steps of the Unified Process to determine the

client’s real needs

Slide 10A.9

© The McGraw-Hill Companies, 2005

10.2 Overview of the Requirements Workflow

First, gain an understanding of the application domain (or domain, for short)The specific environment in which the target product is to

operate

Second, build a business modelModel the client’s business processes

Third, use the business model to determine the client’s requirements

Iterate the above steps

Slide 10A.10

© The McGraw-Hill Companies, 2005

Definitions

Discovering the client’s requirementsRequirements elicitation (or requirements capture)Methods include interviews and surveys

Refining and extending the initial requirements Requirements analysis

Slide 10A.11

© The McGraw-Hill Companies, 2005

10.3 Understanding the Domain

Every member of the development team must become fully familiar with the application domainCorrect terminology is essential

Construct a glossaryA list of technical words used in the domain, and their

meanings

Slide 10A.12

© The McGraw-Hill Companies, 2005

10.4 Business Model

A business model is a description of the business processes of an organization

The business model gives an understanding of the client’s business as a wholeThis knowledge is essential for advising the client

regarding computerization

The systems analyst needs to obtain a detailed understanding of the various business processes  Different techniques are used, primarily interviewing

Slide 10A.13

© The McGraw-Hill Companies, 2005

10.4.1 Interviewing

The requirements team meet with the client and users to extract all relevant information

Slide 10A.14

© The McGraw-Hill Companies, 2005

Interviewing (contd)

There are two types of questionsClose-ended questions require a specific answerOpen-ended questions are asked to encourage the

person being interviewed to speak out

There are two types of interviews In a structured interview, specific preplanned questions

are asked, frequently close-ended In an unstructured interview, questions are posed in

response to the answers received, frequently open-ended

Slide 10A.15

© The McGraw-Hill Companies, 2005

Interviewing (contd)

Interviewing is not easyAn interview that is too unstructured will not yield much

relevant informationThe interviewer must be fully familiar with the

application domainThe interviewer must remain open-minded at all times

After the interview, the interviewer must prepare a written report It is strongly advisable to give a copy of the report to the

person who was interviewed

Slide 10A.16

© The McGraw-Hill Companies, 2005

10.4.2 Other Techniques

Interviewing is the primary technique

A questionnaire is useful when the opinions of hundreds of individuals need to be determined

Examination of business forms shows how the client currently does business

Slide 10A.17

© The McGraw-Hill Companies, 2005

Other Techniques (contd)

Direct observation of the employees while they perform their duties can be usefulVideotape cameras are a modern version of this

techniqueBut, it can take a long time to analyze the tapesEmployees may view the cameras as an unwarranted

invasion of privacy

Slide 10A.18

© The McGraw-Hill Companies, 2005

10.4.3 Use Cases

+A use case models an interaction (business activity) between the software product itself and the users of that software product (actors)

Example:

Figure 10.1

Slide 10A.19

© The McGraw-Hill Companies, 2005

Use Cases (contd)

An actor is a member of the world outside the software product

It is usually easy to identify an actorAn actor is frequently a user of the software product

In general, an actor plays a role with regard to the software product. This role isAs a user; orAs an initiator; orAs someone who plays a critical part in the use case

Slide 10A.20

© The McGraw-Hill Companies, 2005

Use Cases (contd)

A user of the system can play more than one role

Example: A customer of the bank can beA Borrower or A Lender

Slide 10A.21

© The McGraw-Hill Companies, 2005

Use Cases (contd)

Conversely, one actor can be a participant in multiple use cases

Example: A Borrower may be an actor in The Borrow Money use case;The Pay Interest on Loan use case; and The Repay Loan Principal use case

Also, the actor Borrower may stand for many thousands of bank customers

Slide 10A.22

© The McGraw-Hill Companies, 2005

Use Cases (contd)

An actor need not be a human being

Example: An e-commerce information system has to interact with the credit card company information systemThe credit card company information system is an actor

from the viewpoint of the e-commerce information system

The e-commerce information system is an actor from the viewpoint of the credit card company information system

Slide 10A.23

© The McGraw-Hill Companies, 2005

Use Cases (contd)

A potential problem when identifying actorsOverlapping actors

Example: Hospital software productOne use case has actor NurseA different use case has actor Medical StaffBetter:

Actors: Physician and Nurse

Slide 10A.24

© The McGraw-Hill Companies, 2005

Use Cases (contd)

Alternatively: Actor Medical Staff with two specializations: Physician

and Nurse

Figure 10.2

Slide 10A.25

© The McGraw-Hill Companies, 2005

10.5 Initial Requirements

The initial requirements are based on the initial business model

Then they are refined

The requirements are dynamic — there are frequent changesMaintain a list of likely requirements, together with use

cases of requirements approved by the client

Slide 10A.26

© The McGraw-Hill Companies, 2005

Initial Requirements (contd)

There are two categories of requirements

A functional requirement specifies an action that the software product must be able to performOften expressed in terms of inputs and outputs

A nonfunctional requirement specifies properties of the software product itself, such as Platform constraintsResponse timesReliability

Slide 10A.27

© The McGraw-Hill Companies, 2005

Initial Requirements (contd)

Functional requirements are handled as part of the requirements and analysis workflows

Some nonfunctional requirements have to wait until the design workflowThe detailed information for some nonfunctional

requirements is not available until the requirements and analysis workflows have been completed

Slide 10A.28

© The McGraw-Hill Companies, 2005

10.6 Initial Understanding of the Domain: The Osbert Oglesby Case Study

Osbert Oglesby, Art Dealer, needs a software product to assist him in buying and selling paintings

Obtaining domain knowledge is the first step

Osbert is interviewed to obtain the relevant information

This information is put into a glossary (see next slide)

Slide 10A.29

© The McGraw-Hill Companies, 2005

Glossary: The Osbert Oglesby Case Study

Figure 10.3

Slide 10A.30

© The McGraw-Hill Companies, 2005

10.7 Initial Business Model: The Osbert Oglesby Case Study

Osbert wants an software product, running on his laptop computer, that will Determine the maximum price he should pay for a

paintingDetect new trends in the art market as soon as possible

To do this, the software product needs to keep a record of all purchases and all sales

Slide 10A.31

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Currently, Osbert produces reports of annual sales and purchases by handAt only a small additional cost, the software product can

also print these two reports on demand

It is vital to determine the client’s needs up front, and not after the software product has been delivered

Slide 10A.32

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Osbert has three business activities: He buys paintingsHe sells paintingsHe produces reports

Slide 10A.33

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Buy a Painting use case

Figure 10.4

Slide 10A.34

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Sell a Painting use case

Figure 10.5

Slide 10A.35

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Produce a Report use case

Figure 10.6

Slide 10A.36

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

For conciseness, all three use cases are combined into a use-case diagram  

Figure 10.7

Slide 10A.37

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

The only person who uses the current (manual) software product is OsbertOsbert is therefore an actor in all three use cases

The customer may initiate the Buy a Painting or the Sell a Painting use case

The customer plays a critical part in both use cases by providing data entered into the software product by OsbertThe customer is therefore an actor in both these use

cases

Slide 10A.38

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Next, the use cases have to be annotated

Here are the initial use-case descriptions

Slide 10A.39

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Buy a Painting use case

Figure 10.8

Slide 10A.40

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Sell a Painting use case

Figure 10.9

Slide 10A.41

© The McGraw-Hill Companies, 2005

Initial Business Model: The Osbert Oglesby Case Study (contd)

Produce a Report use case

Figure 10.10

Slide 10A.42

© The McGraw-Hill Companies, 2005

Continued in Unit 10B