Object-Oriented and

Classical Software
Engineering
Eighth Edition, WCB/McGraw-Hill, 2011
 CHAPTER 11

REQUIREMENTS
The Aim of the Requirements
Workflow
• To answer the question:

What must the product be able to do?

The objective is to determine what the client

needs and not what the client wants
 11.1 Determining What the
Client Needs
• Why is it difficult to determine what the
client needs?
– Many clients do not know what they need
– If they know, they have difficulty in accurately
conveying these ideas to the developers
– The client may not appreciate what is going on
in his or her own organisation
– It is hard for a systems analyst to visualize a
software product and its functionality
• The problem is far worse for the client
 Determining What the Client
Needs
• A skilled systems analyst is needed to elicit
the appropriate information from the client
• The client is the only source of this
information

• The solution:
– Obtain initial information from the client
– Use this initial information as input to the
requirements workflow of the Unified Process
– Follow the steps of the Unified Process to
determine the client’s real needs
 11.2 Overview of the
Requirements Workflow
• First, gain an understanding of the
application domain
– The specific environment in which the target
product is to operate
• Second, build a business model
– Model the client’s business processes using
UML
• Third, use the business model to determine
the initial set of the client’s requirements
• Iterate the above steps
 Overview of the
Requirements Workflow
• Overview
– Starting point is an initial understanding of the domain
– This information is used to build the initial business
model
– The initial business model is used to draw up an initial
set of client requirements
– Then a deeper understanding of the domain is gained
through learning about requirements
– This knowledge is used to refine the business model
and client requirements
– Iteration continues until team is satisfied with set of
requirements
 Overview of the Requirements
Workflow - Definitions
• Requirements elicitation or requirements
capture
– Discovering the client’s requirements

• Requirements analysis
– Refining and extending the initial
requirements
 11.3 Understanding the
Domain
• Every member of the development team must
become fully familiar with the application domain
– Cannot ask a neurosurgeon meaningful questions
without having some familiarity of neurosurgery
– Correct terminology is essential
• Creates correct impression
• Reduces the possibility of a misunderstanding
• Construct a glossary
– A list of technical words used in the domain, and their
meanings
– Gets updated whenever the members of the
requirements team encounter new terminology.
 11.4 The Business Model
• A business model is a description of the business
processes of an organization
– Example: Business processes of a bank include
accepting deposits from clients, loaning money to
clients and making investments
• 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
 11.4.1 Interviewing
• The requirements team meet with the client
and users to extract all relevant information

• There are two types of questions

– Close-ended questions require a specific
answer
– Open-ended questions are posed to encourage
the person being interviewed to speak out
 Interviewing
• 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
 Interviewing
• 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 and not make up his/her mind
regarding the client’s needs beforehand
• 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
 11.4.2 Other Techniques
• Interviewing is the primary technique for
obtaining information for the business model
• Questionnaire
– Useful when the opinions of hundreds of
individuals need to be determined
– Carefully written out answers may be more
accurate than an immediate verbal response
– An unstructured interview conducted by an
methodical interviewer usually yields far better
information
 Other Techniques
• Examination of business forms
– Shows how the client currently does business
– Can provide an idea of business processes
– User manuals of current software products
must be examined
– Client documentation is a valuable source of
information that can lead to accurate
assessment of client’s needs
 Other Techniques
• Direct observation of the employees while
they perform their duties
– Member of the requirement team observes and
writes down actions of the employees
– Videotape cameras are a modern version of this
technique (permission from person being video
taped must be obtained)
– But, it can take a long time to analyze the tapes
– Employees may view the cameras as an
unwarranted invasion of privacy
 11.4.3 Use Cases
(Gebruiksgeval)
• A model is a set of UML diagrams that
represent one or more aspects of the
software product to be developed
• A use case models an interaction between
the software product itself and the users of
that software product (actors)
 Use Cases (Gebruiksgeval)
• Example:

Figure 11.1

• Two actors: Teller and Customer

• The label inside the oval describes the
business activity, in this case, withdraw
money
 Use Cases
• An actor is a member of the world outside the
software product
• It is usually easy to identify an actor
– An actor is frequently a user of the software product
• In general, an actor plays a role with regard to
the software product. This role is
– As a user; or
– As an initiator; or
– As someone who plays a critical part in the use case
 Use Cases
• A user of the system can play more than
one role

• Example: A customer of the bank can be

– A Borrower (when he takes out a loan) or
– A Lender (when he deposits money in the
bank)
 Use Cases
• 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
 Use Cases
• An actor need not be a human being
• Example: An e-commerce 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 e-
commerce information system
– The e-commerce information system is an
actor from the viewpoint of the credit card
company information system
 Use Cases
• A potential problem when identifying
actors
– Overlapping actors

• Example: Hospital software product

– One use case has actor Nurse
– A different use case has actor Medical Staff
– Better:
• Actors: Physician and Nurse
 Use Cases Gebruiksgeval
• Alternatively:
– Actor Medical Staff with two specializations:
Physician and Nurse

Figure 11.2
 11.5 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
 Initial Requirements
• There are two categories of requirements
• A functional requirement specifies an action that
the software product must be able to perform
– Often expressed in terms of inputs and outputs
• A nonfunctional requirement specifies properties
of the software product itself, such as
– Platform constraints
– Response times
– Reliability
 Initial Requirements
• 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
11.6 Initial Understanding of the
Domain: MSG Case Study
• The MSG Foundation provides low cost
mortgage loans to young couples

• The trustees commission a pilot project

– A software product to determine how much
money is available each week to purchase
homes
 MSG Case Study

• A mortgage is a loan in which real estate

is used as security
• Example: House costs $100,000
• Buyer pays a 10% deposit and borrows
the balance
– The principal (or capital) borrowed is $90,000
• Loan is to be repaid monthly over 30 years
– Interest rate of 7.5% per annum (or 0.625%
per month)
 MSG Case Study
• Each month, the borrower pays $629.30
– Part of this is the interest on the outstanding
balance
– The rest is used to reduce the principal

• The monthly payment is therefore often

referred to as P & I (principal and interest)
 Mortgage Payments: First
Month
• In the first month the outstanding balance
is $90,000
– Monthly interest at 0.625% on $90,000 is
$562.50
– The 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
payment has been made, only $89,933.20
is owed to the finance company
 Mortgage Payments: Second
Month
• In the second month the outstanding balance is
$89,933.20
– Monthly interest at 0.625% on $89,933.20 is $562.08
– The 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 second
payment has been made, only $89,865.98 is
owed to the finance company
Mortgage Payments: After 15
and 30 Years
• After 15 years (180 months) the
outstanding balance is $67,881.61
– Monthly interest at 0.625% on $67,881.61 is
$424.26
– The 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 will have been repaid
 Insurance Premiums
• The finance company requires the
borrower to insure the house
– If the house burns down, the check from the
insurance company will then be used to repay
the loan
 Insurance Premiums
• The insurance premium is paid once a
year by the finance company
– The finance company requires the borrower to
pay monthly insurance installments
– These are deposited in an savings account

• The annual premium is then paid from the

savings account
 Real Estate Taxes
• Real-estate taxes paid on a home are
treated the same way as insurance
premiums
– Monthly installments are deposited in the
savings account
– The annual real-estate tax payment is made
from that account
 Borrowing Limits
• A mortgage will not be granted unless the
total monthly payment (P & I plus
insurance plus real-estate taxes) is less
than 28% of the borrower’s total income
 Other Costs
• The finance company requires a lump sum
up front in return for lending the money to
the borrower
– Typically, the finance company will want 2%
of the principal (“2 points”)
– For the $90,000 loan, this amounts to $1,800
 Other Costs
• There are other costs involved in buying a
house
– Legal costs
– Various taxes

• When the deal is “closed,” the closing

costs (legal costs, taxes, and so on) plus
the points can easily amount to $7,000
Initial Glossary

Figure 11.3
 11.7 Initial Business Model:
MSG Case Study
• At the start of each week, MSG estimates
how much money will be available that
week to fund mortgages

• Low-income couples can apply at any time

 Initial Business Model: MSG
Case Study
• An MSG Foundation staff member determines
– Whether the couple qualifies for an MSG mortgage,
and
– Whether MSG has sufficient funds on hand to
purchase the home
• If so, the mortgage is granted
– The weekly mortgage repayment is computed
according to MSG rules
• This repayment amount may vary from week to
week, depending on the couple’s current income
 Initial Business Model: MSG
Case Study
• There are three use cases (Gebruiksgeval)
– Estimate Funds Available for Week
– Apply for an MSG Mortgage
– Compute Weekly Repayment Amount
Estimate Funds Available for Week Use Case

Figure 11.4

Figure 11.7
Apply for an MSG Mortgage Use Case

Figure 11.5

Figure 11.8
Compute Weekly Repayment Amount Use Case

Figure 11.6

Figure 11.9
 Who Is an Actor?
• Why is Applicants an actor in use case
Apply for an MSG Mortgage?

• Applicants do not interact with the

software product
– Their answers are entered into the software
product by an MSG staff member
 Who Is an Actor?
• However,
– The applicants initiate the use case
– The applicants provide the data entered by
MSG staff
– The real actor is therefore Applicants — the
MSG Staff Member is merely an agent of the
applicants

• Applicants is therefore indeed an actor

 Who Is an Actor?
• Once the application has been granted,
the applicant becomes a borrower
• Similarly, Borrowers is an actor in use
case Compute Weekly Repayment Amount
– Again the use case is initiated by actor
Borrowers
– Again the information entered by MSG staff is
supplied by the borrowers
• Thus, Borrowers is indeed an actor in the
use case
 Manage an Investment Use Case

• Another aspect of the MSG Foundation

concerns the investments of the
foundation
• At this stage, no details are known
regarding
– The buying and selling of investments, or
– How investment income becomes available
for mortgages
• However, use case Manage an Investment is an
essential part of the initial business model
Manage an Investment Use Case

Figure 11.10

Figure 11.11
 Use-Case Diagram of the
Initial Business Model
The four use cases are
combined into a single
use case diagram

Next the initial

requirements have to
be drawn up

Figure 11.12
11.8 Initial Requirements: MSG Case
Study
• It is unclear if all four use cases are all
requirements of the product to be
developed
– What, exactly, is “a pilot project”?
– Recall what the client wants is “ a product that
will perform the calculations needed to
determine how much money is available each
week to purchase homes
• The best way to proceed is
– Draw up the initial requirements on the basis
of what the client wants, and then iterate
Initial Requirements: MSG Case
Study (contd)
• Consider each use case in turn:

• Estimate Funds Available for Week is obviously part

of the initial requirements

does not seem to have

• Apply for an MSG Mortgage

anything to do with the pilot project, so it is

excluded
Initial Requirements: MSG Case
Study (contd)
• , and
Compute Weekly Repayment Amount

• Manage an Investment

– Both appear to be irrelevant to the pilot project

• However, the pilot project deals with the “money
that is available each week to purchase homes”
– Some of that money comes from the weekly
repayment of existing mortgages, and from income
from investments
• The resulting use-case diagram is shown on the
next slide
 Initial Use-Case Diagram: MSG
Case Study

Figure 11.13

• The next step: Iterate the requirements workflow

• Interviews are conducted again
11.9 Continuing the Requirements Workflow: MSG
• The systems analysts learn that the MSG
Foundation grants a 100% mortgage to buy a
home under the following conditions:
– The couple has been legally married for at least 1
year but not more than 10 years
– Both husband and wife are gainfully employed
– The price of the home must be below the published
median price for homes in that area for the past 12
months
– Their income and/or savings are insufficient to afford
a standard fixed-rate 30-year 90% mortgage
– The foundation has sufficient funds to purchase the
home
Conditions for an MSG Mortgage
• If the application is approved, then each week
for the next 30 years the couple pays MSG
– The total of the principal and interest payment — this
never changes over the life of the mortgage; plus
– The escrow payment, which is 1/52nd of the sum of
the annual real-estate tax and the annual
homeowner’s insurance premium
• If this exceeds 28% of the couple’s gross weekly
income, MSG pays the difference as a grant
– The couple must provide proof of their current income
— the weekly payment may vary from week to week
 Algorithm to Determine If
Funds Are Available
• The following algorithm is used to determine
whether there is sufficient funds available
– (1) At the beginning of the week, the estimated
annual income from MSG investments is computed
and divided by 52
– (2) The estimated annual MSG operating expenses
are divided by 52
– (3) The total of the estimated mortgage payments for
the week is computed
 Algorithm to Determine If
Funds Are Available (contd)
– (4) The total of the estimated grants for the
week is computed
– (5) The amount available at the beginning of
the week 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
funds are invested
 Requirements of the Pilot
Project
• To keep the cost of the pilot project as low
as possible, only those data items needed
for the weekly funds computation will be
included
• Only three types of data are therefore
needed:
– Investment data
– Operating expenses data
– Mortgage data
 Investment Data
• With regard to investments, the following
data are required:
– Item number
– Item name
– Estimated annual return
– Date estimated annual return was last
updated
 Operating Expenses Data
• With regard to annual operating expenses,
the following data are required:
– Estimated annual operating expenses
– Date estimated annual operating expenses
was last updated
 Mortgage Data
• With regard to each mortgage, the following data are
required:
– 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
– 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
Reports Required for the Pilot
Project
• In the course of further discussions with
MSG managers, the developers learn that
three reports are required:
– The results of the funds computation for the
week
– A listing of all investments (to be printed on
request)
– A listing of all mortgages (to be printed on
request)
 11.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
Revising the Requirements: MSG
(contd)
• Consider each element of the formula to
determine how 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 for

Week, is needed

– (We still need use case Manage an Investment for adding,

deleting, and modifying investments)
 Estimate Investment Income for Week Use Case

Figure 11.14

 The dashed line with the open arrowhead labeled

«include» denotes that
Use case Estimate Investment Income for Week is part of
use case Estimate Funds Available for Week
Estimate Investment Income for Week Use Case

• Description of use case

Figure 11.15
 First Iteration of the Revised
Use-Case Diagram
• New use case is shaded

Figure 11.16
 Revising the Requirements: MSG Case Study
(contd)

• (2) Estimated annual operating expenses:

• To determine the estimated annual

operating expenses two additional use
cases are needed
– Use case Update Estimated Annual Operating Expenses
models adjustments to the value of the
estimated annual operating expenses
– Use case Estimate Operating Expenses for Week
provides the needed estimate of the operating
expenses
Update Estimated Annual Operating Expenses Use Case

Figure 11.17

Figure 11.18
Estimate Operating Expenses for Week Use Case (contd)

Figure 11.19

Figure 11.20
 Second Iteration of Revised Use-Case
Diagram
• The new use cases are shaded

Figure 11.21
Revising the Requirements: MSG
(contd)
• (3) Total estimated mortgage payments for the
week and

• (4) Total estimated grant payments for the week:

– Use case Compute Weekly Repayment Amount models the
computation of both the estimated mortgage payment
and the estimated grant payment for each mortgage
separately
– Summing these separate quantities gives
• The total estimated mortgage payments for the week, and
• The total estimated grant payments for the week
Revising the Requirements: MSG
(contd)
• Now the use cases need to be
reorganized
– Use case Compute Weekly Repayment Amount also
models borrowers updating their weekly
income
• Split Compute Weekly Repayment Amount into two
separate use cases
– Use case Estimate Payments and Grants for Week,
and
– Use case Update Borrowers’ Weekly Income
Estimate Payments and Grants for Week Use Case

Figure 11.22
Estimate Payments and Grants for Week Use Case
(contd)

Figure 11.23
Update Borrowers’ Weekly Income Use Case

Figure 11.24

Figure 11.25
 Third Iteration of the Revised Use-Case
Diagram
• The two new use cases are shaded

Figure 11.26
 Estimate Funds Available for Week Use Case

• Use case Estimate Funds Available for Week

models the computation that uses the data
obtained from three other use cases
– Estimate Investment Income for Week
– Estimate Operating Expenses for Week
– Estimate Payments and Grants for Week
Estimate Funds Available for Week Use Case
(contd)
• Second iteration of use case

Figure 11.27
Estimate Funds Available for Week Use Case
(contd)

• Second iteration of description of use case

Figure 11.28
 «include» Relationship
• Correct use case (top); incorrect use case (bottom)

Figure 11.29
 «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 cases

– However, a use case models an interaction
between the product itself and users of the
product (actors)
 «include» Relationship (contd)
• Use case Estimate Payments and Grants for Week
does not interact with an actor and
therefore cannot be a use case in its own
right
– Instead, it is a portion of use case Estimate
Funds Available for Week, as reflected in the top
diagram
 11.11 The Test Workflow: MSG Case Study

• A common side-effect of the iterative and

incremental life-cycle model
– Details that correctly have been postponed
somehow get forgotten
– Two instances of this are described on the
next slide
 The Test Workflow: MSG Case Study (contd)

• Details of use case Manage an Investment have

been overlooked, and
• Use case Manage a Mortgage to model
– The addition of a new mortgage
– The modification of an existing mortgage, or
– The removal of an existing mortgage
has been totally forgotten
(Analogous to use case Manage an Investment )
Manage an Investment Use Case

Figure 11.30

Figure 11.31
Fourth Iteration of the Revised Use-Case Diagram

• The new use case is shaded

Figure 11.34
The Test Workflow: MSG Case Study
(contd)
• There is a further omission
– Use case Produce a Report to print the three
reports
• Investments report
• Mortgages report
• Results of weekly computation
has also been totally forgotten
Produce a Report Use Case

Figure 11.35
Produce a Report Use Case (contd)

Figure 11.36
 Fifth Iteration of the Revised
Use-Case Diagram
• The new use case, Produce a Report , is shaded

Figure 11.37
The Test Workflow: MSG Case Study
(contd)
• Rechecking the revised requirements
uncovers two new problems
– A use case has been partially duplicated
– Two of the use cases need to be reorganized
Partially Duplicated Use Case
• Use case Manage a Mortgage

– One action is to modify a mortgage

• Use case Update Borrowers’ Weekly Income

– Only action is to update the borrowers’ weekly income

• The borrowers’ weekly income is an attribute of
the mortgage
– Use case Manage a Mortgage already includes use case
Update Borrowers’ Weekly Income

• Accordingly, use case Update Borrowers’ Weekly Income

is superfluous, and must be deleted

 Sixth Iteration of the Revised
Use-Case Diagram
• The modified use case is shaded

Figure 11.38
The Test Workflow: MSG Case Study
(contd)
• This iteration resulted in a decrement, not
an increment

• In fact, deletion occurs often

– Whenever we make a mistake

• Sometimes we can fix an incorrect artifact

– More frequently we have to delete an artifact
The Test Workflow: MSG Case Study
(contd)
• However, when we discover a fault, we do
not have 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, we backtrack to the previous
iteration, and try to find a better way to go
forward from there
 Reorganizing Two Use Cases

• Determine the funds available for the

current week
– Use case Estimate Funds Available for Week models
performing the calculation
– Step 1.3 of use case Produce a Report models
printing out the result of the computation
• There is no point in estimating the funds
available unless the results are printed out
 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)
Modified Description — Produce a Report

Figure 11.39
Modified Description — Estimate Funds Available for Week

Figure 11.40
 The Test Workflow: MSG Case Study
(contd)
• The usual reason for an «include» relationship is where
one use case is part of two or more other use cases
– Example: U.S. tax forms—avoiding triplication

Figure 11.41
 Estimate Funds Available for Week Use Case
(contd)

• For the MSG Foundation case study

– All of the included use cases are part of only one
use case, Estimate Funds Available for Week

• Incorporate those three «include» use cases into

use case Estimate Funds Available for Week
– The resulting use-case diagram is on the next
slide
Seventh Iteration of Revised
Use-Case Diagram

Figure 11.42
Estimate Funds Available for Week Revised Description of Use Case

Figure 11.43
The Test Workflow: MSG Case Study
(contd)
• Now the requirements appear to be
correct
– They correspond to what the client has
requested
– They appear to satisfy the client’s needs
– There do not seem to be any more faults

• For now, everything seems to be fine

 11.12 The Classical Requirements
Phase
• There is no such thing as “object-oriented
requirements”
– The requirements workflow has nothing to do
with how the product is to be built

• However, the approach presented in this

chapter is
– Model oriented, and therefore
– Object oriented
 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

rapid prototype
 11.13 Rapid Prototyping
• Rapid prototype
– Hastily built software that exhibits the key functionality
of the target product
– Reflects the functionality the client sees (e.g. Input
screens and reports), but omits “hidden” aspects such
as file updating
• Client and intended users of the product experiment
with rapid prototype, while members of the
development team watch and take notes
• Users tell the developers how the rapid prototype
satisfies their needs and identify the areas that need
improvement.
• Developers make the necessary changes until both
sides are convinced that the needs of the client are
accurately encapsulated in the rapid prototype.
 11.14 Human factors
• Read through section 11.14.
 11.15 Reusing the Rapid
Prototype
• After the rapid prototype has been built to test the user
interface, it is discarded.
• An alternative is to develop and refine the prototype until it
becomes the complete product.
• This is generally unwise, because
– It is similar to the code-and-fix model and will exhibit the
following problems
• In course of refining the product, changes have to be made to a
working product. This is an expensive way to proceed.
• It is hurriedly put together, rather than carefully specified, designed
and implemented. The resulting code is difficult and expensive to
maintain.
• There is one circumstance when it is permissible to refine a
rapid prototype
– When portions of the rapid prototype of the user interface are
computer generated, those portions may be used in the final
product.
11.16 CASE Tools for the Requirements
Workflow
• Read through section 11.16.
 11.17 Metrics for the
Requirements Workflow
• Requirements volatility
– Keeping a record of how frequently the requirements change
during the requirements workflow
– Gives management a way of determining the rate at which
the requirements team converges on the actual requirements
of the product.
• Number of requirements that change during the rest of
the software development process. Determine if
changes are initiated by client or the developers.
– If initiated by developers during analysis, design and
subsequent workflows, then the process used by the team to
carry out the requirements workflow should be thoroughly
reviewed.
– If client makes repeated changes to the requirements during
subsequent workflows, the metric can be used to warn the
client that the moving-target problem can adversely affect the
product.
 11.18 Challenges of the Requirements
Phase
• Employees of the client organization often
feel threatened by computerization
• The requirements team members must be
able to negotiate
– The client’s needs may have to be scaled down
• Key employees of the client organization
may not have the time for essential in-depth
discussions
• Flexibility and objectivity are essential for
requirements elicitation.