Analysis Workflow

 The primary activities of the Analysis workflow

are aimed at building the analysis model,
which helps the developers refine and
structure the functional requirements captured
within the use case model.

 This model contains realizations of use cases

that lend themselves to design and
implementation work better than the use
cases.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 11

Slide
Analysis Workflow vs Requirements Workflow

 Requirements Workflow – Users

external view of the system

 Analysis Workflow – expansion of the

requirements deliverables to further
describe the system from a developers
point of view.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 22

Slide
 Analysis Workflow Tasks

 GOAL:

 The goal of object-oriented analysis and

the analysis workflow is to

 REFINE THE REQUIREMENTS.

 To do this we need to deliver use case

realizations.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 33

Slide
 Analysis Workflow Tasks…

 The analysis use case realization is

essentially a model that contains
• behavioral and structural diagrams.

• - Structural diagrams are the Class diagrams.

• - Behavioral diagrams are the Collaboration or
Sequence diagrams

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 44

Slide
 Analysis Workflow Tasks
 STEPS
 1. Class Analysis
• Analysis class diagrams (no methods)
 2. Use Case Realizations
• Use Case descriptions
• Sequence Diagrams
 3. Advanced Items
• Analysis Packages
• Metadata Definition
• Analysis Patterns
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 55
Slide
 Analysis Workflow …

The aim of the analysis workflow

• - To analyze and refine the requirements
• - It is required to redefine the problems because
problems are defined in language of client's
language and may lack technical aspect.
Requirements are redefined in language of
programmer in this workflow.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 66

Slide
 Analysis Workflow

 Why not do this during the requirements

workflow?
• The requirements artifacts must be totally
comprehensible by the client
 The artifacts of the requirements workflow
must therefore be expressed in a natural
(human) language
• All natural languages are imprecise

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 77

Slide
 Analysis Workflow

Example from a manufacturing information

system:
• “A part record and a plant record are read from the
database. If it contains the letter A directly
followed by the letter Q, then calculate the cost of
transporting that part to that plant”
 To what does “it” refer?
• The part record?
• The plant record?
• Or the database?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 88

Slide
 Analysis Workflow

 Two separate workflows are needed

• The requirements artifacts must be expressed in the

language of the client

• The analysis artifacts must be precise, and complete

enough for the designers (although they may be
reviewed with sophisticated users)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 99

Slide
 Analysis Workflow
 Specification document (“specifications”)
• Constitutes a contract
• It must not have imprecise phrases like “optimal,” or
“98 percent complete”

 Having complete and correct specifications is

essential for
• Testing, and Maintenance

 The specification document must not have

• Contradictions / Omissions / Incompleteness

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 10
10
 Requirements workflow:

 -The primary activities of the Requirements

workflow are aimed at building the use case
model, which captures the functional
requirements of the system being defined.
 -This model helps the project stakeholders
reach agreement on the capabilities of the
system and the conditions to which it must
conform.
 -The use case model also serves as the
foundation for all other development work.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 11
11
 Determining the Client’s Needs
• Consider the requirements workflow

• The primary task of the systems analyst is to

determine what the client needs
– This may not be what the client says that he or
she wants

• Information systems are complex

– Clients therefore often ask for the wrong
information system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 12
12
 Determining the Client’s Needs (contd)

• It is hard for a systems analyst to visualize an

information system and its functionality
– The problem is far worse for the client

• A skilled systems analyst is needed to elicit the

appropriate information from the client

• The client is the only source of this information

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 13
13
 Determining the Client’s Needs (contd)

 The solution:
• Obtain initial information from the client
• Use this initial information as input to the Unified
Process
• Follow the steps of the Unified Process to
determine the client’s real needs

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 14
14
 Overview of the Requirements
Workflow

• First, gain an understanding of the application domain

(domain, for short)
– (The specific business environment in which the information
system is to operate)

• Second, build a business model

– Use UML to describe the client’s business processes

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

requirements

• Then iterate (“repeat”) the above steps

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide
Slide 15
15
 Flowchart of the Requirements
Workflow

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 16
16
 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 whole
– This 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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 17
17
 Interviewing

 The requirements team meet with the client

and users to extract all relevant information

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 18
18
 Interviewing (contd)
• There are two types of questions
– Close-ended questions requires a specific answer
– Open-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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 19
19
 Interviewing (contd)
• Interviewing is not easy
– An interview that is too unstructured will not yield much
relevant information
– The interviewer must be fully familiar with the
application domain
– The 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

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 20
20
 Initial Understanding:
Art Dealer Case Study

• Osbert Oglesby, Art Dealer, needs an information

system 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)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 21
21
 Glossary: Case Study

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 22
22
 Requirements Workflow: Art Dealer
• More details of each use case are needed now

• First consider use cases

– Buy a Painting, and
– Sell a Painting

• To refine the descriptions, determine what

attributes need to be input when a painting is
bought and when a painting is sold

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 23
23
 Attributes: Art dealer Case Study

• Attributes when buying a painting include:

– Title of work, name of artist, date of painting,
classification, medium, purchase price, name and
address of seller

• Attributes when selling a painting are:

– Date of sale, name of buyer, address of buyer,
actual selling price

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 24
24
 Requirements Workflow: Art dealer

 Now the algorithm for computing the maximum

purchase price is considered

 Classify the painting as a

• Masterpiece
• Masterwork, or
• Other painting

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 25
25
 Maximum Price for a Masterpiece
• Scan worldwide auction records over the past 25
years for the most similar work by the same artist

• Use the auction purchase price of the most similar

work as the base price

• The maximum purchase price is found by adding

7.5 percent to the base price, compounded
annually, for each year since that auction

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 26
26
 Maximum Price for a Masterwork
• Compute the maximum purchase price as if the
painting were a masterpiece by the same artist

• If the picture was painted in the 21st century,

multiply this figure by 0.25

• Otherwise, multiply it by (21 – c) / (22 – c), where

c is the century in which the work was painted
(12 < c < 21)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 27
27
 Maximum Price for an Other Painting

• Measure the dimensions of the canvas

• The maximum purchase price is then given by the

formula F  A, where
– F is a constant for that artist (fashionability coefficient),
and
– A is the area of the canvas in square centimeters

• If there is no fashionability coefficient for that

artist, Osbert will not buy the painting

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 28
28
 Coefficient of Similarity: Art dealer

• For a masterpiece or masterwork, the

coefficient of similarity between two paintings
is computed as follows:
– Score 1 for a match on medium, otherwise 0
– Score 1 for a match on subject, otherwise 0
– Add these two numbers, multiply by the area of
the smaller painting, and divide by the area of the
larger
– The resulting number is the coefficient of similarity

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 29
29
 Coefficient of Similarity: Art dealer…

 If the coefficient of similarity between the

painting under consideration and all the
paintings in the file of auction data is zero,
then Osbert will not buy that masterwork or
masterpiece

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 30
30
 Fashionability Coefficients: Art dealer

• The information system must include a list of

artists and their corresponding F values

• The value of F can vary from month to month,

depending on the current fashionability of an artist

• Osbert determines the value of F on the basis of

his knowledge and experience
– He changes the value if prices for work by an artist
increase or decrease

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 31
31
 Use-Case Modify a Fashionability
Coefficient

 Use-case description

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 32
32
 Second Iteration of Use-Case Diagram
 Incorporate all four use cases

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 33
33
 Analysis of Req. Workflow: Art dealer
• A fault was detected
– There was a missing use case
– The existing artifacts did not need to be changed

• Two additional artifacts had to be added

– A use case, and
– Its description

• The Unified Process is iterative and incremental

– Systems analysts must always be aware that changes
and extensions to the current version of the information
system may have to made at any time

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide

Slide 34
34