Software_Requirements

Symptoms Possible root causes Possible solutions
■ Conflicting requirements priorities
■ Different user classes have ■ Perform sufficient market research.
among stakeholders.
conflicting needs. ■ Establish and communicate
■ Rapid descoping late in the
project. ■ Lack of focus on the original business objectives.

■ Developers find requirements product vision, or the vision ■ Base priorities on vision, scope,
vague and ambiguous. evolves during the project. and business objectives.

■ Developers have to track down ■ Unclear business objectives, or ■ Identify favored user classes or
missing information. lack of agreement on business market segments.
objectives.
■ Developers misunderstand ■ Identify product champions to
requirements and have to rework ■ Changing business objectives. represent different user classes.
their implementations.
■ It’s not clear who the requirements ■ Identify and empower
■ Some requirements aren’t decision makers are.
technically feasible. requirements decision makers.

■ Unrealistic optimism about ■ Define priorities early on.
developer productivity.
■ Use priorities to guide decisions
■ Insufficient early and ongoing about what to work on now and
prioritization. what to defer.

■ Not relying on priorities to define ■ Reprioritize when new
implementation sequence and to requirements are incorporated.
make controlled scope changes.
■ Adjust scope periodically, not just
late in the project.

■ Use incremental development or
staged releases to stay focused on
delivering customer value.

■ BAs and customers don’t ■ Train BAs in writing good
understand the level of requirements.
requirements detail developers
need. ■ Avoid using subjective,
ambiguous words in requirements
■ Customers don’t know what they specifications.
need or can’t articulate it clearly.
■ Have developers and customers
■ Insufficient time is spent on review requirements early for
elicitation. clarity and appropriate detail.

■ Business rules aren’t identified, ■ Model requirements to find
communicated, or understood. missing information and enhance
details.
■ Requirements contain vague and
ambiguous words. ■ Build prototypes and have users
evaluate them.
■ Stakeholders interpret terms,
concepts, and data definitions ■ Refine requirements in progressive
differently. levels of detail.

■ Customers assume that developers ■ Document business rules.

already know enough about the ■ Define terms in a glossary.
business domain and their needs. ■ Define data items in a data

dictionary.

■ Facilitate effective communication
among all project participants.

■ Requirements are not analyzed ■ Perform feasibility analysis.
sufficiently.
■ Create proof-of-concept
■ Customers don’t accept feasibility prototypes.
analysis results.
■ Have a developer participate in
■ Lack of understanding of the elicitation.
limitations of tools, technologies,
and the operating environment. ■ Have developers review
requirements for feasibility.

■ Conduct a separate research or
exploratory mini-project or pilot
to assess feasibility.

568 APPENDIX B Requirements troubleshooting guide

Symptoms Possible root causes Possible solutions
■ Requirements from different
■ Lack of shared product vision. ■ Develop, approve, and
sources or user classes conflict. ■ Requirements decision makers are communicate a unified set of
■ Difficulty in reaching agreement business requirements.
not identified.
on requirements among ■ Business processes are not ■ Understand target market
stakeholders. segments and user classes.
understood in the same way by
■ Requirements contain TBDs, different stakeholders. ■ Identify favored user classes to
information gaps, and open issues. ■ Politics drive requirements input. resolve conflicts.
■ Diverse users or market segments
■ BAs spend too much time on have differing needs, expectations, ■ Identify product champions to
requirements analysis. and objectives. resolve conflicts within each user
■ Product isn’t sufficiently focused class.
on a specific target market.
■ Some user groups already have a ■ Identify and empower
useful system in place that they’re requirements decision makers.
attached to.
■ Focus on shared business interests
■ No one is assigned to resolve instead of emotional and political
TBDs or open issues before positions.
requirements are baselined.
■ Review requirements to identify
■ No time is available to resolve information gaps.
TBDs or open issues before
beginning implementation. ■ Assign responsibility for resolving
each TBD or open issue to an
■ Reluctance to proceed until individual.
the requirements are “perfect”
(analysis paralysis). ■ Prioritize TBDs to be resolved if
time is tight.
■ An intent to develop a complete
specification rather than one that ■ Track each TBD or open issue to
is good enough. closure before baselining a set of
requirements.
■ Inappropriate selection of analysis
techniques for the project. ■ Focus analysis and modeling on
the complex, novel, or uncertain
portions of the requirements.

■ Use peer reviews to judge when
requirements are good enough
for development to proceed at
acceptable risk.

Specification issues

The symptoms in the following table indicate shortcomings in the way that requirements are being
specified for the project.

Symptoms Possible root causes Possible solutions

■ Requirements are not ■ No one is sure what to build. ■ Point out risks of inadequately
documented. specified requirements.
■ Insufficient time is provided to
■ Developers create the elicit and document requirements. ■ Define and follow a requirements
requirements. development process.
■ There’s a perception that writing
■ Customers provide requirements requirements slows down the ■ Establish team role definitions,
details to developers verbally. project. and obtain commitment from
individuals to perform their roles.
■ Developers do a lot of exploratory ■ Individuals responsible for
programming as they try to figure specification aren’t clearly ■ Train other team members and
out what customers want. identified and committed. customers in the requirements
process.
■ No defined requirements
development process or templates ■ Build requirements effort,
in place. resources, tasks, and deliverables
into project plans and schedules.
■ Development management
doesn’t value and expect ■ Have standard templates and
requirements specifications. good examples of requirements
specifications available to share.
■ Developers think they know what
customers need.

APPENDIX B Requirements troubleshooting guide 569

Symptoms Possible root causes Possible solutions
■ Stakeholders assume that ■ Requirements for a new system are
■ Reverse engineer the existing
functionality in the existing system specified as deltas from a poorly system to understand its full
will be replicated in a new system. documented existing system. capabilities.
■ Business objectives aren’t clear.
■ Requirements documentation ■ Write a requirements specification
doesn’t accurately describe the ■ Changes made during that includes all the desired
system. development are not incorporated functionality for the new system.
into requirements documentation.
■ Different, conflicting versions of ■ Build as-is and to-be process
the requirements exist. ■ Poor version control practices. models so that stakeholders are
■ Multiple “master” copies of clear on what the future system
will and won’t do.
requirements documents.
■ Requirements are maintained ■ Don’t replicate old functionality
that might not be needed.
separately in a tool and in
documents; people aren’t sure ■ Follow a change control
which is the definitive source. process that includes updating
requirements when changes are
accepted.

■ Pass all change requests through
the change control board.

■ Have key stakeholders review
modified requirements.

■ Define and follow good version
control practices for requirements
documents.

■ Store requirements in a
requirements management tool.

■ Assign a requirements manager to
be responsible for making changes
to requirements.

Validation issues

It’s difficult to know for sure if the requirements you’ve developed will in fact achieve the intended
business objectives. The symptoms in this section are indicative of requirements validation
shortcomings.

Symptoms Possible root causes Possible solutions

■ Product doesn’t achieve ■ Customers didn’t accurately ■ Perform market research to
business objectives or meet user
expectations. present their needs. understand market segments and

■ Customers have unstated, ■ Market or business needs changed their needs.
assumed, or implicit requirements
that weren’t satisfied. and mechanisms were not in place ■ Engage product champions

to revise requirements accordingly. representing each user class

■ The BA didn’t ask the right throughout the duration of the
questions. project.

■ Inadequate customer participation ■ Train BAs in how to elicit
requirements.
in requirements development.

■ Wrong customer representatives ■ Develop use cases to make sure
involved, such as surrogates who business tasks are understood.

don’t represent the real users’ real ■ Have customers participate in

needs. requirements reviews.

■ Market needs were not accurately ■ Build prototypes and have users
assessed, especially for innovative evaluate them.
products with uncertain
requirements. ■ Have users write acceptance tests
and acceptance criteria.
■ Project participants made
incorrect assumptions. ■ Establish effective change
mechanisms to allow requirements
to adapt to business realities.

570 APPENDIX B Requirements troubleshooting guide

Symptoms Possible root causes Possible solutions

■ Product does not achieve ■ Quality attribute requirements ■ Educate BAs and customers about
performance goals or satisfy other were not elicited and specified. nonfunctional requirements and
quality expectations that users how to specify them.
have. ■ Stakeholders don’t understand
nonfunctional requirements and ■ Have BAs explore nonfunctional
their importance. requirements during elicitation.

■ The requirements template or tool ■ Use an SRS template that includes

being used doesn’t have sections sections for nonfunctional

for nonfunctional requirements. requirements.

■ Users don’t state their assumptions ■ Use Planguage to specify quality

about the system’s quality attributes precisely.

characteristics.

■ Quality attributes weren’t
specified precisely enough to
give all stakeholders the same
understanding.

Requirements management issues

One sign that requirements are not being managed well is that not all of the intended requirements
are implemented.

Symptoms Possible root causes Possible solutions

■ Some planned requirements were ■ SRS was not well organized or well ■ Keep requirements current and
not implemented.
written. make them available to the whole

■ Individual requirements were not team.

discretely identified and labeled. ■ Make sure the change control

■ Developers didn’t follow the SRS. process includes communication
to stakeholders.
■ SRS was not communicated to
everyone. ■ Store requirements in a
requirements management tool.
■ Changes were not communicated
to all those affected. ■ Track the status of individual
requirements.
■ Requirements were
inadvertently overlooked during ■ Create and use a requirements
implementation. traceability matrix.

■ Responsibilities for implementing ■ Define clear responsibilities for
requirements were not assigned. software construction.

■ The status of individual ■ Train BAs in writing clear, concise
requirements was not tracked requirements.

accurately.

APPENDIX B Requirements troubleshooting guide 571

Change management issues

There are many indicators that a software project is not handling change requests well, several of
which are itemized in the following table.

Symptoms Possible root causes Possible solutions
■ Requirements change frequently.
■ Many requirements changes are ■ Customers aren’t sure what they ■ Improve requirements elicitation
need. practices.
made late in the development
cycle. ■ Changing business processes or ■ Implement and follow a change
■ Changes cause missed delivery market demands. control process.
targets.
■ Not all the right people were ■ Establish a change control board
■ New requirements are added involved in eliciting and approving to make decisions on proposed
frequently. the requirements. changes.

■ Increased scope causes missed ■ Requirements weren’t adequately ■ Perform impact analysis before
delivery targets. defined initially. accepting changes.

■ Requirements baseline wasn’t ■ Have stakeholders review
defined or agreed to. requirements before baselining
them.
■ External sources, such as the
government or political issues, ■ Design software for high
dictate changes. modifiability to accommodate
change.
■ The initial requirements contained
many solution ideas, which did not ■ Include contingency buffers in the
satisfy the real needs. project schedule to accommodate
some change.
■ Market needs weren’t well
understood. ■ Use incremental development
approaches to respond quickly to
■ Requirements elicitation was changing requirements.
incomplete.
■ Protect the schedule and
■ Insufficient customer participation negotiate to deliver reduced
in requirements development. scope, planning a follow-on
release.
■ Business needs or environment are
changing rapidly. ■ Improve requirements elicitation
practices.
■ Business domain is not well
understood. ■ Define and communicate scope.

■ Stakeholders don’t understand or ■ Have the right people make
respect project scope. explicit business decisions to
change scope.
■ Management, marketing, or
customers demand new features ■ Perform root cause analysis to see
without considering their impact where new requirements come
on the project. from and why.

■ Perform change impact
analysis before accepting new
requirements.

■ Ensure that all user classes have
provided input.

■ Include contingency buffers in the
project schedule to accommodate
some growth.

■ Use incremental development
approaches to respond quickly to
new requirements.

572 APPENDIX B Requirements troubleshooting guide

Symptoms Possible root causes Possible solutions
■ Requirements move in and out of
■ Vision and scope are not clearly ■ Clearly define the business
scope. defined. objectives, vision, and scope.

■ Scope definition changes after ■ Business objectives are not clearly ■ Use the scope statement to decide
development is underway. understood and communicated. whether proposed requirements
are in or out of scope.
■ People don’t know the scope or ■ Scope is volatile, perhaps in
understand scope changes. response to changing market ■ Record the rationale for rejecting a
demands. proposed requirement.
■ Proposed requirements changes
are lost. ■ Requirements priorities are poorly ■ Ensure that the change control
defined. board has the appropriate
■ The status of each change request members and a shared
isn’t known. ■ Decision makers don’t agree on understanding of project scope.
project scope.
■ Use incremental development to
■ Poorly defined, poorly adapt flexibly to a changing scope
understood, or changing business boundary.
objectives.
■ Focus on implementing the stable
■ Market segments and market requirements.
needs aren’t well understood.
■ Define business objectives and
■ Competing products become align vision and scope with them.
available.
■ Identify decision-making
■ Key stakeholders did not review stakeholders at the business
and approve requirements. requirements level.

■ Changes in key stakeholders ■ Have decision makers review the
partway through the project. vision and scope document.

■ Requirements changes aren’t ■ Follow a change control process to
communicated to all affected incorporate changes.
stakeholders.
■ Renegotiate schedules, resources,
■ Requirements specifications aren’t and commitments when project
updated when requirements direction changes.
change.
■ Define an owner for each
■ Customers request changes requirement.
directly from developers.
■ Define trace links between
■ Not everyone has ready access to requirements and other artifacts.
the requirements documentation.
■ Include all affected areas in
■ Informal communication pathways requirements communications.
exclude some project participants.
■ Establish a change control process
■ It’s not clear who needs to be that includes the communication
informed of changes. mechanisms.

■ No established change control ■ Handle all requirements changes
process. through the change control
process.
■ Lack of understanding of
interrelationships between ■ Use a requirements management
requirements. tool to make current requirements
available to stakeholders.
■ Ineffective or undefined change
control process. ■ Improve collaboration and
communication among
■ Change control process isn’t project participants and other
followed. stakeholders.

■ Adopt a practical, effective change
control process and educate
stakeholders about it.

■ Assign responsibilities for
performing the change control
process steps.

■ Ensure that the change control
process is followed.

■ Use requirements management
tools to track changes and track
each requirement’s status.

APPENDIX B Requirements troubleshooting guide 573

Symptoms Possible root causes Possible solutions
■ Stakeholders bypass the change
■ Change control process isn’t ■ Ensure that the change control
control process. practical and effective. process is pragmatic, effective,
■ Customers request changes efficient, and accessible to all
■ Change control board is stakeholders.
directly from developers. ineffective.
■ Make the change control process
■ Requirements changes take much ■ Stakeholders don’t understand or flexible in how it handles small
more effort than planned. accept the change control process. versus large changes.

■ Changes affect more system ■ Management doesn’t require that ■ Establish and charter an
components than expected. the change control process be appropriate change control board.
followed.
■ Changes conflict with other ■ Enlist management to commit to
requirements. ■ Insufficient impact analysis of and champion the change control
proposed requirements changes. process.
■ Changes degrade system quality.
■ Developers underestimate the ■ Enforce a policy that requirements
impact of requirements changes. changes are made only through
the change control process.
■ The wrong people make decisions
to accept changes. ■ Adopt a change impact analysis
procedure and checklist.
■ Team members are afraid to
be honest about the impact of ■ Incorporate impact analysis into
proposed changes. the change control process.

■ Change requests do not provide ■ Use requirements trace
enough information to permit information to evaluate the impact
good impact analysis. of proposed changes.

■ Communicate changes to all
affected stakeholders.

■ Renegotiate project commitments
as needed and make necessary
trade-offs when changes are
proposed.

574 APPENDIX B Requirements troubleshooting guide

APPENDIX C

Sample requirements documents

This appendix illustrates some of the requirements documents and diagrams described in this book,
using a hypothetical project called the Cafeteria Ordering System (COS). This appendix includes:

■ A vision and scope document.
■ A list of use cases and several use case specifications, showing different degrees of detail.
■ A portion of a software requirements specification.
■ Several partial analysis models, including a feature tree, context diagram, entity-relationship

diagram, and state-transition diagram.
■ A partial data dictionary.
■ Several business rules.
Because this is just an example, these deliverables aren’t intended to be complete. Instead, they
are meant to illustrate how the various types of requirements information relate to each other and
how you might write the contents of each document section. The information in these examples
could be organized and grouped in many other reasonable ways, including combining it into a single
document on a small project or storing it in a requirements management tool. Clarity, completeness,
and usability of the requirements information are the essential objectives. The examples conform to
the templates described in previous chapters. Because this is a small project, some template sections
have been combined. Every project should consider how to adapt the organization’s standard
templates to best suit the size and nature of the project.

575

Vision and Scope Document

1. Business Requirements

1.1 Background

Employees at the company Process Impact presently spend an average of 65 minutes per day going
to the cafeteria to select, purchase, and eat lunch. About 20 minutes of this time is spent walking to
and from the cafeteria, selecting their meals, and paying by cash or credit card. When employees go
out for lunch, they spend an average of 90 minutes off-site. Some employees phone the cafeteria in
advance to order a meal to be ready for them to pick up. Employees don’t always get the selections
they want because the cafeteria runs out of certain items. The cafeteria wastes a significant quantity
of food that is not purchased and must be thrown away. These same issues apply to breakfast and
supper, although far fewer employees use the cafeteria for those meals than for lunch.

1.2 Business Opportunity

Many employees have requested a system that would permit a cafeteria user to order meals (defined
as a set of one or more food items selected from the cafeteria menu) online, to be picked up at the
cafeteria or delivered to a company location at a specified time and date. Such a system would save
employees time, and it would increase their chance of getting the items they prefer. Knowing what
food items customers want in advance would reduce waste in the cafeteria and would improve the
efficiency of cafeteria staff. The future ability for employees to order meals for delivery from local
restaurants would make a wide range of choices available to employees and provide the possibility of
cost savings through volume discount agreements with the restaurants.

1.3 Business Objectives

BO-1: Reduce the cost of cafeteria food wastage by 40% within 6 months following initial release.
[This example shows the use of Planguage to precisely state a business objective.]

Scale: Cost of food thrown away each week by cafeteria staff

Meter: Examination of Cafeteria Inventory System logs

Past: 33% (2013, initial study)

Goal: Less than 20%

Stretch: Less than 15%

BO-2: Reduce cafeteria operating costs by 15% within 12 months following initial release.

BO-3: Increase average effective work time by 15 minutes per cafeteria-using employee per day
within 6 months following initial release.

576 APPENDIX C Sample requirements documents

1.4 Success Metrics

SM-1: 75% of employees who used the cafeteria at least 3 times per week during Q3 2013 use the
COS at least once a week within 6 months following initial release.

SM-2: The average rating on the quarterly cafeteria satisfaction survey increases by 0.5 on a scale of
1 to 6 from the Q3 2013 rating within 3 months following initial release and by 1.0 within 12 months.

1.5 Vision Statement

For employees who want to order meals from the company cafeteria or from local restaurants online,
the Cafeteria Ordering System is an Internet-based and smartphone-enabled application that will
accept individual or group meal orders, process payments, and trigger delivery of the prepared meals
to a designated location on the Process Impact campus. Unlike the current telephone and manual
ordering processes, employees who use the Cafeteria Ordering System will not have to go to the
cafeteria to get their meals, which will save them time and will increase the food choices available to
them.

1.6 Business Risks

RI-1: The Cafeteria Employees Union might require that their contract be renegotiated to reflect the
new employee roles and cafeteria hours of operation. (Probability = 0.6; Impact = 3)

RI-2: Too few employees might use the system, reducing the return on investment from the system
development and the changes in cafeteria operating procedures. (Probability = 0.3; Impact = 9)

RI-3: Local restaurants might not agree to offer delivery, which would reduce employee satisfaction
with the system and possibly their usage of it. (Probability = 0.3; Impact = 3)

RI-4: Sufficient delivery capacity might not be available, which means that employees might not
always receive their meals on time and could not always request delivery for the desired times.
(Probability = 0.5; Impact = 6)

1.7 Business Assumptions and Dependencies

AS-1: Systems with appropriate user interfaces will be available for cafeteria employees to process the
expected volume of meals ordered.

AS-2: Cafeteria staff and vehicles will be available to deliver all meals for specified delivery time slots
within 15 minutes of the requested delivery time.

DE-1: If a restaurant has its own online ordering system, the Cafeteria Ordering System must be able
to communicate with it bidirectionally.

APPENDIX C Sample requirements documents 577

2. Scope and Limitations

2.1 Major Features

FE-1: Order and pay for meals from the cafeteria menu to be picked up or delivered.
FE-2: Order and pay for meals from local restaurants to be delivered.
FE-3: Create, view, modify, and cancel meal subscriptions for standing or recurring meal orders, or for
daily special meals.
FE-4: Create, view, modify, delete, and archive cafeteria menus.
FE-5: View ingredient lists and nutritional information for cafeteria menu items.
FE-6: Provide system access through corporate intranet, smartphone, tablet, and outside Internet
access by authorized employees.

FIGURE C-1 Partial feature tree for the Cafeteria Ordering System.

578 APPENDIX C Sample requirements documents

2.2 Scope of Initial and Subsequent Releases

Feature Release 1 Release 2 Release 3
FE-1, Order from cafeteria Standard meals from lunch Accept credit and debit Accept meal orders for
menu only; meal orders for card payments breakfasts and suppers
FE-2, Order from delivery can be paid for by
restaurants payroll deduction only Delivery to campus Fully implemented
FE-3, Meal subscriptions Not implemented locations only Fully implemented
Implemented if time
FE-4, Menus Not implemented permits Windows Phone and tablet
Modify, delete, and archive apps
FE-5, Ingredient lists Create and view menus menus
FE-6, System access Fully implemented
Not implemented iOS and Android phone
Intranet and outside and tablet apps
Internet access

2.3 Limitations and Exclusions

LI-1: Some food items that are available from the cafeteria will not be suitable for delivery, so the
delivery menus available to patrons of the COS must be a subset of the full cafeteria menus.

LI-2: The COS shall be used only for the cafeteria at the Process Impact campus in Clackamas, Oregon.

3. Business Context

3.1 Stakeholder Profiles

Stakeholder Major value Attitudes Major interests Constraints
Corporate None identified
Management Improved employee Strong commitment Cost and employee
productivity; cost through release 2; time savings must Training for staff
Cafeteria Staff savings for cafeteria support for release 3 exceed development in Internet usage
contingent on earlier and usage costs needed; delivery staff
results and vehicles needed
Job preservation
More efficient use of Concern about union
staff time throughout relationships and
the day; higher possible downsizing;
customer satisfaction otherwise receptive

Patrons Better food selection; Strong enthusiasm, Simplicity of use; Corporate intranet
Payroll Department time savings; but might not use it reliability of delivery; access, Internet
convenience as much as expected availability of food access, or a mobile
because of social choices device is needed
No benefit; value of eating
needs to set up lunches in cafeteria Minimal changes No resources yet
payroll deduction and restaurants in current payroll committed to make
registration scheme applications software changes
Not happy about
the software
work needed, but
recognizes the value
to the company and
employees

APPENDIX C Sample requirements documents 579

Stakeholder Major value Attitudes Major interests Constraints
Restaurant Managers
Increased sales; Receptive but Minimal new Might not have
marketing exposure cautious technology needed; capacity to handle
to generate new concern about order levels; might
customers resources and costs not all have menus
of delivering meals online

3.2 Project Priorities

Dimension Constraint Driver Degree of freedom
Features
All features scheduled for Team size is half-time project Release 1 planned to be
Quality release 1.0 must be fully manager, half-time BA, 3 available by end of Q1 of
operational developers, and 1 tester; next year, release 2 by end of
Schedule additional developer and Q2; overrun of up to 2 weeks
95% of user acceptance tests half-time tester available if acceptable without sponsor
must pass; all security tests necessary review
must pass Budget overrun up to 15%
acceptable without sponsor
Cost review
Staff

3.3 Deployment Considerations

The web server software will need to be upgraded to the latest version. Apps will have to be
developed for iOS and Android smartphones and tablets as part of the second release, with
corresponding apps for Windows Phone and tablets to follow for the third release. Any corresponding
infrastructure changes must be in place at the time of the second release. Videos no more than five
minutes in length shall be developed to train users in both the Internet-based and app-based versions
of COS.

580 APPENDIX C Sample requirements documents

Use Cases

The various user classes identified the following primary actors and use cases for the COS:

Primary actor Use cases
Patron
1. Order a Meal
Menu Manager 2. Change Meal Order
Cafeteria Staff 3. Cancel Meal Order
Meal Deliverer 4. View Menu
5. Register for Payroll Deduction
6. Unregister for Payroll Deduction
7. Manage Meal Subscription

8. Create a Menu
9. Modify a Menu
10. Delete a Menu
11. Archive Menus
12. Define a Meal Special

13. Prepare Meal
14. Generate a Payment Request
15. Request Meal Delivery
16. Generate System Usage Reports

17. Record Meal Delivery
18. Print Delivery Instructions

ID and Name: UC-1: Order a Meal
Created By:
Primary Actor: Prithvi Raj Date Created: October 4, 2013
Description:
Patron Secondary Actors: Cafeteria Inventory System
Trigger:
Preconditions: A Patron accesses the Cafeteria Ordering System from either the corporate intranet or
Postconditions: external Internet, views the menu for a specific date, selects food items, and places an
order for a meal to be picked up in the cafeteria or delivered to a specified location within a
Normal Flow: specified 15-minute time window.

A Patron indicates that he wants to order a meal.

PRE-1. Patron is logged into COS.
PRE-2. Patron is registered for meal payments by payroll deduction.

POST-1. Meal order is stored in COS with a status of “Accepted.”
POST-2. Inventory of available food items is updated to reflect items in this order.
POST-3. Remaining delivery capacity for the requested time window is updated.

1.0 Order a Single Meal
1. Patron asks to view menu for a specific date. (see 1.0.E1, 1.0.E2)
2. COS displays menu of available food items and the daily special.
3. Patron selects one or more food items from menu. (see 1.1)
4. Patron indicates that meal order is complete. (see 1.2)
5. COS displays ordered menu items, individual prices, and total price, including taxes and

delivery charge.
6. Patron either confirms meal order (continue normal flow) or requests to modify meal order

(return to step 2).
7. COS displays available delivery times for the delivery date.
8. Patron selects a delivery time and specifies the delivery location.
9. Patron specifies payment method.
10. COS confirms acceptance of the order.
11. COS sends Patron an email message confirming order details, price, and delivery

instructions.
12. COS stores order, sends food item information to Cafeteria Inventory System, and updates

available delivery times.

APPENDIX C Sample requirements documents 581

Alternative Flows: 1.1 Order multiple identical meals
Exceptions: 1. Patron requests a specified number of identical meals. (see 1.1.E1)
2. Return to step 4 of normal flow.
Priority: 1.2 Order multiple meals
Frequency of Use: 1. Patron asks to order another meal.
Business Rules: 2. Return to step 1 of normal flow.
Other Information:
1.0.E1 Requested date is today and current time is after today’s order cutoff time
Assumptions: 1. COS informs Patron that it’s too late to place an order for today.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests another date, then COS restarts use case.
1.0.E2 No delivery times left
1. COS informs Patron that no delivery times are available for the meal date.
2a. If Patron cancels the meal ordering process, then COS terminates use case.
2b. Else if Patron requests to pick the order up at the cafeteria, then continue with normal

flow, but skip steps 7 and 8.
1.1.E1 Insufficient inventory to fulfill multiple meal order
1. COS informs Patron of the maximum number of identical meals he can order, based on

current available inventory.
2a. If Patron modifies number of meals ordered, then return to step 4 of normal flow.
2b. Else if Patron cancels the meal ordering process, then COS terminates use case.

High

Approximately 300 users, average of one usage per day. Peak usage load for this use case is
between 9:00 A.M. and 10:00 A.M. local time.

BR-1, BR-2, BR-3, BR-4, BR-11, BR-12, BR-33

1. Patron shall be able to cancel the meal ordering process at any time prior to confirming it.
2. Patron shall be able to view all meals he ordered within the previous six months and repeat

one of those meals as the new order, provided that all food items are available on the
menu for the requested delivery date. (Priority = medium) [Note: You could also show this
as an alternative flow for the use case.]
3. The default date is the current date if the Patron is using the system before today’s order
cutoff time. Otherwise, the default date is the next day that the cafeteria is open.

Assume that 15 percent of Patrons will order the daily special (Source: previous 6 months of
cafeteria data).

582 APPENDIX C Sample requirements documents

[Note: the following use case is written in less detail than UC-1, to illustrate that it isn’t always necessary
to fully specify every detail of the use case, provided developers have the necessary information
available from some other source.]

ID and Name: UC-5 Register for Payroll Deduction
Created By:
Primary Actor: Nancy Anderson Date Created: September 15, 2013
Description:
Patron Secondary Actors: Payroll System
Trigger:
Preconditions: Cafeteria patrons who use the COS and have meals delivered must be registered for payroll
Postconditions: deduction. For noncash purchases made through the COS, the cafeteria will issue a payment
Normal Flow: request to the Payroll System, which will deduct the meal costs from the next scheduled
employee payday direct deposit.
Alternative Flows:
Exceptions: Patron requests to register for payroll deduction, or Patron says yes when COS asks if he wants
Priority: to register.
Business Rules:
Other Information: PRE-1. Patron is logged into COS.

POST-1. Patron is registered for payroll deduction.

5.0 Register for Payroll Deduction
1. COS asks Payroll System if Patron is eligible to register for payroll deduction.
2. Payroll System confirms that Patron is eligible to register for payroll deduction.
3. COS asks Patron to confirm his desire to register for payroll deduction.
4. If so, COS asks Payroll System to establish payroll deduction for Patron.
5. Payroll System confirms that payroll deduction is established.
6. COS informs Patron that payroll deduction is established.

None

5.0.E1 Patron is not eligible for payroll deduction.
5.0.E2 Patron is already enrolled for payroll deduction.

High

BR-86 and BR-88 govern an employee’s eligibility to enroll for payroll deduction.

Expect high frequency of executing this use case within first 2 weeks after system is released.

[Note: the following use case is written in a very brief form, to illustrate that it is not always necessary
to fully complete the use case template, provided developers have the necessary information available
from some other source. It’s a good idea to plan out which use cases require detailing and which do
not.]

ID and Name: UC-9 Modify a Menu
Created By:
Description: Mark Hassall Date Created: October 7, 2013

Exceptions: The cafeteria Menu Manager may retrieve the menu for a specific date in the future, modify
it to add new food items, remove or change food items, create or change a meal special, or
Priority: change prices, and save the modified menu.
Business Rules:
Other Information: No menu exists for the specified date; show an error message and let the Menu Manager
enter a new date.

High

BR-24

Certain food items will not be deliverable, so the menu presented to the Patrons of the COS
for delivery will not always exactly match the menu available for pickup in the cafeteria. The
Menu Manager can set which items are not deliverable.

APPENDIX C Sample requirements documents 583

Software Requirements Specification

1. Introduction

1.1 Purpose

This SRS describes the functional and nonfunctional requirements for software release 1.0 of the
Cafeteria Ordering System (COS). This document is intended to be used by the members of the
project team who will implement and verify the correct functioning of the system. Unless otherwise
noted, all requirements specified here are committed for release 1.0.

1.2 Document Conventions

No special typographical conventions are used in this SRS.

1.3 Project Scope

The COS will permit Process Impact employees to order meals from the company cafeteria online
to be delivered to specified campus locations. A detailed description is available in the Cafeteria
Ordering System Vision and Scope Document [1], along with the features that are scheduled for full or
partial implementation in this release.

1.4 References

1. Wiegers, Karl. Cafeteria Ordering System Vision and Scope Document, www.processimpact.com/
projects/COS/COS Vision and Scope.docx

2. Beatty, Joy. Process Impact Intranet Development Standard, Version 1.3, www.processimpact.com/
corporate/standards/PI Intranet Development Standard.pdf

3. Rath, Andrew. Process Impact Internet Application User Interface Standard, Version 2.0,
www.processimpact.com/corporate/standards/PI Internet UI Standard.pdf

2. Overall Description

2.1 Product Perspective

The Cafeteria Ordering System is a new software system that replaces the current manual and
telephone processes for ordering and picking up meals in the Process Impact cafeteria. The context
diagram in Figure C-2 illustrates the external entities and system interfaces for release 1.0. The system
is expected to evolve over several releases, ultimately connecting to the Internet ordering services for
several local restaurants and to credit and debit card authorization services.

584 APPENDIX C Sample requirements documents

FIGURE C-2 Context diagram for release 1.0 of the Cafeteria Ordering System.

2.2 User Classes and Characteristics

User class Description
Patron (favored)
A Patron is a Process Impact employee who wants to order meals to be delivered from the
Cafeteria Staff company cafeteria. There are about 600 potential Patrons, of which 300 are expected to use
Menu Manager the COS an average of 5 times per week each. Patrons will sometimes order multiple meals for
group events or guests. An estimated 60 percent of orders will be placed using the corporate
Meal Deliverer intranet, with 40 percent of orders being placed from home or by smartphone or tablet apps.

The Process Impact cafeteria employs about 20 Cafeteria Staff who will receive orders from the
COS, prepare meals, package them for delivery, and request delivery. Most of the Cafeteria Staff
will need training in the use of the hardware and software for the COS.

The Menu Manager is a cafeteria employee who establishes and maintains daily menus of the
food items available from the cafeteria. Some menu items may not be available for delivery. The
Menu Manager will also define the cafeteria’s daily specials. The Menu Manager will need to
edit existing menus periodically.

As the Cafeteria Staff prepare orders for delivery, they will issue delivery requests to a Meal
Deliverer’s smartphone. The Meal Deliverer will pick up the food and deliver it to the Patron. A
Meal Deliverer's other interactions with the COS will be to confirm that a meal was (or was not)
delivered.

APPENDIX C Sample requirements documents 585

2.3 Operating Environment

OE-1: The COS shall operate correctly with the following web browsers: Windows Internet Explorer
versions 7, 8, and 9; Firefox versions 12 through 26; Google Chrome (all versions); and Apple Safari
versions 4.0 through 8.0.
OE-2: The COS shall operate on a server running the current corporate-approved versions of Red Hat
Linux and Apache HTTP Server.
OE-3: The COS shall permit user access from the corporate intranet; from a VPN Internet connection;
and by Android, iOS, and Windows smartphones and tablets.

2.4 Design and Implementation Constraints

CO-1: The system’s design, code, and maintenance documentation shall conform to the Process
Impact Intranet Development Standard, Version 1.3 [2].
CO-2: The system shall use the current corporate standard Oracle database engine.
CO-3: All HTML code shall conform to the HTML 5.0 standard.

2.5 Assumptions and Dependencies

AS-1: The cafeteria is open for breakfast, lunch, and supper every company business day in which
employees are expected to be on site.
DE-1: The operation of the COS depends on changes being made in the Payroll System to accept
payment requests for meals ordered with the COS.
DE-2: The operation of the COS depends on changes being made in the Cafeteria Inventory System to
update the availability of food items as COS accepts meal orders.

3. System Features

3.1 Order Meals from Cafeteria

3.1.1 Description
A cafeteria Patron whose identity has been verified can order meals either to be delivered to a
specified company location or to be picked up in the cafeteria. A Patron can cancel or change a meal
order if it has not yet been prepared. Priority = High.

586 APPENDIX C Sample requirements documents

3.1.2 Functional Requirements

APPENDIX C Sample requirements documents 587

[Note: Functional requirements for reordering a meal and for changing and canceling meal orders are
not provided in this example.]

3.2 Order Meals from Restaurants

[Details are not provided in this example. Quite a lot of the functionality described under 3.1
Order Meals from Cafeteria could likely be reused, so this section should just specify the additional
functionality that addresses the restaurant interface.]

3.3 Create, View, Modify, and Delete Meal Subscriptions

[Details are not provided in this example.]

3.4 Create, View, Modify, and Delete Cafeteria Menus

[Details are not provided in this example.]

588 APPENDIX C Sample requirements documents

4. Data Requirements

4.1 Logical Data Model

FIGURE C-3 Partial data model for release 1.0 of the Cafeteria Ordering System.

4.2 Data Dictionary

Data element Description Composition or data type Length Values
delivery instruction patron name
where and to whom a meal + patron phone number 50 hyphens and
delivery location is to be delivered, if it isn’t + meal date hh:mm commas permitted
being picked up in the + delivery location local time; hh = 0-23
delivery time cafeteria + delivery time window 6 inclusive; mm = 00,
window alphanumeric 100 15, 30, or 45
building and room to which dd.cc
employee ID an ordered meal is to be time
delivered
food item integer
description beginning time of a
food item price 15-minute range on the alphabetic
meal date during which
an ordered meal is to be numeric, dollars and cents
delivered

company ID number of the
employee who placed a
meal order

description of a food item
on a menu

pre-tax cost of a single unit
of a menu food item

APPENDIX C Sample requirements documents 589

Data element Description Composition or data type Length Values
meal date default = current
the date the meal is to be date, MM/DD/YYYY 10 date if the current
delivered or picked up time is before the
order cutoff time,
meal order details about a meal a meal order number else the next day;
Patron ordered + order date cannot be prior to
meal order number + meal date current date
meal order status + 1:m{ordered food item}
+ delivery instruction Initial value is 1
+ meal order status Incomplete,
accepted, prepared,
unique ID that COS assigns integer 7 pending delivery,
to each accepted meal order 16 delivered, canceled

status of a meal order that a alphabetic hyphens and
Patron initiated commas permitted

meal payment information about a payment amount
menu payment COS accepted for + payment method
menu date a meal + transaction number
menu food item
order cutoff time list of food items available menu date
order date for purchase on a specific + 1:m{menu food item}
ordered food item date
patron
the date for which a specific date, MM/DD/YYYY 10
patron email menu is available
patron location
patron name description of a menu item food item description
patron phone + food item price
number
the time of day before time, HH:MM 5
which all meal orders for
that date must be placed

the date on which a Patron date, MM/DD/YYYY 10
placed a meal order

one menu food item that a menu food item
Patron requested as part of + quantity ordered
a meal order

a Process Impact employee patron name
who is authorized to order + employee ID
a meal + patron phone number
+ patron location
+ patron email

email address of the alphanumeric 50
employee who placed a
meal order

building and room numbers alphanumeric 50
of the employee who placed
a meal order

name of the employee who alphabetic 30
placed a meal order

telephone number of the AAA-EEE-NNNN xXXXX for 18
employee who placed a area code (A), exchange
meal order (E), number (N), and
extension (X)

590 APPENDIX C Sample requirements documents

Data element Description Composition or data type Length Values
payment amount numeric, dollars and cents dddd.cc
total price of an order in payroll deduction,
payment method dollars and cents, calculated alphabetic 16 cash, credit card,
per BR-12 debit card
default = 1;
how the Patron is paying for maximum = quantity
a meal he ordered presently in inventory

quantity ordered the number of units of each integer 4
transaction number food item that the Patron integer 12
is ordering in a single meal
order

unique sequence number
that COS assigns to each
payment transaction

4.3 Reports

4.3.1 Ordered Meal History Report

Report ID COS-RPT-1
Report Title
Report Purpose Ordered Meal History

Priority Patron wants to see a list of all meals that he had previously ordered from the Process
Report Users Impact cafeteria or local restaurants over a specified time period up to 6 months prior
Data Sources to the current date, so he can reorder a particular meal he liked.
Frequency and Disposition
Medium
Latency
Visual Layout Patrons
Header and Footer
Report Body Database of previously placed meal orders

End-of-Report Indicator Report is generated on demand by a Patron. Data in the report is static. Report is
Interactivity displayed on user’s web browser screen on a computer, tablet, or smartphone. It can be
Security Access Restrictions printed if the display device permits printing.

Complete report must be displayed to Patron within 3 seconds after it is requested.

Landscape mode

Report header shall contain the report title, Patron’s name, and date range specified.
If printed, report footer shall show the page number.

Fields shown and column headings:
■ Order Number
■ Meal Date
■ Ordered From (“Cafeteria” or restaurant name)
■ Items Ordered (list all items in the meal order, their quantity, and their prices)
■ Total Food Price
■ Tax
■ Delivery Charge
■ Total Price (sum of food item prices, tax, and delivery charge)
Selection Criteria: date range specified by Patron, inclusive of end points
Sort Criteria: reverse chronological order

None

Patron can drill down to see ingredients and nutritional information for each item in
the order.

A Patron may retrieve only his own meal order history.

[Note: Other COS reports are not provided in this example.]

APPENDIX C Sample requirements documents 591

4.4 Data Integrity, Retention, and Disposal

DI-1: The COS shall retain individual Patron meal orders for 6 months following the meal’s delivery date.
DI-2: The COS shall retain menus for 1 year following the menu date.

5. External Interface Requirements

5.1 User Interfaces

UI-1: The Cafeteria Ordering System screen displays shall conform to the Process Impact Internet
Application User Interface Standard, Version 2.0 [3].
UI-2: The system shall provide a help link from each displayed webpage to explain how to use that
page.
UI-3: The webpages shall permit complete navigation and food item selection by using the keyboard
alone, in addition to using mouse and keyboard combinations.

5.2 Software Interfaces

SI-1: Cafeteria Inventory System
SI-1.1: The COS shall transmit the quantities of food items ordered to the Cafeteria Inventory
System through a programmatic interface.
SI-1.2: The COS shall poll the Cafeteria Inventory System to determine whether a requested food
item is available.
SI-1.3: When the Cafeteria Inventory System notifies the COS that a specific food item is no longer
available, the COS shall remove that food item from the menu for the current date.

SI-2: Payroll System
The COS shall communicate with the Payroll System through a programmatic interface for the

following operations:
SI-2.1: To allow a Patron to register and unregister for payroll deduction.
SI-2.2: To inquire whether a Patron is registered for payroll deduction.
SI-2.3: To inquire whether a Patron is eligible to register for payroll deduction.
SI-2.4: To submit a payment request for a purchased meal.
SI-2.5: To reverse a previous charge because a patron rejected a meal or wasn’t satisfied with it, or
because the meal was not delivered per the delivery instructions.

5.3 Hardware Interfaces

No hardware interfaces have been identified.

592 APPENDIX C Sample requirements documents

5.4 Communications Interfaces

CI-1: The COS shall send an email or text message (based on user account settings) to the Patron to
confirm acceptance of an order, price, and delivery instructions.

CI-2: The COS shall send an email or text message (based on user account settings) to the Patron to
report any problems with a meal order or delivery.

6. Quality Attributes

6.1 Usability Requirements

USE-1: The COS shall allow a Patron to retrieve the previous meal ordered with a single interaction.

USE-2: 95% of new users shall be able to successfully order a meal without errors on their first try.

6.2 Performance Requirements

PER-1: The system shall accommodate a total of 400 users and a maximum of 100 concurrent users
during the peak usage time window of 9:00 A.M. to 10:00 A.M. local time, with an estimated average
session duration of 8 minutes.

PER-2: 95% of webpages generated by the COS shall download completely within 4 seconds from the
time the user requests the page over a 20 Mbps or faster Internet connection.

PER-3: The system shall display confirmation messages to users within an average of 3 seconds and a
maximum of 6 seconds after the user submits information to the system.

6.3 Security Requirements

SEC-1: All network transactions that involve financial information or personally identifiable
information shall be encrypted per BR-33.

SEC-2: Users shall be required to log on to the COS for all operations except viewing a menu.

SEC-3: Only authorized Menu Managers shall be permitted to work with menus, per BR-24.

SEC-4: The system shall permit Patrons to view only orders that they placed.

6.4 Safety Requirements

SAF-1: The user shall be able to see a list of all ingredients in any menu items, with ingredients
highlighted that are known to cause allergic reactions in more than 0.5 percent of the North
American population.

APPENDIX C Sample requirements documents 593

6.5 Availability Requirements

AVL-1: The COS shall be available at least 98% of the time between 5:00 A.M. and midnight local
time and at least 90% of the time between midnight and 5:00 A.M. local time, excluding scheduled
maintenance windows.

6.6 Robustness Requirements

ROB-1: If the connection between the user and the COS is broken prior to a new order being either
confirmed or terminated, the COS shall enable the user to recover an incomplete order and continue
working on it.

Appendix A: Analysis Models

Figure C-4 is a state-transition diagram that shows the possible meal order statuses and the allowed
changes in status.

FIGURE C-4 State-transition diagram for meal order status.
594 APPENDIX C Sample requirements documents

Business Rules

[Note: The following illustrates a portion of a separate business rules catalog.]

ID Rule definition Type of rule Static or Source
dynamic Cafeteria Manager
BR-1 Delivery time windows are 15 minutes, Fact Dynamic
BR-2 beginning on each quarter hour. Constraint Dynamic Cafeteria Manager
BR-3 Constraint Static
BR-4 Deliveries must be completed between Constraint Static Cafeteria Manager
BR-8 11:00 A.M. and 2:00 P.M. local time, inclusive. Constraint Dynamic
BR-11 Constraint Dynamic Cafeteria Manager
BR-12 All meals in a single order must be delivered Computation Dynamic
to the same location. Cafeteria Manager
BR-24 Constraint Static
All meals in a single order must be paid for by Cafeteria Manager
BR-33 using the same payment method. Constraint Static
cafeteria policy; state
BR-86 Meals must be ordered within 14 calendar Constraint Static tax code
BR-88 days of the meal date. Constraint Dynamic
cafeteria policy
If an order is to be delivered, the patron must
pay by payroll deduction. corporate security
policy
Order price is calculated as the sum of each
food item price times the quantity of that Corporate
food item ordered, plus applicable sales tax, Accounting Manager
plus a delivery charge if a meal is delivered Corporate
outside the free delivery zone. Accounting Manager

Only cafeteria employees who are designated
as Menu Managers by the Cafeteria Manager
can create, modify, or delete cafeteria menus.

Network transmissions that involve financial
information or personally identifiable
information require 256-bit encryption.

Only regular employees can register for
payroll deduction for any company purchase.

An employee can register for payroll
deduction payment of cafeteria meals if no
more than 40 percent of his gross pay is
currently being deducted for other reasons.

APPENDIX C Sample requirements documents 595



Glossary

acceptance criteria Conditions that a software requirements, negotiating priorities, and related
product must satisfy to be accepted by a user, activities.
customer, or other stakeholder.
analyst See business analyst.
acceptance test A test that evaluates anticipated
usage scenarios to determine the software’s application See product.
acceptability. Used in agile development both
to express details about a user story and to architecture The structure of a system, including
determine whether a user story is fully and correctly any software, hardware, and human components
implemented. that make up the system, the interfaces and
relationships between those components, and
activity diagram An analysis model that depicts the component behaviors that are visible to other
a process flow proceeding from one activity to components.
another. Similar to a flowchart.
assumption A statement that is believed to be true
actor A person performing a specific role, a in the absence of proof or definitive knowledge.
software system, or a hardware device that interacts
with a system to achieve a useful goal. Also called a attribute, quality See quality attribute.
user role.
attribute, requirement See requirement attribute.
agile development A term used for software
development methods characterized by continuous BA See business analyst.
collaboration between developers and customers,
limited documentation of requirements in the form backlog, product On an agile project, the
of user stories and corresponding acceptance tests, prioritized list of work remaining for the project.
and rapid and frequent delivery of small increments A backlog can contain user stories, business
of useful functionality. Agile development processes, change requests, infrastructure
methods include Extreme Programming, Scrum, development, and defect stories. Work items from
Feature-Driven Development, Lean Software the backlog are allocated to upcoming iterations
Development, and Kanban. based on their priority.

allocation See requirements allocation. baseline, requirements A snapshot in time that
represents the current agreed-upon, reviewed,
alternative flow A path through a use case that and approved set of requirements, often defining
leads to success but that involves a variation from the contents of a specific product release or
the normal flow in the specifics of the task or in the development iteration. Serves as the basis for
actor’s interaction with the system. further development work.

analysis, requirements The process of classifying big data A collection of data that is characterized
requirements information into various categories, as large volume (much data exists), high velocity
evaluating requirements for desirable qualities, (data flows rapidly into an organization), and/or
representing requirements in different forms, highly complex (the data is diverse). Managing big
deriving detailed requirements from high-level data entails understanding how to discover, collect,
store, and process the data quickly and effectively.

597

business analyst (BA) The role on a project constraint A restriction that is imposed on the
team that has primary responsibility for choices available to the developer for the design
working with stakeholder representatives and construction of a product. Other types of
to elicit, analyze, specify, validate, and constraints can restrict the options available to
manage the project’s requirements. Also project managers. Business rules often impose
called a requirements analyst, system analyst, constraints on business operations and hence on
requirements engineer, requirements manager, software systems.
business systems analyst, and simply analyst.
context diagram An analysis model that
business analytics system A software system depicts a system at a high level of abstraction.
used to convert large and complex data sets into The context diagram identifies objects outside
meaningful information from which to make the system that exchange data with the system,
decisions. but it shows nothing about the system’s internal
structure or behavior.
business objective A financial or nonfinancial
business benefit that an organization expects COTS (commercial off-the-shelf) product
to receive as a result of a project or some other A software package purchased from a vendor
initiative. and either used as a self-contained solution to
a problem or integrated, customized, and/or
business objectives model A visual extended to satisfy customer needs.
representation of a hierarchy of business
problems and business objectives. CRUD matrix A table that correlates system
actions with data entities to show where each
business requirements A set of information data item is created, read, updated, and deleted.
that describes a business need that leads to
one or more projects to deliver a solution customer An individual or organization that
and the desired ultimate business outcomes. derives either direct or indirect benefit from a
The business requirements include business product. Software customers might request, pay
opportunities, business objectives, success for, select, specify, use, or receive the output
metrics, a vision statement, and scope and generated by a software product.
limitations.
dashboard report A screen display or
business rule A policy, guideline, standard, printed report that uses multiple textual and/or
regulation, or computational formula that graphical representations of data to provide a
defines or constrains some aspect of the consolidated, multidimensional view of what is
business. going on in an organization or a process.

cardinality The number of instances of a data dictionary A collection of definitions for
particular data entity that logically relate to the data elements and data structures that are
an instance of another entity. Possibilities are relevant to the problem domain.
one-to-one, one-to-many, and many-to-many.
data flow diagram An analysis model that
change control board (CCB) The group of depicts the processes, data stores, external
people responsible for deciding to accept or entities, and flows among them that characterize
reject proposed changes on a software project, the behavior of data flowing through business
including changes in requirements. processes or software systems.

class A description of a set of objects having decision rule An agreed-upon way by which a
common properties and behaviors, which body of people arrives at a decision.
typically correspond to real-world items
(persons, places, or things) in the business or decision table An analysis model in the form
problem domain. of a matrix that shows all combinations of
values for a set of conditions and indicates the
class diagram An analysis model that shows a expected system action in response to each
set of system or problem domain classes, their combination.
interfaces, and their relationships.

598 Glossary

decision tree An analysis model that visually out and extended incrementally as requirements
depicts the actions a system takes in response to become clear and ready for implementation.
specific combinations of a set of conditions.
exception A condition that can prevent a use
dependency As used in requirements case from concluding successfully. Unless some
specification, a reliance that a project has on a recovery mechanism is possible, the use case’s
factor, event, or group outside its control. postconditions are not reached and the actor’s
goal is not achieved.
dialog map An analysis model that depicts a
user interface architecture, showing the dialog extend relationship A construct in which an
elements with which the user can interact and alternative flow in a use case branches off from
the navigations permitted between them. the normal flow into a separate extension use
case.
ecosystem map An analysis model that shows a
set of systems that interact with each other and external entity An object in a context diagram
the nature of their relationships. Unlike a context or a data flow diagram that represents a user
diagram, an ecosystem map shows systems that class, actor, software system, or hardware device
have a relationship even if there is no direct that is external to the system being described
interface between them. but interfaces to it in some fashion. Also called a
terminator.
elicitation, requirements The process of
identifying requirements from various sources external interface requirement A description
through interviews, workshops, focus groups, of a connection between a software system and
observations, document analysis, and other a user, another software system, or a hardware
mechanisms. device.

embedded system A system that contains facilitator A person who is responsible for
hardware components controlled by software planning and leading a group activity, such as a
running on a dedicated computer that is requirements elicitation workshop.
incorporated as part of a larger product.
feature One or more logically related system
entity An item in the business domain about capabilities that provide value to a user and are
which data is collected and stored. described by a set of functional requirements.

entity-relationship diagram An analysis feature tree An analysis model that depicts the
model that identifies the logical relationships features planned for a product in a hierarchical
between pairs of entities. Used for modeling tree, showing up to two levels of subfeatures
data. beneath each main feature.

epic A user story on an agile project that is flowchart An analysis model that shows the
too large to implement in one development processing steps and decision points in the logic
iteration. It is subdivided into smaller stories of a process. Similar to an activity diagram.
that each can be fully implemented in a single
iteration. function point A measure of software size,
based on the number and complexity of internal
event A trigger or stimulus that takes place in logical files, external interface files, external
a system’s environment that leads to a system inputs, outputs, and queries.
response, such as a functional behavior or a
change in state. functional requirement A description of a
behavior that a software system will exhibit
event-response table A list of the external under specific conditions.
or time-triggered events that could affect the
system and a description of how the system is to gap analysis A comparison of the current state
respond to each event. to an alternative or potential state for a system,
process, or other aspect of a business situation,
evolutionary prototype A fully functional to identify significant differences between them.
prototype created as a skeleton or an initial
increment of the final product, which is fleshed

Glossary 599

gold-plating Unnecessary or excessively paper prototype A non-executable mock-up of
complex functionality that is specified or built a software system’s user interface using low-tech
into a product, sometimes without customer screen sketches.
approval.
peer review An activity in which one or more
green-field project A project in which new persons other than the author of a work product
software or a new system is developed. examine that product with the intent of finding
defects and improvement opportunities.
horizontal prototype See mock-up.
pilot A controlled execution of a new solution
include relationship A construct in which (such as a process, tool, software system, or
several steps that recur in multiple use cases are training course) with the objective of evaluating
factored out into a separate sub-use case, which the solution under real conditions to assess its
the other use cases then invoke when needed. readiness for general deployment.

inspection A type of formal peer review that Planguage A keyword-oriented language
involves a trained team of individuals who developed by Tom Gilb that enables precise
follow a well-defined process to examine a work and quantitative specification of requirements,
product carefully for defects. particularly nonfunctional requirements.

issue, requirement A defect, open question, postcondition A condition that describes the
or decision regarding a requirement. Examples state of a system after a use case is successfully
include items flagged as TBD, pending decisions, completed.
information that is needed, and conflicts
awaiting resolution. precondition A condition that must be satisfied
or a state the system must be in before a use
iteration An uninterrupted development case can begin.
period, typically one to four weeks in duration,
during which a development team implements prioritization The act of determining which
a defined set of functionality selected from the requirements for a software product are the
product backlog or baselined requirements for most important for achieving business success
the product. and the sequence in which requirements should
be implemented.
mock-up A partial or possible representation
of a user interface for a software system. procedure A step-by-step description of
Used to evaluate usability and to assess the a course of action to be taken to perform a
completeness and correctness of requirements. specified activity, describing how the activity is
Could be executable or could be in the form to be accomplished.
of a paper prototype. Also called a horizontal
prototype. process A sequence of activities performed for
a particular purpose. A process description is a
navigation map See dialog map. documented definition of those activities.

nonfunctional requirement A description of process assets Items such as templates,
a property or characteristic that a system must forms, checklists, policies, procedures, process
exhibit or a constraint that it must respect. descriptions, and sample work products that are
collected to assist an organization’s effective
normal flow The default sequence of steps in a application of software development practices.
use case, which leads to satisfying the use case’s
postconditions and letting the user achieve his process flow The sequential steps of a business
goal. Also known as the normal course, main process or the operations of a proposed
course, basic flow, normal sequence, main success software system. Often represented by using an
scenario, and happy path. activity diagram, flowchart, swimlane diagram,
or other modeling notation.
operational profile A suite of scenarios that
represents the expected usage pattern of a product Whatever ultimate deliverable a
software product. project is developing. In this book, product,

600 Glossary

application, system, and solution are used requirement pattern A systematic approach to
interchangeably. specifying a particular type of requirement.

product backlog See backlog, product. requirements allocation The process of
apportioning system requirements among
product champion A designated various architectural subsystems and
representative of a specific user class who components.
supplies the user requirements for the group
that he or she represents. requirements analysis See analysis,
requirements.
product owner A role, typically on an agile
project team, that represents the customer and requirements analyst See business analyst.
that is responsible for setting the product vision,
providing project boundaries and constraints, requirements development The process
prioritizing the contents of the product backlog, of defining a project’s scope, identifying
and making product decisions. user classes and user representatives, and
eliciting, analyzing, specifying, and validating
proof of concept A prototype that implements requirements. The product of requirements
a portion of a software-containing system that development is a set of documented
slices through multiple layers of the architecture. requirements that defines some portion of the
Used to evaluate technical feasibility and product to be built.
performance. Also called a vertical prototype.
requirements engineer See business analyst.
prototype A partial, preliminary, or possible
implementation of a software system. Used requirements engineering The subdiscipline
to explore and validate requirements and of systems engineering and software
design approaches. Types of prototypes engineering that encompasses all project
are evolutionary and throwaway; paper and activities associated with understanding a
electronic; and mock-up and proof-of-concept. product’s necessary capabilities and attributes.
Includes both requirements development and
quality attribute A nonfunctional requirement requirements management.
that describes a service or performance
characteristic of a product. Types of quality requirements management The process of
attributes include usability, portability, working with a defined set of requirements
maintainability, integrity, efficiency, reliability, throughout the product’s development
and robustness. Quality attribute requirements process and its operational life. Includes
describe the extent to which a software product tracking requirements status, managing
must demonstrate desired characteristics. changes to requirements, controlling versions
of requirements specifications, and tracing
quality-of-service requirement See quality individual requirements to other requirements
attribute. and system elements.

real-time system A hardware and software requirements specification See software
system that must produce a response within a requirements specification and specification,
specified time after an initiating event. requirements.

requirement A statement of a customer need requirements traceability matrix
or objective, or of a condition or capability that A table that depicts logical links between
a product must possess to satisfy such a need or individual functional requirements and other
objective. A property that a product must have system artifacts, including other functional
to provide value to a stakeholder. requirements, user requirements, business
requirements, architecture and design elements,
requirement attribute Descriptive information code modules, tests, and business rules.
about a requirement that enriches its definition
beyond the statement of intended functionality. retrospective A review in which project
Example attribute types are origin, rationale, participants reflect on the project’s activities and
priority, owner, release number, and version outcomes with the intent of identifying ways to
number. make the next project be even more successful.

Glossary 601

reuse, requirements The act of using existing state machine diagram An analysis model
requirements knowledge in multiple systems that shows the sequence of states that an object
that share some similar functionality. in a system goes through during its lifetime in
response to specific events that take place, or
review See peer review. that shows the possible states of the system as a
whole. Similar to a state-transition diagram.
risk A condition that could cause some loss or
otherwise threaten the success of a project. state table An analysis model that shows in
matrix form the various states that a system, or
root cause analysis An activity that seeks an object in the system, can be in, and which
to understand the underlying factors that of the possible transitions between states are
contribute to an observed problem. allowed.

scenario A description of a specific interaction state-transition diagram An analysis model
between a user and a system to accomplish that visually depicts the various states in which
some goal. Alternatively, an instance of usage of a system or an object in the system can exist,
the system, or a specific path through a use case. the permitted transitions that can take place
between states, and the conditions and/or
scope The portion of the ultimate product events that trigger each transition. Similar to a
vision that the current project will address. state machine or statechart diagram.
The scope draws the boundary between what’s
in and what’s out for a project that creates a story See user story.
specific release or for a single development
iteration. subject matter expert An individual who
has extensive experience and knowledge
scope creep A condition in which the scope in a domain and who is recognized as an
of a project continues to increase in an authoritative source of information about the
uncontrolled fashion throughout the domain.
development process.
swimlane diagram An analysis model that
software development life cycle A sequence shows the sequential steps of a business process
of activities by which a software product is flow or the operations of a proposed software
defined, designed, built, and verified. system. The process is subdivided into visual
components called lanes, which show the
software requirements specification (SRS) systems or actors that execute the steps.
A collection of the functional and nonfunctional
requirements for a software product. system A product that contains multiple software
and/or hardware subsystems. Colloquially, system
solution All of the components delivered by a also is used interchangeably in this book with
project to achieve a set of business objectives application, product, and solution to refer to
specified by an organization, including software, whatever software-containing deliverable a team
hardware, business processes, user manuals, and is building.
training.
system requirement A high-level requirement
specification, requirements The process for a product that contains multiple subsystems,
of documenting a software application’s which could be all software or software and
requirements in a structured, shareable, and hardware.
manageable form. Also, the product from this
process (see software requirements specification). TBD Abbreviation for to be determined. TBD
serves as a placeholder when you know you are
sprint See iteration. missing some requirements information. See
issue, requirement.
SRS See software requirements specification.
template A pattern to be used as a guide for
stakeholder An individual, group, or producing a complete document or other item.
organization that is actively involved in a
project, is affected by its process or outcome, or throwaway prototype A prototype that
can influence its process or outcome. is created with the intent of discarding it

602 Glossary

after it has served its purpose of clarifying user stories, and scenarios are common ways to
and validating requirements and/or design represent user requirements.
alternatives.
user role See actor.
tracing The process of defining logical links
between one system element (user requirement, user story A format to capture user
functional requirement, business rule, design requirements on agile projects in the form of
component, code module, test, and the like) and one or two sentences that articulate a user need
another. Also called traceability. or describe a unit of desired functionality, as well
as stating the benefit of the functionality to the
UML An abbreviation for the Unified Modeling user.
Language, which describes a set of standard
notations for creating various visual models validation The process of evaluating a project
of systems, particularly for object-oriented deliverable to determine whether it satisfies
software development. customer needs. Often stated as “Are we
building the right product?”
usage scenario See scenario.
verification The process of evaluating a project
use case A description of a set of logically deliverable to determine whether it satisfies
related possible interactions between an actor the specifications on which it was based. Often
and a system that results in an outcome that stated as “Are we building the product right?”
provides value to the actor. Can encompass
multiple scenarios. vertical prototype See proof of concept.

use case diagram An analysis model that vision A statement that describes the strategic
identifies the actors who can interact with a concept or the ultimate purpose and form of a
system to accomplish valuable goals and the new system.
various use cases that each actor might be
involved with. vision and scope document A collection of
the business requirements for a new system,
user A customer who will interact with a including business objectives, success metrics,
system either directly or indirectly (for example, a product vision statement, and a project scope
by using outputs from the system but not description.
generating those outputs personally). Also called
end user. waterfall development life cycle A model
of the software development process in which
user class A group of users for a system who the various activities of requirements, design,
have similar characteristics and requirements for coding, testing, and deployment are performed
the system. Members of a user class function as sequentially with little overlap or iteration.
actors when interacting with the system through
use cases. wireframe A kind of throwaway mock-up
prototype that is often used for preliminary
user requirement A goal or task that specific webpage design.
classes of users must be able to perform with a
system, or a desired product attribute. Use cases, work product Any interim or final deliverable
created for a software project.

Glossary 603



References

Abran, Alain, James W. Moore, Pierre Bourque, and Robert Dupuis, eds. 2004. Guide to the Software
Engineering Body of Knowledge, 2004 Version. Los Alamitos, CA: IEEE Computer Society Press.

Akers, Doug. 2008. “Real Reuse for Requirements.” Methods & Tools 16(1):33–40.
Alexander, Ian F., and Ljerka Beus-Dukic. 2009. Discovering Requirements: How to Specify Products

and Services. Chichester, England: John Wiley & Sons Ltd.
Alexander, Ian F., and Neil Maiden. 2004. Scenarios, Stories, Use Cases: Through the Systems

Development Life-Cycle. Chichester, England: John Wiley & Sons Ltd.
Alexander, Ian F., and Richard Stevens. 2002. Writing Better Requirements. London: Addison-Wesley.
Ambler, Scott. 2005. The Elements of UML 2.0 Style. New York: Cambridge University Press.
Anderson, Ross J. 2008. Security Engineering: A Guide to Building Dependable Distributed Systems,

2nd ed. Indianapolis, IN: Wiley Publishing, Inc.
Arlow, Jim. 1998. “Use Cases, UML Visual Modeling and the Trivialisation of Business Requirements.”

Requirements Engineering 3(2):150–152.
Armour, Frank, and Granville Miller. 2001. Advanced Use Case Modeling: Software Systems.

Boston: Addison-Wesley.
Arnold, Robert S., and Shawn A. Bohner. 1996. Software Change Impact Analysis. Los Alamitos,

CA: IEEE Computer Society Press.
Basili, Victor R., and H. Dieter Rombach. 1988. “The TAME Project: Towards Improvement-Oriented

Software Environments.” IEEE Transactions on Software Engineering. 14(6):758–773.
Bass, Len, Paul Clements, and Rick Kazman. 1998. Software Architecture in Practice. Reading,

MA: Addison-Wesley.
Beatty, Joy, and Anthony Chen. 2012. Visual Models for Software Requirements. Redmond,

WA: Microsoft Press.
Beatty, Joy, and Remo Ferrari. 2011. “How to Evaluate and Select a Requirements Management Tool.”

http://www.seilevel.com/wp-content/uploads/RequirementsManagementToolWhitepaper_1.pdf.
Beck, Kent, et al. 2001. “Manifesto for Agile Software Development.” http://www.agilemanifesto.org.
Beizer, Boris. 1999. “Best and Worst Testing Practices: A Baker’s Dozen.” Cutter IT Journal 12(2):32–38.

605

Beyer, Hugh, and Karen Holtzblatt. 1998. Contextual Design: Defining Customer-Centered
Systems. San Francisco, CA: Morgan Kaufmann Publishers, Inc.

Blackburn, Joseph D., Gary D. Scudder, and Luk N. Van Wassenhove. 1996. “Improving Speed
and Productivity of Software Development: A Global Survey of Software Developers.”
IEEE Transactions on Software Engineering 22(12):875–885.

Boehm, Barry W. 1981. Software Engineering Economics. Upper Saddle River, NJ: Prentice Hall.
. 1988. “A Spiral Model of Software Development and Enhancement.” IEEE Computer
21(5):61–72.
. 2000. “Requirements that Handle IKIWISI, COTS, and Rapid Change.” IEEE Computer
33(7):99–102.

Boehm, Barry W., Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz,
Ray Madachy, Donald J. Reifer, and Bert Steece. 2000. Software Cost Estimation with
Cocomo II. Upper Saddle River, NJ: Prentice Hall PTR.

Boehm, Barry W., and Philip N. Papaccio. 1988. “Understanding and Controlling Software
Costs.” IEEE Transactions on Software Engineering 14(10):1462–1477.

Boehm, Barry, and Richard Turner. 2004. Balancing Agility and Discipline: A Guide for the
Perplexed. Boston: Addison-Wesley.

Booch, Grady, James Rumbaugh, and Ivar Jacobson. 1999. The Unified Modeling Language User
Guide. Reading, MA: Addison-Wesley.

Box, George E. P., and Norman R. Draper. 1987. Empirical Model-Building and Response
Surfaces. New York: John Wiley & Sons, Inc.

Boyer, Jérôme, and Hafedh Mili. 2011. Agile Business Rule Development: Process, Architecture,
and JRules Examples. Heidelberg, Germany: Springer.

Bradshaw, Jeffrey M. 1997. Software Agents. Menlo Park, CA: The AAAI Press.
Brijs, Bert. 2013. Business Analysis for Business Intelligence. Boca Raton, FL: CRC Press.
Brooks, Frederick P., Jr. 1987. “No Silver Bullet: Essence and Accidents of Software Engineering.”

IEEE Computer 20(4):10–19.
Brosseau, Jim. 2010. “Software Quality Attributes: Following All the Steps.” http://www.clarrus.com/

resources/articles/software-quality-attributes.
Brown, Norm. 1996. “Industrial-Strength Management Strategies.” IEEE Software 13(4):94–103.
Business Rules Group. 2012. http://www.businessrulesgroup.org.
Callele, David, Eric Neufeld, and Kevin Schneider. 2008. "Emotional Requirements.“ IEEE

Software 25(1):43–45.
Caputo, Kim. 1998. CMM Implementation Guide: Choreographing Software Process Improvement.

Reading, MA: Addison-Wesley.

606 References

Carr, Marvin J., Suresh L. Konda, Ira Monarch, F. Carol Ulrich, and Clay F. Walker. 1993.
Taxonomy-Based Risk Identification (CMU/ SEI-93-TR-6). Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University.

Cavano, J. P., and J. A. McCall. 1978. “A Framework for the Measurement of Software Quality.”
ACM SIGSOFT Software Engineering Notes 3(5):133–139.

Charette, Robert N. 1990. Applications Strategies for Risk Analysis. New York: McGraw-Hill.

Chernak, Yuri. 2012. “Requirements Reuse: The State of the Practice.” In Proceedings of the 2012
IEEE International Conference on Software Science, Technology and Engineering, 46–53.
Los Alamitos, CA: IEEE Computer Society Press.

Chung, Lawrence, Kendra Cooper, and D.T. Huynh. 2001. “COTS-Aware Requirements
Engineering Techniques.“ In Proceedings of the 2001 Workshop on Embedded Software
Technology (WEST‘01).

Cockburn, Alistair. 2001. Writing Effective Use Cases. Boston: Addison-Wesley.

Cohen, Lou. 1995. Quality Function Deployment: How to Make QFD Work for You. Reading,
MA: Addison-Wesley.

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development.
Boston: Addison-Wesley.

. 2005. Agile Estimating and Planning. Upper Saddle River, NJ: Prentice Hall.

. 2010. Succeeding with Agile: Software Development Using Scrum. Upper Saddle River,
NJ: Addison-Wesley.

Collard, Ross. 1999. “Test Design.” Software Testing & Quality Engineering 1(4):30–37.

Colorado State University. 2013. “Writing@CSU.“ http://writing.colostate.edu/guides/guide
.cfm?guideid=68.

Constantine, Larry. 1998. “Prototyping from the User’s Viewpoint.” Software Development
6(11):51–57.

Constantine, Larry L., and Lucy A. D. Lockwood. 1999. Software for Use: A Practical Guide to the
Models and Methods of Usage-Centered Design. Reading, MA: Addison-Wesley.

Cooper, Alan. 2004. The Inmates Are Running the Asylum: Why High-Tech Products Drive Us
Crazy and How to Restore the Sanity. Indianapolis, IN: Sams Publishing.

Covey, Stephen R. 2004. The 7 Habits of Highly Effective People. New York: Free Press.

Davenport, Thomas H., ed. 2013. Enterprise Analytics: Optimize Performance, Process, and
Decisions through Big Data. Upper Saddle River, NJ: Pearson Education, Inc.

Davenport, Thomas H., Jeanne G. Harris, and Robert Morrison. 2010. Analytics at Work: Smarter
Decisions, Better Results. Boston: Harvard Business Review Press.

Davis, Alan M. 1993. Software Requirements: Objects, Functions, and States, Revised Edition.
Englewood Cliffs, NJ: Prentice Hall PTR.

References 607

. 1995. 201 Principles of Software Development. New York: McGraw-Hill.

. 2005. Just Enough Requirements Management: Where Software Development Meets
Marketing. New York: Dorset House Publishing.

DeGrace, Peter, and Leslie Hulet Stahl. 1993. The Olduvai Imperative: CASE and the State of
Software Engineering Practice. Englewood Cliffs, NJ: Yourdon Press/Prentice Hall.

Dehlinger, Josh, and Robyn R. Lutz. 2008. “Supporting Requirements Reuse in Multi-Agent
System Product Line Design and Evolution.“ In Proceedings of the 24th IEEE International
Conference on Software Maintenance, 207–216. Los Alamitos, CA: IEEE Computer Society
Press.

DeMarco, Tom. 1979. Structured Analysis and System Specification. Upper Saddle River,
NJ: Prentice Hall PTR.

DeMarco, Tom, and Timothy Lister. 1999. Peopleware: Productive Projects and Teams, 2nd ed.
New York: Dorset House Publishing.

Denne, Mark, and Jane Cleland-Huang. 2003. Software by Numbers: Low-Risk, High-Return
Development. Santa Clara, CA: Sun Microsystems Press/Prentice Hall.

Derby, Esther, and Diana Larsen. 2006. Agile Retrospectives: Making Good Teams Great. Raleigh,
NC: The Pragmatic Bookshelf.

Devine, Tom. 2008. “Replacing a Legacy System.“ http://www.richconsulting.com/our/pdfs/
RichConsulting_ReplacingLegacy.pdf.

Douglass, Bruce Powel. 2001. “Capturing Real-Time Requirements.“ Embedded Systems
Programming (November 2001). http://www.embedded.com/story/OEG20011016S0126.

Dyché, Jill. 2012. “The 7 Steps in Big Data Delivery.“ http://www.networkworld.com/news/
tech/2012/071112-big-data-delivery-260813.html.

Engblom, Jakob. 2007. “Using Simulation Tools For Embedded Systems Software Development:
Part 1.“ Embedded Systems Programming (May 2007). http://www.embedded.com/
design/real-time-and-performance/4007090/Using-simulation-tools-for-embedded-
systems-software-development-Part-1.

Ericson II, Clifton A. 2005. Hazard Analysis Techniques for System Safety. Hoboken,
NJ: John Wiley & Sons, Inc.

. 2011. Fault Tree Analysis Primer. Charleston, NC: CreateSpace.

. 2012. Hazard Analysis Primer. Charleston, NC: CreateSpace.

Fagan, Michael E. 1976. “Design and Code Inspections to Reduce Errors in Program
Development.” IBM Systems Journal 15(3):182–211.

Ferdinandi, Patricia L. 2002. A Requirements Pattern: Succeeding in the Internet Economy.
Boston: Addison-Wesley.

Firesmith, Donald. 2004. “Specifying Reusable Security Requirements.“ Journal of Object
Technology 3(1):61–75.

608 References

Fisher, Roger, William Ury, and Bruce Patton. 2011. Getting to Yes: Negotiating Agreement 609
Without Giving In. New York: Penguin Books.

Florence, Al. 2002. “Reducing Risks Through Proper Specification of Software Requirements.”
CrossTalk 15(4):13–15.

Fowler, Martin. 1999. Refactoring: Improving the Design of Existing Code. Reading,
MA: Addison-Wesley.

. 2003. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed.
Boston: Addison-Wesley.

Franks, Bill. 2012. Taming the Big Data Tidal Wave: Finding Opportunities in Huge Data Streams
with Advanced Analytics. Hoboken, NJ: John Wiley & Sons, Inc.

Frye, Colleen. 2009. “New Requirements Definition Tools Focus on Chronic Flaws.“ TechTarget.
http://searchsoftwarequality.techtarget.com/news/1354455/New-requirements-
definition-tools-focus-on-chronic-flaws.

GAO (Government Accounting Office). 2004. “Stronger Management Practices Are Needed to
Improve DOD‘s Software-Intensive Weapon Acquisitions.“ GAO-04-393, http://www.gao
.gov/products/GAO-04-393.

Garmahis, Michael. 2009. “Top 20 Wireframe Tools.“ http://garmahis.com/reviews/wireframe-tools.

Gause, Donald C., and Brian Lawrence. 1999. “User-Driven Design.” Software Testing & Quality
Engineering 1(1):22–28.

Gause, Donald C., and Gerald M. Weinberg. 1989. Exploring Requirements: Quality Before
Design. New York: Dorset House Publishing.

Gilb, Tom. 1988. Principles of Software Engineering Management. Harlow, England:
Addison-Wesley.

. 1997. “Quantifying the Qualitative: How to Avoid Vague Requirements by Clear
Specification Language.” Requirenautics Quarterly 12:9–13.

. 2005. Competitive Engineering: A Handbook for Systems Engineering, Requirements
Engineering, and Software Engineering Using Planguage. Oxford, England: Elsevier
Butterworth-Heinemann.

. 2007. “Requirements for Outsourcing.“ Methods and Tools (Winter 2007).

Gilb, Tom, and Kai Gilb. 2011. “User Stories: A Skeptical View.“ Agile Record 6:52–54.

Gilb, Tom, and Dorothy Graham. 1993. Software Inspection. Wokingham, England:
Addison-Wesley.

Glass, Robert L. 1992. Building Quality Software. Englewood Cliffs, NJ: Prentice Hall.

Gomaa, Hassan. 2004. Designing Software Product Lines with UML: From Use Cases to
Pattern-Based Software Architectures. Boston: Addison-Wesley.

Gorman, Mary, and Ellen Gottesdiener. 2011. “It’s the Goal, Not the Role: The Value of Business
Analysis in Scrum.“ http://www.stickyminds.com/s.asp?F=S16902_COL_2.

References

Gottesdiener, Ellen. 2001. “Decide How to Decide.” Software Development 9(1):65–70.

. 2002. Requirements by Collaboration: Workshops for Defining Needs.
Boston: Addison-Wesley.

. 2005. The Software Requirements Memory Jogger. Salem, NH: Goal/QPC.

. 2009. “Agile Business Analysis in Flow: The Work of the Agile Analyst (Part 2).“
http://ebgconsulting.com/Pubs/Articles.

Grady, Robert B. 1999. “An Economic Release Decision Model: Insights into Software Project
Management.” In Proceedings of the Applications of Software Measurement Conference,
227–239. Orange Park, FL: Software Quality Engineering.

Grady, Robert B., and Tom Van Slack. 1994. “Key Lessons in Achieving Widespread Inspection
Use.” IEEE Software 11(4):46–57.

Graham, Dorothy. 2002. “Requirements and Testing: Seven Missing-Link Myths.” IEEE Software
19(5):15–17.

Grochow, Jerrold M. 2012. “IT Planning for Business Analytics.“ International Institute for
Analytics Brief.

Ham, Gary A. 1998. “Four Roads to Use Case Discovery: There Is a Use (and a Case) for Each
One.” CrossTalk 11(12):17–19.

Hammer, Michael, and Graham Champy. 2006. Reengineering the Corporation: A Manifesto for
Business Revolution. New York: HarperCollins.

Hardy, Terry L. 2011. Essential Questions in System Safety: A Guide for Safety Decision Makers.
Bloomington, IN: AuthorHouse.

Harmon, Paul. 2007. Business Process Change: A Guide for Business Managers and BPM and Six
Sigma Professionals, 2nd ed. Burlington, MA: Morgan Kaufmann Publishers, Inc.

Harrington, H. James. 1991. Business Process Improvement: The Breakthrough Strategy for Total
Quality, Productivity, and Competitiveness. New York: McGraw-Hill.

Haskins, B., J. Stecklein, D. Brandon, G. Moroney, R. Lovell, and J. Dabney. 2004. ‘‘Error
Cost Escalation through the Project Life Cycle.’’ In Proceedings of the 14th Annual
International Symposium of INCOSE. Toulouse, France. International Council on Systems
Engineering.

Hatley, Derek, Peter Hruschka, and Imtiaz Pirbhai. 2000. Process for System Architecture and
Requirements Engineering. New York: Dorset House Publishing.

Herrmann, Debra S. 1999. Software Safety and Reliability: Techniques, Approaches, and
Standards of Key Industrial Sectors. Los Alamitos, CA: IEEE Computer Society Press.

Hoffman, Cecilie, and Rebecca Burgess. 2009. “Use and Profit from Peer Reviews on Business
Requirements Documents.“ Business Analyst Times (September–December 2009).

Hofmann, Hubert F., and Franz Lehner. 2001. “Requirements Engineering as a Success Factor in
Software Projects.” IEEE Software 18(4):58–66.

610 References

Hooks, Ivy F., and Kristin A. Farry. 2001. Customer-Centered Products: Creating Successful 611
Products Through Smart Requirements Management. New York: AMACOM.

Hsia, Pei, David Kung, and Chris Sell. 1997. “Software Requirements and Acceptance Testing.”
In Annals of Software Engineering. 3:291–317.

Humphrey, Watts S. 1989. Managing the Software Process. Reading, MA: Addison-Wesley.

IEEE. 1998. “IEEE Std 1061-1998: IEEE Standard for a Software Quality Metrics Methodology.”
Los Alamitos, CA: IEEE Computer Society Press.

IFPUG. 2010. Function Point Counting Practices Manual, Version 4.3.1. Princeton Junction,
NJ: International Function Point Users Group.

IIBA. 2009. A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0.
Toronto: International Institute of Business Analysis.

. 2010. IIBA Business Analysis Self-Assessment. Toronto: International Institute of
Business Analysis.

. 2011. IIBA Business Analysis Competency Model, Version 3.0. Toronto: International
Institute of Business Analysis.

. 2013. IIBA Agile Extension to the BABOK Guide, Version 1.0. Toronto: International
Institute of Business Analysis.

Imhoff, Claudia. 2005. “Charting a Smooth Course to BI Implementation.“ Intelligent Solutions,
Inc. http://www.sas.com/reg/wp/corp/3529.

INCOSE. 2010. “INCOSE Requirements Management Tools Survey.” http://www.incose.org/
productspubs/products/rmsurvey.aspx.

International Institute for Analytics. 2013. “Analytics 3.0.“ International Institute for Analytics.
http://iianalytics.com/a3.

ISO/IEC. 2007. “ISO/IEC 25030:2007, Software engineering—Software product Quality
Requirements and Evaluation (SQuaRE)—Quality Requirements.“ Geneva, Switzerland:
International Organization for Standardization.

. 2011. “ISO/IEC 25010:2011, Systems and software engineering—Systems and software
Quality Requirements and Evaluation (SQuaRE)—System and software quality models.“
Geneva, Switzerland: International Organization for Standardization.

ISO/IEC/IEEE. 2011. “ISO/IEC/IEEE 29148:2011(E), Systems and software engineering—Life cycle
processes—Requirements engineering.“ Geneva, Switzerland: International Organization
for Standardization.

Jacobson, Ivar, Grady Booch, and James Rumbaugh. 1999. The Unified Software Development
Process. Reading, MA: Addison-Wesley.

Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard. 1992. Object-Oriented
Software Engineering: A Use Case Driven Approach. Harlow, England: Addison-Wesley.

Jarke, Matthias. 1998. “Requirements Tracing.” Communications of the ACM 41(12):32–36.

References

Jeffries, Ron, Ann Anderson, and Chet Hendrickson. 2001. Extreme Programming Installed.
Boston: Addison-Wesley.

Johnson, Jeff. 2010. Designing with the Mind in Mind: Simple Guide to Understanding User
Interface Design Rules. San Francisco, CA: Morgan Kaufmann Publishers, Inc.

Jones, Capers. 1994. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice
Hall PTR.

. 1996a. “Strategies for Managing Requirements Creep.” IEEE Computer 29(6):92–94.

. 1996b. Applied Software Measurement, 2nd ed. New York: McGraw-Hill.

. 2006. “Social and Technical Reasons for Software Project Failures.“ CrossTalk 19(6):4–9.

Jung, Ho-Won. 1998. “Optimizing Value and Cost in Requirements Analysis.” IEEE Software
15(4):74–78.

Karlsson, Joachim, and Kevin Ryan. 1997. “A Cost-Value Approach for Prioritizing
Requirements.” IEEE Software 14(5):67–74.

Kavi, Krishna M., Robert Akl, and Ali R. Hurson. 2009. “Real-Time Systems: An Introduction
and the State-of-the-Art.“ Wiley Encyclopedia of Computer Science and Engineering,
2369–2377.

Keil, Mark, and Erran Carmel. 1995. “Customer-Developer Links in Software Development.”
Communications of the ACM 38(5):33–44.

Kelly, John C., Joseph S. Sherif, and Jonathon Hops. 1992. “An Analysis of Defect Densities
Found During Software Inspections.” Journal of Systems and Software 17(2):111–117.

Kerth, Norman L. 2001. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset
House Publishing.

Kleidermacher, David, and Mike Kleidermacher. 2012. Embedded Systems Security: Practical
Methods for Safe and Secure Software and Systems Development. Waltham, MA: Elsevier Inc.

Koopman, Philip. 2010. Better Embedded Systems Software. Pittsburgh, PA: Drumnadrochit
Press.

Kosman, Robert J. 1997. “A Two-Step Methodology to Reduce Requirement Defects.” In Annals
of Software Engineering. 3:477–494.

Kovitz, Benjamin L. 1999. Practical Software Requirements: A Manual of Content and Style.
Greenwich, CT: Manning Publications Co.

Krug, Steve. 2006. Don‘t Make Me Think: A Common Sense Approach to Web Usability, 2nd ed.
Berkeley, CA: New Riders Publishing.

Kukreja, Nupul, Sheetal Swaroop Payyavula, Barry Boehm, and Srinivas Padmanabhuni. 2012.
“Selecting an Appropriate Framework for Value-Based Requirements Prioritization:
A Case Study.“ In Proceedings of the 20th IEEE International Requirements Engineering
Conference, 303–308. Los Alamitos, CA: IEEE Computer Society Press.

612 References

Kulak, Daryl, and Eamonn Guiney. 2004. Use Cases: Requirements in Context, 2nd ed.
Boston: Addison-Wesley.

Larman, Craig. 1998. “The Use Case Model: What Are the Processes?” Java Report 3(8):62–72.

. 2004. Agile and Iterative Development: A Manager‘s Guide. Boston: Addison-Wesley.

Larman, Craig, and Victor R. Basili. 2003. “Iterative and Incremental Development: A Brief
History.“ IEEE Computer 36(6):47–56.

Lauesen, Soren. 2002. Software Requirements: Styles and Techniques. London: Addison-Wesley.

Lavi, Jonah Z., and Joseph Kudish. 2005. Systems Modeling & Requirements Specification Using
ECSAM: An Analysis Method for Embedded and Computer-Based Systems. New York:
Dorset House Publishing.

Lawlis, Patricia K., Kathryn E. Mark, Deborah A. Thomas, and Terry Courtheyn. 2001. “A Formal
Process for Evaluating COTS Software Products.” IEEE Computer 34(5):58–63.

Lawrence, Brian. 1996. “Unresolved Ambiguity.” American Programmer 9(5):17–22.

. 1997. “Requirements Happens. . .” American Programmer 10(4):3–9.

Lazar, Jonathan. 2001. User-Centered Web Development. Sudbury, MA: Jones and Bartlett
Publishers.

Leffingwell, Dean. 1997. “Calculating the Return on Investment from More Effective
Requirements Management.” American Programmer 10(4):13–16.

. 2011. Agile Software Requirements: Lean Requirements Practices for Teams, Programs,
and the Enterprise. Upper Saddle River, NJ: Addison-Wesley.

Leffingwell, Dean, and Don Widrig. 2000. Managing Software Requirements: A Unified
Approach. Reading, MA: Addison-Wesley.

Leishman, Theron R., and David A. Cook. 2002. “Requirements Risks Can Drown Software
Projects.” CrossTalk 15(4):4–8.

Leveson, Nancy. 1995. Safeware: System Safety and Computers. Reading, MA: Addison-Wesley.

Lilly, Susan. 2000. “How to Avoid Use-Case Pitfalls.” Software Development 8(1):40–44.

Martin, Johnny, and W. T. Tsai. 1990. “N-fold Inspection: A Requirements Analysis Technique.”
Communications of the ACM 33(2):225–232.

Mavin, Alistair, Philip Wilkinson, Adrian Harwood, and Mark Novak. 2009. “EARS (Easy
Approach to Requirements Syntax).“ In Proceedings of the 17th International Conference
on Requirements Engineering, 317–322. Los Alamitos, CA: IEEE Computer Society Press.

McConnell, Steve. 1996. Rapid Development: Taming Wild Software Schedules. Redmond,
WA: Microsoft Press.

. 1997. “Managing Outsourced Projects.“ Software Development 5(12):80, 78–79.

. 1998. Software Project Survival Guide. Redmond, WA: Microsoft Press.

References 613

. 2004. Code Complete: A Practical Handbook of Software Construction, 2nd ed.
Redmond, WA: Microsoft Press.
. 2006. Software Estimation: Demystifying the Black Art. Redmond, WA: Microsoft Press.
McGraw, Karen L., and Karan Harbison. 1997. User-Centered Requirements: The Scenario-Based
Engineering Process. Mahwah, NJ: Lawrence Erlbaum Associates.
Miller, Roxanne E. 2009. The Quest for Software Requirements. Milwaukee, WI: MavenMark
Books.
Moore, Geoffrey A. 2002. Crossing the Chasm: Marketing and Selling High-Tech Products to
Mainstream Customers. New York: HarperBusiness.
Morgan, Matthew. 2009. “Requirements Definition for Outsourced Teams.“ Business Analyst
Times. http://www.batimes.com/articles/requirements-definition-for-outsourced-teams
.html.
Morgan, Tony. 2002. Business Rules and Information Systems: Aligning IT with Business Goals.
Boston: Addison-Wesley.
Musa, John D. 1996. “Software-Reliability-Engineered Testing.” IEEE Computer 29(11):61–68.
. 1999. Software Reliability Engineering. New York: McGraw-Hill.
NASA. 2009. “NPR 7150.2A: NASA Software Engineering Requirements.“ http://nodis3.gsfc
.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7150_002A_&page_name=AppendixA.
Nejmeh, Brian A., and Ian Thomas. 2002. “Business-Driven Product Planning Using Feature
Vectors and Increments.” IEEE Software 19(6):34–42.
Nelsen, E. Dale. 1990. “System Engineering and Requirement Allocation.” In System and
Software Requirements Engineering, Richard H. Thayer and Merlin Dorfman, eds.
Los Alamitos, CA: IEEE Computer Society Press.
Nielsen, Jakob. 2000. Designing Web Usability. Indianapolis, IN: New Riders Publishing.
OMG. 2011. Business Process Model and Notation (BPMN) version 2.0. Object Management
Group. http://www.omg.org/spec/BPMN/2.0.
Pardee, William J. 1996. To Satisfy & Delight Your Customer: How to Manage for Customer
Value. New York: Dorset House Publishing.
Patel, T., and James Taylor. 2010. “Business Analytics 101: Unlock the Business Intelligence Hidden
in Company Databases.“ http://www.sas.com/resources/whitepaper/wp_28372.pdf.
Patterson, Kelly, Joseph Grenny, Ron McMillan, and Al Switzler. 2011. Crucial Conversations:
Tools for Talking When Stakes are High, 2nd ed. New York: McGraw-Hill.
Peterson, Gary. 2002. “Risqué Requirements.” CrossTalk 15(4):31.
Pichler, Roman. 2010. Agile Product Management with Scrum: Creating Products that Customers
Love. Upper Saddle River, NJ: Addison-Wesley.

614 References

PMI. 2013. A Guide to the Project Management Body of Knowledge: PMBOK Guide, 5th ed.
Newtown Square, PA: Project Management Institute.

Podeswa, Howard. 2009. The Business Analyst‘s Handbook. Boston: Course Technology.

. 2010. UML for the IT Business Analyst: A Practical Guide to Requirements Gathering
Using the Unified Modeling Language, 2nd ed. Boston: Course Technology.

Porter, Adam A., Lawrence G. Votta, Jr., and Victor R. Basili. 1995. “Comparing Detection
Methods for Software Requirements Inspections: A Replicated Experiment.” IEEE
Transactions on Software Engineering 21(6):563–575.

Porter-Roth, Bud. 2002. Request for Proposal: A Guide to Effective RFP Development.
Boston: Addison-Wesley.

Poston, Robert M. 1996. Automating Specification-Based Software Testing. Los Alamitos,
CA: IEEE Computer Society Press.

Potter, Neil S., and Mary E. Sakry. 2002. Making Process Improvement Work: A Concise Action
Guide for Software Managers and Practitioners. Boston: Addison-Wesley.

Pugh, Ken. 2011. Lean-Agile Acceptance Test-Driven Development: Better Software Through
Collaboration. Upper Saddle River, NJ: Addison-Wesley.

Putnam, Lawrence H., and Ware Myers. 1997. Industrial Strength Software: Effective
Management Using Measurement. Los Alamitos, CA: IEEE Computer Society Press.

Radice, Ronald A. 2002. High Quality Low Cost Software Inspections. Andover, MA: Paradoxicon
Publishing.

Ramesh, Bala, Curtis Stubbs, Timothy Powers, and Michael Edwards. 1995. “Lessons Learned
from Implementing Requirements Traceability.” CrossTalk 8(4):11–15, 20.

Rettig, Marc. 1994. “Prototyping for Tiny Fingers.” Communications of the ACM 37(4):21–27.

Rierson, Leanna. 2013. Developing Safety-Critical Software: A Practical Guide for Aviation
Software and DO-178C Compliance. Boca Raton, FL: CRC Press.

Robertson, James. 2002. “Eureka! Why Analysts Should Invent Requirements.” IEEE Software
19(4):20–22.

Robertson, James, and Suzanne Robertson. 1994. Complete Systems Analysis: The Workbook,
the Textbook, the Answers. New York: Dorset House Publishing.

Robertson, Suzanne, and James Robertson. 2013. Mastering the Requirements Process: Getting
Requirements Right, 3rd ed. Upper Saddle River, NJ: Addison-Wesley.

Rose-Coutré, Robert. 2007. “Capturing Implied Requirements.“ http://www.stickyminds.com/s
.asp?F=S12998 _ ART_ 2.

Ross, Ronald G. 1997. The Business Rule Book: Classifying, Defining, and Modeling Rules, Version
4.0, 2nd ed. Houston: Business Rule Solutions, LLC.

. 2001. “The Business Rules Classification Scheme.” DataToKnowledge Newsletter 29(5).

References 615

Ross, Ronald G., and Gladys S. W. Lam. 2011. Building Business Solutions: Business Analysis with
Business Rules. Houston: Business Rule Solutions, LLC.

Rothman, Johanna. 2000. Reflections Newsletter 3(1).
Royce, Winston. 1970. “Managing the Development of Large Software Systems.“ In Proceedings

of IEEE WESCON 26, 1–9.
Rozanski, Nick, and Eoin Woods. 2005. Software Systems Architecture: Working with

Stakeholders Using Viewpoints and Perspectives. Upper Saddle River, NJ: Pearson
Education, Inc.
Rubin, Jeffrey, and Dana Chisnell. 2008. Handbook of Usability Testing: How to Plan, Design, and
Conduct Effective Tests, 2nd ed. Indianapolis, IN: Wiley Publishing, Inc.
Scalable Systems. 2008. “How Big is Your Data?“ http://www.scalable-systems.com/whitepaper/
Scalable_WhitePaper_Big_Data.pdf.
Schneider, G. Michael, Johnny Martin, and W. T. Tsai. 1992. “An Experimental Study of Fault
Detection in User Requirements Documents.” ACM Transactions on Software Engineering
and Methodology 1(2):188–204.
Schonberger, Richard. J. 2008. Best Practices in Lean Six Sigma Process Improvement: A Deeper
Look. Hoboken, NJ: John Wiley & Sons, Inc.
Schwaber, Ken. 2004. Agile Project Management with Scrum. Redmond, WA: Microsoft Press.
Schwarz, Roger. 2002. The Skilled Facilitator: A Comprehensive Resource for Consultants,
Facilitators, Managers, Trainers, and Coaches. San Francisco, CA: Jossey-Bass.
Seilevel. 2011. “Seilevel Requirements Management Tool Evaluation Results.” http://www.seilevel
.com/wp-content/uploads/2011/09/Seilevel-RequirementsManagementToolEvalResults2.xls.
. 2012. “Seilevel Project Assessment.” http://www.seilevel.com/wp-content/uploads/
Project _ Assessments _Template.xls.
Sharp, Alec, and Patrick McDermott. 2008. Workflow Modeling: Tools for Process Improvement
and Application Development. Norwood, Massachusetts: Artec, Inc.
Shehata, Mohammed S., Armin Eberlein, and H. James Hoover. 2002. ”Requirements Reuse and
Feature Interaction Management.” In Proceedings of the 15th International Conference
on Software & Systems Engineering and their Applications. Paris.
Shull, F., V. Basili, B. Boehm., A. W. Brown, A. Costa, M. Lindvall, D. Port, I. Rus, R. Tesoriero, and
M. Zelkowitz. 2002. “What We Have Learned About Fighting Defects.” In Proceedings
of the Eighth IEEE Symposium on Software Metrics, 249–258. Ottawa, Canada. IEEE
Computer Society Press.
Sibbet, David. 1994. Effective Facilitation: Achieving Results with Groups. San Francisco, CA: The
Grove Consultants International.

616 References

Simmons, Erik. 2001. “From Requirements to Release Criteria: Specifying, Demonstrating, and 617
Monitoring Product Quality.” In Proceedings of the 2001 Pacific Northwest Software
Quality Conference, 155–165. Portland, OR: Pacific Northwest Software Quality
Conference.

Smith, Larry W. 2000. “Project Clarity Through Stakeholder Analysis.” CrossTalk 13(12):4–9.

Sommerville, Ian, and Pete Sawyer. 1997. Requirements Engineering: A Good Practice Guide.
Chichester, England: John Wiley & Sons Ltd.

Sorensen, Reed. 1999. “CCB—An Acronym for ‘Chocolate Chip Brownies’? A Tutorial on Control
Boards.” CrossTalk 12(3):3–6.

The Standish Group. 2009. “Chaos Summary 2009.“ West Yarmouth, MA: The Standish Group
International, Inc.

Stevens, Richard, Peter Brook, Ken Jackson, and Stuart Arnold. 1998. Systems Engineering:
Coping with Complexity. London: Prentice Hall.

Taylor, James. 2012. “Decision Discovery for a Major Business Function.“ International Institute
for Analytics Research Brief.

. 2013. “Using Decision Discovery to Manage Analytic Project Requirements.“
International Institute for Analytics Research Brief.

Thayer, Richard H. 2002. “Software System Engineering: A Tutorial.” IEEE Computer 35(4):68–73.

Thomas, Steven. 2008. “Agile Change Management.“ http://itsadeliverything.com/agile-change-
management.

Thompson, Bruce, and Karl Wiegers. 1995. “Creative Client/ Server for Evolving Enterprises.”
Software Development 3(2):34–44.

Van Veenendaal, Erik P. W. M. 1999. “Practical Quality Assurance for Embedded Software.“
Software Quality Professional 1(3):7–18.

Voas, Jeffrey. 1999. “Protecting Against What? The Achilles Heel of Information Assurance.”
IEEE Software 16(1):28–29.

Volere. 2013. “Requirements Tools.” http://www.volere.co.uk/tools.htm.

von Halle, Barbara. 2002. Business Rules Applied: Building Better Systems Using the Business
Rules Approach. New York: John Wiley & Sons, Inc.

von Halle, Barbara, and Larry Goldberg. 2010. The Decision Model: A Business Logic Framework
Linking Business and Technology. Boca Raton, FL: Auerbach Publications.

Wallace, Dolores R., and Laura M. Ippolito. 1997. “Verifying and Validating Software
Requirements Specifications.” In Software Requirements Engineering, 2nd ed., Richard
H. Thayer and Merlin Dorfman, eds., 389–404. Los Alamitos, CA: IEEE Computer Society
Press.

Wasserman, Anthony I. 1985. “Extending State Transition Diagrams for the Specification of Human-
Computer Interaction.” IEEE Transactions on Software Engineering SE-11(8):699–713.

References