Slide 10..1
© The McGraw-Hill Companies, 2007
Object-Oriented andClassical Software
Engineering
Seventh Edition, WCB/McGraw-Hill, 2007
Stephen R. [email protected]
Slide 10..2
© The McGraw-Hill Companies, 2007
CHAPTER 10
REQUIREMENTS
Slide 10..3
© The McGraw-Hill Companies, 2007
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 MSG
Foundation case study Initial business model: The MSG Foundation case
study
Slide 10..4
© The McGraw-Hill Companies, 2007
Overview (contd)
Initial requirements: The MSG Foundation casestudy
Continuing the requirements workflow: The MSGFoundation case study
Revising the requirements: The MSG Foundationcase study
The test workflow: The MSG Foundation casestudy
The classical requirements phase Rapid prototyping
Slide 10..5
© The McGraw-Hill Companies, 2007
Overview (contd)
Human factors Reusing the rapid prototype CASE tools for the requirements workflow Metrics for the requirements workflow Challenges of the requirements workflow
Slide 10..6
© The McGraw-Hill Companies, 2007
The Aim of the Requirements Workflow
To answer the question:
What must the product be able to do?
Slide 10..7
© The McGraw-Hill Companies, 2007
10.1 Determining What the Client Needs
MisconceptionWe must determine what the client wants
“I know you believe you understood what you thinkI said, but I am not sure you realize that what youheard is not what I meant!”
We must determine what the client needs
Slide 10..8
© The McGraw-Hill Companies, 2007
Determining What the Client Needs (contd)
It is hard for a systems analyst to visualize asoftware product and its functionalityThe problem is far worse for the client
A skilled systems analyst is needed to elicit theappropriate information from the client
The client is the only source of this information
Slide 10..9
© The McGraw-Hill Companies, 2007
Determining What the Client Needs (contd)
The solution:Obtain initial information from the clientUse this initial information as input to the Unified
ProcessFollow the steps of the Unified Process to determine the
client’s real needs
Slide 10..10
© The McGraw-Hill Companies, 2007
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 theclient’s requirements
Iterate the above steps
Slide 10..11
© The McGraw-Hill Companies, 2007
Definitions
Discovering the client’s requirementsRequirements elicitation (or requirements capture)Methods include interviews and surveys
Refining and extending the initial requirementsRequirements analysis
Slide 10..12
© The McGraw-Hill Companies, 2007
10.3 Understanding the Domain
Every member of the development team mustbecome fully familiar with the application domainCorrect terminology is essential
Construct a glossaryA list of technical words used in the domain, and their
meanings
Slide 10..13
© The McGraw-Hill Companies, 2007
10.4 Business Model
A business model is a description of the businessprocesses of an organization
The business model gives an understanding of theclient’s business as a wholeThis knowledge is essential for advising the client
regarding computerization
The systems analyst needs to obtain a detailedunderstanding of the various business processes Different techniques are used, primarily interviewing
Slide 10..14
© The McGraw-Hill Companies, 2007
10.4.1 Interviewing
The requirements team meet with the client andusers to extract all relevant information
Slide 10..15
© The McGraw-Hill Companies, 2007
Interviewing (contd)
There are two types of questionsClose-ended questions require a specific answerOpen-ended questions are posed to encourage the
person being interviewed to speak out
There are two types of interviewsIn a structured interview, specific preplanned questions
are asked, frequently close-endedIn an unstructured interview, questions are posed in
response to the answers received, frequently open-ended
Slide 10..16
© The McGraw-Hill Companies, 2007
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 awritten reportIt is strongly advisable to give a copy of the report to the
person who was interviewed
Slide 10..17
© The McGraw-Hill Companies, 2007
10.4.2 Other Techniques
Interviewing is the primary technique
A questionnaire is useful when the opinions ofhundreds of individuals need to be determined
Examination of business forms shows how theclient currently does business
Slide 10..18
© The McGraw-Hill Companies, 2007
Other Techniques (contd)
Direct observation of the employees while theyperform 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 10..19
© The McGraw-Hill Companies, 2007
10.4.3 Use Cases
A use case models an interaction between thesoftware product itself and the users of thatsoftware product (actors)
Example:
Figure 10.1
Slide 10..20
© The McGraw-Hill Companies, 2007
Use Cases (contd)
An actor is a member of the world outside thesoftware 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 thesoftware product. This role isAs a user; orAs an initiator; orAs someone who plays a critical part in the use case
Slide 10..21
© The McGraw-Hill Companies, 2007
Use Cases (contd)
A user of the system can play more than one role
Example: A customer of the bank can beA Borrower orA Lender
Slide 10..22
© The McGraw-Hill Companies, 2007
Use Cases (contd)
Conversely, one actor can be a participant inmultiple use cases
Example: A Borrower may be an actor inThe Borrow Money use case;The Pay Interest on Loan use case; andThe Repay Loan Principal use case
Also, the actor Borrower may stand for manythousands of bank customers
Slide 10..23
© The McGraw-Hill Companies, 2007
Use Cases (contd)
An actor need not be a human being
Example: An e-commerce information system hasto interact with the credit card companyinformation systemThe credit card company information system is an actor
from the viewpoint of the e-commerce informationsystem
The e-commerce information system is an actor fromthe viewpoint of the credit card company informationsystem
Slide 10..24
© The McGraw-Hill Companies, 2007
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 10..25
© The McGraw-Hill Companies, 2007
Use Cases (contd)
Alternatively:Actor Medical Staff with two specializations: Physician
and Nurse
Figure 10.2
Slide 10..26
© The McGraw-Hill Companies, 2007
10.5 Initial Requirements
The initial requirements are based on the initialbusiness model
Then they are refined
The requirements are dynamic — there arefrequent changesMaintain a list of likely requirements, together with use
cases of requirements approved by the client
Slide 10..27
© The McGraw-Hill Companies, 2007
Initial Requirements (contd)
There are two categories of requirements
A functional requirement specifies an action thatthe software product must be able to performOften expressed in terms of inputs and outputs
A nonfunctional requirement specifies properties ofthe software product itself, such asPlatform constraintsResponse timesReliability
Slide 10..28
© The McGraw-Hill Companies, 2007
Initial Requirements (contd)
Functional requirements are handled as part of therequirements and analysis workflows
Some nonfunctional requirements have to waituntil the design workflowThe detailed information for some nonfunctional
requirements is not available until the requirements andanalysis workflows have been completed
Slide 10..29
© The McGraw-Hill Companies, 2007
10.6 Initial Understanding of the Domain: MSG Case Study
The Martha Stockton Greengage Foundation(“MSG”) provides low cost mortgage loans toyoung couples
The trustees commission a pilot projectA software product to determine how much money is
available each week to purchase homes
Slide 10..30
© The McGraw-Hill Companies, 2007
Initial Understanding of the Domain: MSG Case Study (contd)
A mortgage is a loan in which real estate is usedas security
Example: House costs $100,000
Buyer pays a 10% deposit and borrows thebalanceThe principal (or capital) borrowed is $90,000
Loan is to be repaid monthly over 30 yearsInterest rate of 7.5% per annum (or 0.625% per month)
Slide 10..31
© The McGraw-Hill Companies, 2007
Initial Understanding of the Domain: MSG Case Study (contd)
Each month, the borrower pays $629.30Part of this is the interest on the outstanding balanceThe rest is used to reduce the principal
The monthly payment is therefore often referred toas P & I (principal and interest)
Slide 10..32
© The McGraw-Hill Companies, 2007
Mortgage Payments: First Month
In the first month the outstanding balance is$90,000Monthly interest at 0.625% on $90,000 is $562.50The remainder of the P & I payment of $629.30, namely
$66.80, is used to reduce the principal
At the end of the first month, after the first paymenthas been made, only $89,933.20 is owed to thefinance company
Slide 10..33
© The McGraw-Hill Companies, 2007
Mortgage Payments: Second Month
In the second month the outstanding balance is$89,933.20Monthly interest at 0.625% on $89,933.20 is $562.08The remainder of the P & I payment of $629.30, namely
$67.22, is used to reduce the principal
At the end of the second month, after the secondpayment has been made, only $89,865.98 is owedto the finance company
Slide 10..34
© The McGraw-Hill Companies, 2007
Mortgage Payments: After 15 and 30 Years
After 15 years (180 months) the outstandingbalance is $67,881.61Monthly interest at 0.625% on $67,881.61 is $424.26The remainder of the P & I payment of $629.30, namely
$205.04, is used to reduce the principal
After 30 years (360 months), the entire loan willhave been repaid
Slide 10..35
© The McGraw-Hill Companies, 2007
Insurance Premiums
The finance company requires the borrower toinsure the houseIf the house burns down, the check from the insurance
company will then be used to repay the loan
Slide 10..36
© The McGraw-Hill Companies, 2007
Insurance Premiums (contd)
The insurance premium is paid once a year by thefinance companyThe finance company requires the borrower to pay
monthly insurance installmentsThese are deposited in an escrow account (a savings
account)
The annual premium is then paid from the escrowaccount
Slide 10..37
© The McGraw-Hill Companies, 2007
Real Estate Taxes
Real-estate taxes paid on a home are treated thesame way as insurance premiumsMonthly installments are deposited in the escrow
accountThe annual real-estate tax payment is made from that
account
Slide 10..38
© The McGraw-Hill Companies, 2007
Borrowing Limits
A mortgage will not be granted unless the totalmonthly payment (P & I plus insurance plus real-estate taxes) is less than 28% of the borrower’stotal income
Slide 10..39
© The McGraw-Hill Companies, 2007
Other Costs
The finance company requires a lump sum upfront in return for lending the money to theborrowerTypically, the finance company will want 2% of the
principal (“2 points”)For the $90,000 loan, this amounts to $1,800
Slide 10..40
© The McGraw-Hill Companies, 2007
Other Costs (contd)
There are other costs involved in buying a houseLegal costsVarious taxes
When the deal is “closed,” the closing costs (legalcosts, taxes, and so on) plus the points can easilyamount to $7,000
Slide 10..41
© The McGraw-Hill Companies, 2007
Initial Glossary
Figure 10.3
Slide 10..42
© The McGraw-Hill Companies, 2007
10.7 Initial Business Model: MSG Case Study
At the start of each week, MSG estimates howmuch money will be available that week to fundmortgages
Low-income couples can apply at any time
Slide 10..43
© The McGraw-Hill Companies, 2007
Initial Business Model: MSG Case Study (contd)
An MSG Foundation staff member determinesWhether the couple qualifies for an MSG mortgage, andWhether MSG has sufficient funds on hand to purchase
the home
If so, the mortgage is grantedThe weekly mortgage repayment is computed according
to MSG rules
This repayment amount may vary from week toweek, depending on the couple’s current income
Slide 10..44
© The McGraw-Hill Companies, 2007
Initial Business Model: MSG Case Study (contd)
There are three use cases Estimate Funds Available for Week
Apply for an MSG Mortgage
Compute Weekly Repayment Amount
Slide 10..45
© The McGraw-Hill Companies, 2007
Estimate Funds Available for Week Use Case
Figure 10.4
Figure 10.7
Slide 10..46
© The McGraw-Hill Companies, 2007
Apply for an MSG MortgageUse Case
Figure 10.5
Figure 10.8
Slide 10..47
© The McGraw-Hill Companies, 2007
Compute Weekly Repayment Amount Use Case
Figure 10.6
Figure 10.9
Slide 10..48
© The McGraw-Hill Companies, 2007
Who Is an Actor?
Why is Applicants an actor in use case Apply for anMSG Mortgage?
Applicants do not interact with the softwareproductTheir answers are entered into the software product by
an MSG staff member
Slide 10..49
© The McGraw-Hill Companies, 2007
Who Is an Actor? (contd)
However,The applicants initiate the use caseThe applicants provide the data entered by MSG staffThe real actor is therefore Applicants — the MSG Staff
Member is merely an agent of the applicants
Applicants is therefore indeed an actor
Slide 10..50
© The McGraw-Hill Companies, 2007
Who Is an Actor? (contd)
Similarly, Borrowers is an actor in use caseCompute Weekly Repayment Amount
Again the use case is initiated by actor BorrowersAgain the information entered by MSG staff is supplied
by the borrowers
Thus, Borrowers is indeed an actor in the usecase
Slide 10..51
© The McGraw-Hill Companies, 2007
Manage an InvestmentUse Case
At this stage, no details are known regardingThe buying and selling of investments, orHow investment income becomes available for
mortgages
However, use case Manage an Investment is anessential part of the initial business model
Slide 10..52
© The McGraw-Hill Companies, 2007
Manage an InvestmentUse Case (contd)
Figure 10.10
Figure 10.11
Slide 10..53
© The McGraw-Hill Companies, 2007
Use-Case Diagram of the Initial Business Model
Figure 10.12
Slide 10..54
© The McGraw-Hill Companies, 2007
10.8 Initial Requirements: MSG Case Study
It is unclear if all four use cases are allrequirements of the product to be developedWhat, exactly, is “a pilot project”?
The best way to proceed isDraw up the initial requirements on the basis of what the
client wants, and then iterate
Slide 10..55
© The McGraw-Hill Companies, 2007
Initial Requirements: MSG Case Study (contd)
Consider each use case in turn:
Estimate Funds Available for Week is obviously part ofthe initial requirements
Apply for an MSG Mortgage does not seem to haveanything to do with the pilot project, so it isexcluded
Slide 10..56
© The McGraw-Hill Companies, 2007
Initial Requirements: MSG Case Study (contd)
Compute Weekly Repayment Amount, and Manage an Investment
Both appear to be irrelevant to the pilot project
However, the pilot project deals with the “moneythat is available each week to purchase homes”Some of that money comes from the weekly repayment
of existing mortgages, and from income frominvestments
The resulting use-case diagram is shown on thenext slide
Slide 10..57
© The McGraw-Hill Companies, 2007
Initial Use-Case Diagram: MSG Case Study
The next step: Iterate the requirements workflow
Figure 10.13
Slide 10..58
© The McGraw-Hill Companies, 2007
10.9 Continuing the Requirements Workflow: MSG
The systems analysts learn that the MSGFoundation grants a 100% mortgage to buy ahome under the following conditions:The couple has been legally married for at least 1 year
but not more than 10 yearsBoth husband and wife are gainfully employedThe price of the home must be below the published
median price for homes in that area for the past 12months
Their income and/or savings are insufficient to afford astandard fixed-rate 30-year 90% mortgage
The foundation has sufficient funds to purchase thehome
Slide 10..59
© The McGraw-Hill Companies, 2007
Conditions for an MSG Mortgage (contd)
If the application is approved, then each week forthe next 30 years the couple pays MSGThe total of the principal and interest payment — this
never changes over the life of the mortgage; plusThe escrow payment, which is 1/52nd of the sum of the
annual real-estate tax and the annual homeowner’sinsurance premium
If this exceeds 28% of the couple’s gross weeklyincome, MSG pays the difference as a grantThe couple must provide proof of their current income
— the weekly payment may vary from week to week
Slide 10..60
© The McGraw-Hill Companies, 2007
Algorithm to Determine If Funds Are Available
(1) At the beginning of the week, the estimatedannual income from MSG investments iscomputed and divided by 52
(2) The estimated annual MSG operatingexpenses are divided by 52
(3) The total of the estimated mortgage paymentsfor the week is computed
Slide 10..61
© The McGraw-Hill Companies, 2007
Algorithm to Determine If Funds Are Available
(4) The total of the estimated grants for the weekis computed
(5) The amount available at the beginning of theweek is then (1) – (2) + (3) – (4)
(6) If the cost of the home is no more than (5),funds are provided to buy the home
(7) At the end of each week, any unspent fundsare invested
Slide 10..62
© The McGraw-Hill Companies, 2007
Requirements of the Pilot Project
To keep the cost of the pilot project as low aspossible, only those data items needed for theweekly funds computation will be included
Only three types of data are therefore needed:Investment dataOperating expenses dataMortgage data
Slide 10..63
© The McGraw-Hill Companies, 2007
Investment Data
Item number Item name Estimated annual return Date estimated annual return was last updated
Slide 10..64
© The McGraw-Hill Companies, 2007
Operating Expenses Data
Estimated annual operating expenses Date estimated annual operating expenses was
last updated
Slide 10..65
© The McGraw-Hill Companies, 2007
Mortgage Data
Account number Last name of mortgagees Original purchase price of home Date mortgage was issued Weekly principal and interest payment Current combined gross weekly income Date combined gross weekly income was last
updated
Slide 10..66
© The McGraw-Hill Companies, 2007
Mortgage Data (contd)
Annual real-estate tax Date annual real-estate tax was last updated Annual homeowner’s insurance premium Date annual homeowner’s insurance premium was
last updated
Slide 10..67
© The McGraw-Hill Companies, 2007
Reports Required for the Pilot Project
Three types of reports are needed:The results of the funds computation for the weekA listing of all investments (to be printed on request)A listing of all mortgages (to be printed on request)
Slide 10..68
© The McGraw-Hill Companies, 2007
10.10 Revising the Requirements: MSG Case Study
The initial requirements include three use cases: Estimate Funds Available for Week
Compute Weekly Repayment Amount
Manage an Investment
In the light of the additional information received,the initial requirements can be revised
Slide 10..69
© The McGraw-Hill Companies, 2007
Revising the Requirements: MSG (contd)
Consider each element of the formula to determinehow much money is available each week
(1) Estimated annual income from investments:Take all the investments, sum the estimated annual
return on each investment, and divide the result by 52
An additional use case, Estimate Investment Income forWeek, is needed(We still need use case Manage an Investment for adding,
deleting, and modifying investments)
Slide 10..70
© The McGraw-Hill Companies, 2007
The dashed line with the open arrowhead labeled«include» denotes thatUse case Estimate Investment Income for Week is part of
use case Estimate Funds Available for Week
Estimate Investment Income for WeekUse Case
Figure 10.14
Slide 10..71
© The McGraw-Hill Companies, 2007
Estimate Investment Income for WeekUse Case (contd)
Description of use case
Figure 10.15
Slide 10..72
© The McGraw-Hill Companies, 2007
First Iteration of the Revised Use-Case Diagram
New use case is shaded
Figure 10.16
Slide 10..73
© The McGraw-Hill Companies, 2007
Revising the Requirements: MSG Case Study (contd)
(2) Estimated annual operating expenses:
To determine the estimated annual operatingexpenses two additional use cases are neededUse case Update Estimated Annual Operating Expenses models
adjustments to the value of the estimated annualoperating expenses
Use case Estimate Operating Expenses for Week provides theneeded estimate of the operating expenses
Slide 10..74
© The McGraw-Hill Companies, 2007
Update Estimated Annual Operating ExpensesUse Case
Figure 10.18
Figure 10.17
Slide 10..75
© The McGraw-Hill Companies, 2007
Estimate Operating Expenses for WeekUse Case (contd)
Figure 10.20
Figure 10.19
Slide 10..76
© The McGraw-Hill Companies, 2007
Second Iteration of Revised Use-Case Diagram
The new use cases are shaded
Figure 10.21
Slide 10..77
© The McGraw-Hill Companies, 2007
Revising the Requirements: MSG (contd)
(3) Total estimated mortgage payments for theweek and
(4) Total estimated grant payments for the week:Use case Compute Weekly Repayment Amount models the
computation of both the estimated mortgage paymentand the estimated grant payment for each mortgageseparately
Summing these separate quantities gives The total estimated mortgage payments for the week, and The total estimated grant payments for the week
Slide 10..78
© The McGraw-Hill Companies, 2007
Revising the Requirements: MSG (contd)
Now the use cases need to be reorganizedUse case Compute Weekly Repayment Amount also models
borrowers updating their weekly income
Split Compute Weekly Repayment Amount into two separateuse casesUse case Estimate Payments and Grants for Week, andUse case Update Borrowers’ Weekly Income
Slide 10..79
© The McGraw-Hill Companies, 2007
Estimate Payments and Grants for WeekUse Case
Figure 10.22
Slide 10..80
© The McGraw-Hill Companies, 2007
Estimate Payments and Grants for Week Use Case (contd)
Figure 10.23
Slide 10..81
© The McGraw-Hill Companies, 2007
Update Borrowers’ Weekly IncomeUse Case
Figure 10.25
Figure 10.24
Slide 10..82
© The McGraw-Hill Companies, 2007
Third Iteration of the Revised Use-Case Diagram
The two new use cases are shaded
Figure 10.26
Slide 10..83
© The McGraw-Hill Companies, 2007
Estimate Funds Available for WeekUse Case
Use case Estimate Funds Available for Week models thecomputation that uses the data obtained fromthree other use cases Estimate Investment Income for Week
Estimate Operating Expenses for Week
Estimate Payments and Grants for Week
Slide 10..84
© The McGraw-Hill Companies, 2007
Estimate Funds Available for Week Use Case (contd)
Second iteration of use case
Figure 10.27
Slide 10..85
© The McGraw-Hill Companies, 2007
Estimate Funds Available for Week Use Case (contd)
Second iteration of description of use case
Figure 10.28
Slide 10..86
© The McGraw-Hill Companies, 2007
«include» Relationship
Correct use case (top); incorrect use case (bottom)
Figure 10.29
Slide 10..87
© The McGraw-Hill Companies, 2007
«include» Relationship (contd)
The bottom diagram models use cases Estimate Funds Available for Week, and Estimate Payments and Grants for Week
as two independent use casesHowever, a use case models an interaction between the
product itself and users of the product (actors)
Slide 10..88
© The McGraw-Hill Companies, 2007
«include» Relationship (contd)
Use case Estimate Payments and Grants for Week doesnot interact with an actor and therefore cannot bea use case in its own rightInstead, it is a portion of use case Estimate Funds
Available for Week, as reflected in the top diagram
Slide 10..89
© The McGraw-Hill Companies, 2007
10.11 The Test Workflow: MSG Case Study
A common side-effect of the iterative andincremental life-cycle modelDetails that correctly have been postponed somehow
get forgottenTwo instances of this are described on the next slide
Slide 10..90
© The McGraw-Hill Companies, 2007
The Test Workflow: MSG Case Study (contd)
Details of use case Manage an Investment have beenoverlooked, and
Use case Manage a Mortgage to modelThe addition of a new mortgageThe modification of an existing mortgage, orThe removal of an existing mortgage
has been totally forgotten(Analogous to use case Manage an Investment)
Slide 10..91
© The McGraw-Hill Companies, 2007
Manage an Investment Use Case
Figure 10.31
Figure 10.30
Slide 10..92
© The McGraw-Hill Companies, 2007
Manage a Mortgage Use Case
Figure 10.33
Figure 10.32
Slide 10..93
© The McGraw-Hill Companies, 2007
Fourth Iteration of the Revised Use-Case Diagram
The new use case is shaded
Figure 10.34
Slide 10..94
© The McGraw-Hill Companies, 2007
The Test Workflow: MSG Case Study (contd)
There is a further omissionUse case Produce a Report to print the three reports
Investments report Mortgages report Results of weekly computation
has also been totally forgotten
Slide 10..95
© The McGraw-Hill Companies, 2007
Produce a Report Use Case
Figure 10.35
Slide 10..96
© The McGraw-Hill Companies, 2007
Produce a Report Use Case (contd)
Figure 10.36
Slide 10..97
© The McGraw-Hill Companies, 2007
Fifth Iteration of the Revised Use-Case Diagram
The new use case, Produce a Report, is shaded
Figure 10.37
Slide 10..98
© The McGraw-Hill Companies, 2007
The Test Workflow: MSG Case Study (contd)
Rechecking the revised requirements uncoverstwo new problemsA use case has been partially duplicatedTwo of the use cases need to be reorganized
Slide 10..99
© The McGraw-Hill Companies, 2007
Partially Duplicated Use Case
Use case Manage a MortgageOne action is to modify a mortgage
Use case Update Borrowers’ Weekly IncomeOnly action is to update the borrowers’ weekly income
The borrowers’ weekly income is an attribute ofthe mortgageUse case Manage a Mortgage already includes use case
Update Borrowers’ Weekly Income
Accordingly, use case Update Borrowers’ Weekly Incomeis superfluous, and must be deleted
Slide 10..100
© The McGraw-Hill Companies, 2007
Sixth Iteration of the Revised Use-Case Diagram
The modified use case is shaded
Figure 10.38
Slide 10..101
© The McGraw-Hill Companies, 2007
The Test Workflow: MSG Case Study (contd)
This iteration resulted in a decrement, not anincrement
In fact, deletion occurs oftenWhenever we make a mistake
Sometimes we can fix an incorrect artifactMore frequently we have to delete an artifact
Slide 10..102
© The McGraw-Hill Companies, 2007
The Test Workflow: MSG Case Study (contd)
However, when we discover a fault, we do nothave to start the whole process from scratch
First we try to fix the current iteration
If the mistake is too serious for this to work, webacktrack to the previous iteration, and try to find abetter way to go forward from there
Slide 10..103
© The McGraw-Hill Companies, 2007
Reorganizing Two Use Cases
Determine the funds available for the current weekUse case Estimate Funds Available for Week models
performing the calculationStep 1.3 of use case Produce a Report models printing out
the result of the computation
There is no point in estimating the funds availableunless the results are printed out
Slide 10..104
© The McGraw-Hill Companies, 2007
Reorganizing Two Use Cases (contd)
The descriptions of the use cases Estimate Funds Available for Week, and Produce a Report
have to be modified (the use cases do not change)
Slide 10..105
© The McGraw-Hill Companies, 2007
Modified Description — Produce a Report
Figure 10.39
Slide 10..106
© The McGraw-Hill Companies, 2007
Modified Description — Estimate Funds Available for Week
Figure 10.40
Slide 10..107
© The McGraw-Hill Companies, 2007
The Test Workflow: MSG Case Study (contd)
The usual reason for an «include» relationship is whereone use case is part of two or more other use casesExample: U.S. tax forms—avoiding triplication
Figure 10.41
Slide 10..108
© The McGraw-Hill Companies, 2007
For the MSG Foundation case studyAll of the included use cases are part of only one use
case, Estimate Funds Available for Week
Incorporate those three «include» use cases into usecase Estimate Funds Available for WeekThe resulting use-case diagram is on the next slide
Estimate Funds Available for WeekUse Case (contd)
Slide 10..109
© The McGraw-Hill Companies, 2007
Seventh Iteration of Revised Use-Case Diagram
Figure 10.42
Slide 10..110
© The McGraw-Hill Companies, 2007
Estimate Funds Available for Week Revised Description of Use Case
Figure 10.43
Slide 10..111
© The McGraw-Hill Companies, 2007
The Test Workflow: MSG Case Study (contd)
Now the requirements appear to be correctThey correspond to what the client has requestedThey appear to satisfy the client’s needsThere do not seem to be any more faults
For now, everything seems to be fine
Slide 10..112
© The McGraw-Hill Companies, 2007
10.12 The Classical Requirements Phase
There is no such thing as “object-orientedrequirements”The requirements workflow has nothing to do with how
the product is to be built
However, the approach presented in this chapterisModel oriented, and thereforeObject oriented
Slide 10..113
© The McGraw-Hill Companies, 2007
The Classical Requirements Phase (contd)
The classical approach to requirements
Requirements elicitation
Requirements analysis
Construction of a rapid prototype
Client and future users experiment with the rapidprototype
Slide 10..114
© The McGraw-Hill Companies, 2007
10.13 Rapid Prototyping
Hastily built (“rapid”)Imperfections can be ignored
Exhibits only key functionality
Emphasis on only what the client seesError checking, file updating can be ignored
Aim:To provide the client with an understanding of the
product
Slide 10..115
© The McGraw-Hill Companies, 2007
Rapid Prototyping (contd)
A rapid prototype is built for changeLanguages for rapid prototyping include 4GLs and
interpreted languages
Slide 10..116
© The McGraw-Hill Companies, 2007
10.14 Human Factors
The client and intended users must interact withthe user interface
Human-computer interface (HCI)Menu, not command line“Point and click”Windows, icons, pull-down menus
Slide 10..117
© The McGraw-Hill Companies, 2007
Human Factors (contd)
Human factors must be taken into accountAvoid a lengthy sequence of menusAllow the expertise level of an interface to be modifiedUniformity of appearance is importantAdvanced psychology vs. common sense?
Rapid prototype of the HCI of every product isobligatory
Slide 10..118
© The McGraw-Hill Companies, 2007
10.15 Reusing the Rapid Prototype
Reusing a rapid prototype is essentially code-and-fix
Changes are made to a working productExpensive
Maintenance is hard without specification anddesign documents
Real-time constraints are hard to meet
Slide 10..119
© The McGraw-Hill Companies, 2007
Reusing the Rapid Prototype (contd)
One way to ensure that the rapid prototype isdiscardedImplement it in a different language from that of the
target product
Generated code can be reused
We can safely retain (parts of) a rapid prototype ifThis is prearrangedThose parts pass SQA inspectionsHowever, this is not “classical” rapid prototyping
Slide 10..120
© The McGraw-Hill Companies, 2007
10.16 CASE Tools for the Requirements Workflow
We need graphical tools for UML diagramsTo make it easy to change UML diagramsThe documentation is stored in the tool and therefore is
always available
Such tools are sometimes hard to use
The diagrams may need considerable “tweaking”
Overall, the strengths outweigh the weaknesses
Slide 10..121
© The McGraw-Hill Companies, 2007
CASE Tools for the Requirements Workflow (contd)
Graphical CASE environments extended tosupport UML includeSystem ArchitectSoftware through Pictures
Object-oriented CASE environments includeIBM Rational RoseTogetherArgoUML (open source)
Slide 10..122
© The McGraw-Hill Companies, 2007
10.17 Metrics for the Requirements Workflow
Volatility and speed of convergence are measuresof how rapidly the client’s needs are determined
Slide 10..123
© The McGraw-Hill Companies, 2007
Metrics for the Requirements Workflow (contd)
The number of changes made during subsequentphases
Changes initiated by the developersToo many changes can mean the process is flawed
Changes initiated by the clientMoving target problem
Slide 10..124
© The McGraw-Hill Companies, 2007
10.18 Challenges of the Requirements Phase
Employees of the client organization often feelthreatened by computerization
The requirements team members must be able tonegotiateThe client’s needs may have to be scaled down
Key employees of the client organization may nothave the time for essential in-depth discussions
Flexibility and objectivity are essential