THE REQUIREMENTS WORKFLOW
Chapter Overview







Determining What the Client Needs
Overview of the Requirements Workflow
Understanding the Domain
Initial Understanding of the Domain: Osbert Oglesby Case Study
Business Model
Interviewing
Other techniques
R.Rajkumar AP/CSE
Chapter Overview (contd)
 Use Cases
 Initial Business Model: Osbert Oglesby Case Study
 Initial Requirements
 Initial Requirements: Osbert Oglesby Case Study
 Continuing the Requirements Workflow: Osbert Oglesby Case Study
 It Ain’t Over Till it’s Over
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
Flowchart of the Requirements Workflow
R.Rajkumar AP/CSE
Definitions
 Discovering the client’s requirements
 Requirements elicitation (or requirements capture)
 Methods include interviews and surveys
 Refining and extending the initial requirements
 Requirements analysis
R.Rajkumar AP/CSE
Understanding the Domain
 Every member of the development team must become fully
familiar application domain
 Correct terminology is essential
 We must build a glossary
 That is, a list of technical words used in the domain, and their
meaning
R.Rajkumar AP/CSE
Initial Understanding: Osbert Oglesby
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)
R.Rajkumar AP/CSE
Glossary: Osbert Oglesby Case Study
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
Interviewing
 The requirements team meet with the client and users to
extract all relevant information
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
Other Information Gathering
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
R.Rajkumar AP/CSE
Other Information Gathering
Techniques (contd)
 Direct observation of the employees while they perform
their duties can be useful
 Videotape cameras are modern version of this technique
 But, it can take a long time to analyze the tapes
 Employees may view the cameras as an unwarranted invasion of
privacy
R.Rajkumar AP/CSE
Use Cases
 A use case models an interaction between the information
system itself and the users of that information system (actors)
 Example:
R.Rajkumar AP/CSE
Use Cases (contd)
 A use case shows the interaction between
 The information system and
 The environment in which the information system operates
 Each use case models one type of interaction
 There can be just a few use cases for an information system, or
there can be hundreds
 The rectangle in the use case represents the information
system itself
R.Rajkumar AP/CSE
Use Cases (contd)
 An actor is a member of the world outside the information
system
 It is usually easy to identify an actor
 An actor is frequently a user of the information system
 In general, an actor plays a role with regard to the
information system. This role is
 As a user; or
 As an initiator; or
 As someone who plays a critical part in the use case
R.Rajkumar AP/CSE
Use Cases (contd)
 A user of the system can play more than one role
 Example: A customer of the bank can be
 A Borrower or
 A Lender
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
Use Cases (contd)
 An actor need not be a human being
 Example: The Cardholder Clothing Company information
system has to interact with the credit card company
information system
 The credit card company information system is an actor from
the viewpoint of the Cardholder Clothing Company
information system
 The Cardholder Clothing Company information system is an
actor from the viewpoint of the credit card company
information system
R.Rajkumar AP/CSE
Use Cases (contd)
 A potential problem when identifying actors
 Overlapping actors
 Example: Hospital Information System
 One use case has actor Nurse
 A different use case has actor Medical Staff
 Better:
 Actors: Physician and Nurse
R.Rajkumar AP/CSE
Use Cases (contd)
 Alternatively:
 Actor Medical Staff with two specializations: Physician and
Nurse
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 Osbert wants an information system, running on his laptop
computer, that will
 Determine the maximum price he should pay for a painting
 Detect new trends in the art market as soon as possible
 To do this, the information system needs to keep a record of all
purchases and all sales
 Currently, Osbert produces reports of annual sales and purchases
by hand
 At only a small additional cost, the information system can also print
these two reports on demand
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 Osbert wants an information system that can
 Compute the highest price he should pay for a painting; and
 Detect new art trends
 Osbert needs an information system that can also
 Provide reports on purchases and sales
 It is vital to determine the client’s needs up front, and not
after the information system has been delivered
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 Osbert has three business activities:
 He buys paintings
 He sells paintings
 He produces reports
R.Rajkumar AP/CSE

Init. Business Model: Osbert Oglesby
Case Study
Buy a Painting use case
R.Rajkumar AP/CSE

Init. Business Model: Osbert Oglesby
Case Study
Sell a Painting use case
R.Rajkumar AP/CSE

Init. Business Model: Osbert Oglesby
Case Study
Produce a Report use case
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 For conciseness, all three use cases are combined into a use-
case diagram
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 The only person who uses the current (manual) information
system is Osbert
 Osbert 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 information system by
Osbert
 The customer is therefore an actor in both these use cases
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 Next, the use cases have to be annotated
 Here are the initial use-case descriptions
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 Buy a Painting use case
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 Sell a Painting use case
R.Rajkumar AP/CSE
Init. Business Model: Osbert Oglesby
Case Study
 Produce a Report use case
R.Rajkumar AP/CSE
Initial Requirements
 The initial requirements are based on the initial business
model
 Then they are refined
 The requirements are dynamic—there are frequent changes
 Maintain a list of likely requirements, together with use cases of
requirements approved by the client
R.Rajkumar AP/CSE
Initial Requirements (contd)
 There are two categories of requirements
 A functional requirement specifies an action that the
information system must be able to perform
 Often expressed in terms of inputs and outputs
 A nonfunctional requirement specifies properties of the
information system itself, such as
 Platform constraints
 Response times
 Reliability
R.Rajkumar AP/CSE
Initial Requirements (contd)
 Functional requirements are handled as part of the
requirements and analysis workflows
 Some nonfunctional requirements have to wait until the
design workflow
 The detailed information for some nonfunctional requirements
is not available until the requirements and analysis workflows
have been completed
R.Rajkumar AP/CSE
Initial Requirements: Osbert Oglesby
Case Study
 The initial business model (the three use cases) shows how
Osbert currently does business
 Decide which of these use cases are also requirements of the
information system to be built
 Clearly, all three are requirements
 Refine the resulting initial requirements
 The descriptions of the use cases have to be refined
R.Rajkumar AP/CSE

Initial Requirements: Osbert Oglesby
Buy a Painting use case
R.Rajkumar AP/CSE

Initial Requirements: Osbert Oglesby
(contd)
Sell a Painting use case
R.Rajkumar AP/CSE

Initial Requirements: Osbert Oglesby
(contd)
Produce a Report use case
R.Rajkumar AP/CSE
Initial Requirements: Osbert Oglesby
(contd)
 All three descriptions are still vague
 A consequence of the iterative nature of the Unified Process
 For example, the algorithm details are irrelevant at this time
 Basic principle: Defer all details to as late as possible
 This will simplify the inevitable changes of the next iteration
R.Rajkumar AP/CSE
Requirements Workflow: Osbert
Oglesby
 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
R.Rajkumar AP/CSE
Attributes: Osbert Oglesby 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
 (The complete list of attributes appears in the textbook in
Figure 4.15)
 Attributes when selling a painting are:
 Date of sale, name of buyer, address of buyer, actual selling
price
R.Rajkumar AP/CSE
Requirements Workflow: Osbert
Oglesby
 Now the algorithm for computing the maximum purchase
price is considered
 Classify the painting as a
 Masterpiece
 Masterwork, or
 Other painting
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
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)
R.Rajkumar AP/CSE
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
R.Rajkumar AP/CSE
Coefficient of Similarity: Osbert
Oglesby
 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
R.Rajkumar AP/CSE
Coefficient of Similarity: Osbert
Oglesby (contd)
 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
R.Rajkumar AP/CSE
Fashionability Coefficients: Osbert
Oglesby
 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
R.Rajkumar AP/CSE
Auction Data: Osbert Oglesby Case
Study
 The information system must utilize information on auction
sales of masterpieces over the past 25 years worldwide
 Each month Osbert receives a CD with updated worldwide
auction prices; these prices are never modified by Osbert
R.Rajkumar AP/CSE
Updated Use Cases : Osbert Oglesby
Case Study
 The use-case descriptions must reflect this information
 The resulting description of the Buy a Painting use case is in
Figure 4.15
R.Rajkumar AP/CSE
Updated Use Cases : Osbert Oglesby
Case Study
 The description of the Sell a Painting use case:
R.Rajkumar AP/CSE
Reports for the Osbert Oglesby Case
Study
 There are three reports:
 Purchases during the past year
 Sales during the past year
 Detection of new trends
 Sample reports show Osbert’s needs are as follows (question
marks in the first or last name of artist, or in the title or date
of the work are to be included in all reports):
R.Rajkumar AP/CSE
Report of Purchases during the Past
Year
 A report is needed to display all the paintings purchased
during the past year
 The average ratio of the purchase price to the suggested
maximum price is required at the end of the report
R.Rajkumar AP/CSE
Report of Sales during the Past Year
 A report is needed to display all the paintings sold during the
past year
 The average ratio of the actual selling price to the target selling
price is required at the end of the report
R.Rajkumar AP/CSE
Report of Trends during the Past Year
 A report showing artists whose works Osbert has sold at a
price that has exceeded the target selling price in every
instance during the past year
 To appear in this report, at least two of the artist’s works must
have been sold by Osbert during that period
R.Rajkumar AP/CSE
Updated Use-Case Description:
Produce a Report
 The updated description of the Produce a Report use case,
incorporating the details listed above, appears in Figure 4.20
R.Rajkumar AP/CSE
It Ain’t Over Till it’s Over
 There is a serious omission
 The use case for updating a fashionability coefficient has been
overlooked
 Missing use case Modify a Fashionability Coefficient
R.Rajkumar AP/CSE
Use-Case Modify a Fashionability
Coefficient
 Use-case description
R.Rajkumar AP/CSE
Second Iteration of Use-Case Diagram
 Incorporate all four use cases
R.Rajkumar AP/CSE
Analysis of Req. Workflow: Osbert
Oglesby
 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
R.Rajkumar AP/CSE