Professional Documents
Culture Documents
Introduction to Requirements
• Purpose
• Relation to Other Workflows
Concepts
• Requirements
• Requirements Management
• Types of Requirements
• Traceability
• User-Centered Design
• Use-Case View
Purpose
• To establish and maintain agreement with the customers and other stakeholders
on what the system should do.
• To provide system developers with a better understanding of the system
requirements.
• To define the boundaries of (delimit) the system.
• To provide a basis for planning the technical contents of iterations.
• To provide a basis for estimating cost and time to develop the system.
• To define a user-interface for the system, focusing on the needs and goals of the
users.
To achieve these goals, it is important, first of all, to understand the definition and scope
of the problem which we are trying to solve with this system. The Business Rules,
Business Use-Case Model and Business Object Model developed during Business
Modeling will serve as valuable input to this effort. Stakeholders are identified and
Stakeholder Requests are elicited, gathered and analyzed.
A Vision document, a use-case model, use cases and Supplementary Specification are
developed to fully describe the system - what the system will do - in an effort that views
all stakeholders, including customers and potential users, as important sources of
information (in addition to system requirements).
Stakeholder Requests are both actively elicited and gathered from existing sources to get
a "wish list" of what different stakeholders of the project (customers, users, product
champions) expect or desire the system to include, together with information on how
each request has been considered by the project.
The use-case model should serve as a communication medium and can serve as a contract
between the customer, the users, and the system developers on the functionality of the
system, which allows:
• Customers and users to validate that the system will become what they expected.
• System developers to build what is expected.
The use-case model consists of use cases and actors. Each use case in the model is
described in detail, showing step-by-step how the system interacts with the actors, and
what the system does in the use case. Use cases function as a unifying thread throughout
the software lifecycle; the same use-case model is used in system analysis, design,
implementation, and testing.
A complete definition of the software requirements described in the use cases and
Supplementary Specifications may be packaged together to define a Software
Requirements Specification (SRS) for a particular "feature" or other subsystem
grouping.
Complementary to the above mentioned artifacts, the following artifacts are also
developed:
• Glossary
• Use-Case Storyboard
• User-Interface Prototype
The Use-Case Storyboard and User-Interface Prototype are all results of user-interface
modeling and prototyping, which are done in parallel with other requirements activities.
There are a many different kinds of requirements. One way of categorizing them is
described as the FURPS+ model [GRA92], using the acronym FURPS to describe the
major categories of requirements with subcategories as shown below.
• Functionality,
• Usability,
• Reliability,
• Performance and
• Supportability
The "+" in FURPS+ helps you to also remember to also include such requirements as
• design constraints,
• implementation requirements,
• interface requirements and
• physical requirements.
Functional requirements specify actions that a system must be able to perform, without
taking physical constraints into consideration. These are often best described in a use-
case model and in use cases. Functional requirements thus specify the input and output
behavior of a system.
Requirements that are not functional, such as the ones listed below, are sometimes called
non-functional requirements. Many requirements are non-functional, and describe only
attributes of the system or attributes of the system environment. Although some of these
may be captured in use cases, those that cannot may specified in Supplementary
Specifications. Nonfunctional requirements are those that address issues such as those
described below.
For a complete definition of the software requirements, use cases and Supplementary
Specifications may be packaged together to define a Software Requirements
Specification (SRS) for a particular "feature" or other subsystem grouping.
• feature sets,
• capabilities, and
• security.
Usability
Reliability
Performance
• speed,
• efficiency,
• availability,
• accuracy,
• throughput,
• response time,
• recovery time, or
• resource usage.
Supportability
• testability,
• extensibility,
• adaptability,
• maintainability,
• compatibility,
• configurability,
• serviceability,
• installability, or
• localizability (internationalization).
Design Requirement
A design requirement, often called a design constraint, specifies or constrains the design
of a system.
Implementation Requirement
• required standards,
• implementation languages,
• policies for database integrity,
• resource limits, and
• operation environments.
Interface Requirement
Physical Requirement
A physical requirement specifies a physical characteristic that a system must possess; for
example,
• material,
• shape,
• size, and
• weight.
Collecting requirements may sound like a rather straightforward task. In real projects,
however, you will run into difficulties because:
• Requirements are not always obvious, and can come from many sources.
• Requirements are not always easy to express clearly in words.
• There are many different types of requirements at different levels of detail.
• The number of requirements can become unmanageable if not controlled.
• Requirements are related to one another and also to other deliverables of the
software engineering process.
So, what skills do you need to develop in your organization to help you manage these
difficulties? We have learned that the following skills are important to master:
• Problem analysis
• Understanding stakeholder needs
• Defining the system
• Managing scope of the project
• Refining the system definition
• Managing changing requirements
Problem Analysis
Problem analysis is done to understand problems, initial stakeholder needs, and propose
high-level solutions. It is an act of reasoning and analysis to find "the problem behind the
problem". During problem analysis, agreement is gained on the real problem(s), and who
the stakeholders are. Also, you define what from a business perspective are the
boundaries of the solution, as well as business constraints on the solution. You should
also have analyzed the business case for the project so that there is a good understanding
of what return is expected on the investment made in the system being built.
Requirements come from many sources, examples would be customers, partners, end
users, and domain experts. You need to know how to best determine what the sources
should be, get access to those sources, and also how to best elicit information from them.
The individuals who provide the primary sources for this information are referred to as
stakeholders in the project. If you’re developing an information system to be used
internally within your company, you may include people with end user experience and
business domain expertise in your development team. Very often you will start the
discussions at a business model level rather than a system level. If you’re developing a
product to be sold to a market place, you may make extensive use of your marketing
people to better understand the needs of customers in that market.
To define the system means to translate and organize the understanding of stakeholder
needs into a meaningful description of the system to be built. Early in system definition,
decisions are made on what constitutes a requirement, documentation format, language
formality, degree of requirements specificity (how many and in what detail), request
priority and estimated effort (two very different valuations usually assigned by different
people in separate exercises), technical and management risks, and initial scope. Part of
this activity may include early prototypes and design models directly related to the most
important stakeholder requests. The outcome of system definition is a description of the
system that is both natural language and graphical.
To efficiently run a project, you need to carefully prioritize the requirements, based on
input from all stakeholders, and manage its scope. Too many projects suffer from
developers working on so called "Easter eggs" (features the developer finds interesting
and challenging), rather than early focusing on tasks that mitigate a risk in the project or
stabilize the architecture of the application. To make sure that you resolve or mitigate
risks in a project as early as possible, you should develop your system incrementally,
carefully choosing requirements to for each increment that mitigates known risks in the
project. To do so, you need to negotiate the scope (of each iteration) with the
stakeholders of the project. This typically requires good skills in managing expectations
of the output from the project in its different phases. You also need to have control of the
sources of requirements, of how the deliverables of the project look, as well as the
development process itself.
The detailed definition of the system needs to be presented in such a way that your
stakeholders can understand, agree to, and sign off on them. It needs to cover not only
functionality, but also compliance with any legal or regulatory requirements, usability,
reliability, performance, supportability, and maintainability. An error often committed is
to believe that what you feel is complex to build needs to have a complex definition. This
leads to difficulties in explaining the purpose of the project and the system. People may
be impressed, but they will not give good input since they don’t understand. You should
put lots effort in understanding the audience for the documents you are producing to
describe the system. You may often see a need to produce different kinds of description
for different audiences.
Another component of the detailed definition of the system is to state how the system
should be tested. Test plans and definitions of what tests to perform tells us what system
capabilities will be verified.
No matter how careful you are about defining your requirements, there will always be
things that change. What makes changing requirements complex to manage is not only
that a changed requirement means that more or less time has to be spent on implementing
a particular new feature, but also that a change to one requirement may have an impact on
other requirements. You need to make sure that you give your requirements a structure
that is resilient to changes, and that you use traceability links to represent dependencies
between requirements and other artifacts of the development lifecycle. Managing change
include activities like establishing a baseline, determining which dependencies are
important to trace, establishing traceability between related items, and change control.
Traditionally, requirements are looked upon as statements of text fitting into one of the
categories mentioned in Concepts: Requirements. Each requirement states "a condition or
capability to which the system must conform".
We may want to keep track of ambiguous "wishes", as well as formal requests, from our
stakeholders to make sure we know how they are taken care of. The Vision document
helps us keep track of key "user needs" and "features" of the system. The use-case model
is an effective way of expressing detailed functional "software requirements", therefore
use cases may need to be tracked and maintained as requirements, as well as perhaps
individual statements within the use case properties which state "conditions or
capabilities to which the system must conform". Supplementary Specifications may
contain other "software requirements", such as design constraints or legal or regulatory
Test cases are ways of stating how we will verify what the system actually does, and
therefore we may also want to track these by maintaining separate "test requirements".
Similarly, we may wish to track "documentation requirements" for those requirements
relating to how a technical writer may need to develop end-user support documentation
and training material.
The larger and more intricate the system developed, the more expressions, or types of
requirements appear and the greater the volume of requirements. "Business rules" and
"vision" statements for a project trace to "user needs", "features" or other "product
requirements". Use cases or other forms of modeling and other Supplementary
Specifications drive design requirements, which may be further decomposed to functional
and non-functional "software requirements" represented in analysis & design models and
diagrams. "Test requirements" derived from the above decompose to test procedures and
other testing artifacts.
• Concepts: Requirements
• Concepts: Requirement Management
• Concepts: Types of Requirements
• Guidelines: Going from Business Models to Systems
• White Paper: Applying Requirements Management with Use Cases
• White Paper: Traceability Strategies for Managing Requirements with Use Cases
Traceability helps you understand and manage how input to the requirements, such as
business rules and stakeholder requests, are translated into a set of key stakeholder/user
needs and system features, as specified in the Vision document. The use-case model, in
Traceabilities may be set up to help answer the following sample set of queries:
Example:
For a Recycling Machine system, the Vision document specifies the following feature:
• FEAT10:The recycling machine will allow the addition of new bottle types.
• The use case Add New Bottle Type allows the Operator to teach the Recycling
Machine to recognize new kinds of bottles.
This traceability helps us verify that all features have been accounted for in use cases and
supplementary specifications.
• Introduction
• Business Models and System Architecture
• Business Models and Actors to the System
• Automated Business Workers
• Business Models and Entity Classes in the Analysis Model
• Interaction between Business Workers Translated to System Requirements
• Using the Business Object Model for Resource Planning
• Summary Table
Introduction
The approach to business modeling presented in the Rational Unified Process includes a
concise and straightforward way to generate requirements for supporting business tools
or systems. A good understanding of business processes is important for building the
right systems. Even more value is added if you use people's roles and responsibilities, as
well as definitions of what "things" are handled by the business as a basis for building the
system. It’s from this more internal view of the business, captured in a business object
model, that you can see the tightest link to what the models of the system needs to look
like.
The relation between models of the business and models of a supporting information
system
The business models give input to the use-case view and the logical view as presented in
the analysis model. You can also find key mechanisms at the analysis level, which are
referred to as analysis mechanisms.
• For each business use case that will be supported by the system, identify a
subsystem in the analysis model. This subsystem is in the application layer and is
considered a first prototype iteration. For example, if you have an Order process
and a Billing process in your business use-case model, identify an Order
subsystem and a Billing subsystem in the application layer of your analysis
model. You may argue that Order and Billing are separate systems. Well, that’s a
matter of scope. If you’re considering all of your business tools as one system
with several applications that share architecture, Order and Billing would be
application subsystems. If your scope is to build an Order Management
application only, then Order Management would be your system and the
recommendation above would not make sense. It only makes sense if your scope
is such that you consider all business tools in your organization as one system.
• For each business worker supported by the system, identify use cases that
represent what is to be automated.
• For each business entity supported by the system, identify entity classes in the
analysis model. Some of these are candidates for being considered as key
mechanisms, the component entities, in the system.
• For clusters of business entities—a group of business entities that are used solely
within one business use case or a group of otherwise closely related business
entities—create a subsystem in the business specific layer.
For each business worker, identify a candidate system actor. For each business use case
the business actor participates in, create a candidate system use case.
To identify information-system use cases, begin with the business workers in the business
object model. For each business worker, perform the following steps:
Example:
Based on business models of a bank, you can derive candidate system actors and system
use cases.
If you are aiming at building a system that completely automates a set of business
processes—which is the case if you are building an e-commerce application—for
example, it’s no longer the business worker who will become the system actor. Instead,
it’s the business actor who will directly communicate with the system and act as a system
actor.
You are, in effect, changing the way business is performed when building an application
of this kind. Responsibilities of the business worker will be moved to the business actor.
Example:
When building an e-commerce site for a bank, you will be modifying the way the process
is realized.
For each business entity, create a class in the system's analysis model
Example:
How should you interpret a link between workers in the business model? You must find
out how the information systems can support the communicating workers. An
information system can eliminate the need to transport information between workers by
making the information available in the information system.
If you intend to use the business object model for resource planning or as a basis for
simulation, you will need to update it to reflect what types of resources are used. You
need to modify it so that each business worker and business entity is implemented by
only one type of resource. If you’re aim is to re-engineer the business process, in the first
iteration of your business object model, you should not consider resources. Doing so
tends to make you focus on the already existing solutions, rather than on identifying
• In a first iteration of the business object model, work without considering the
resources or the systems that will be used to implement the business.
• Discuss what can be automated.
• Discuss how automation can change the business process and start sketching out a
system use-case model and system requirements.
• In a second iteration to the business object model, update it to reflect resources
used and what is to be automated.
o Some business workers will be tagged as automated workers.
o Some business workers will be split into two—one automated, the other
one not.
o Parts of two business workers may be partitioned out to a new automated
worker.
o Parts of a business worker’s responsibility may be moved outside of the
organization to become the responsibility of a business actor.
Example:
In the banking example, we decided to update the business object model in order to use it
for resource planning.
Summary Table
The following table summarizes the relationship between the business models and the
system models.
If you are new to or somewhat familiar with requirements management and are interested in
requirements process improvement, this paper offers a framework with which to develop your
own approach
So how do we explain the high incidence of the software project failure today? Why are
many, if not most, software projects still plagued by delays, budget overruns, and quality
problems? How can we improve the quality of the systems we build as our businesses,
national economies, and daily activities become increasingly dependent on them?
The answers, as always, lie in the people, tools, and processes applied to our profession.
Requirements management is often proposed as a solution to the ongoing problems of
This paper presents the elements of an effective requirements management process and
highlights some of the obstacles to its successful implementation.
• The Standish Group’s CHAOS Reports from 1994 and 1997 established that the
most significant contributors to project failure relate to requirements. [1]
• In December 1997, Computer Industry Daily reported on a Sequent Computer
Systems, Inc. study of 500 IT managers in the U.S. and U.K. that found 76
percent of the respondents had experienced complete project failure during their
careers. The most frequently named cause of project failure was "changing user
requirements." [2]
What is a Requirement?
The first step towards understanding requirements management is to agree on a common
vocabulary. Rational defines a requirement as "a condition or capability to which the
system [being built] must conform." The Institute of Electronics and Electrical Engineers
uses a similar definition.
This definition is similar to Dorfman and Thayer’s and the IEEE’s definition of "software
requirements engineering." Requirements Engineering includes elicitation, analysis,
specification, verification, and management of the software requirements, with "software
requirements management" being the planning and controlling of all these related
activities [4]. All of these activities are incorporated in the definition of requirements
management presented here and taught by Rational Software. The difference lies mainly
in the choice of the word "management" rather than "engineering." Management is a
more appropriate description of all the activities involved, and it accurately emphasizes
the importance of tracking changes to maintain agreements between stakeholders and the
project team.
For those unfamiliar with the term "elicitation," it is defined as the set of activities that
teams employ to elicit or discover stakeholder requests, determine the real needs behind
the requests and a suitable set of requirements that might be placed on the system to meet
those needs.
When these problems are combined with inadequate requirements management and
process skills, and the lack of easy-to-use tools, many teams despair of ever managing
requirements well. Rational Software has developed the expertise to instruct teams in
requirements management skills and process. In addition, Rational Requisite®Pro is an
accessible tool for automating effective requirements management.
During problem analysis, agreement is gained on a statement of the real problems and the
stakeholders are identified. Initial solution boundaries and constraints are defined from
both technical and business perspectives. If appropriate, the business case for the project
analyzes return on investment that is expected from the system.
Requirements have many sources. They may come from anyone with an interest in the
outcome of the project. Customers, partners,
end users, and domain experts are some sources of requirements. Management, project
team members, business policies, and regulatory agencies can be others.
It is important to know how to determine who the sources should be, how to get access to
those sources, and how to elicit information from them. The individuals who serve as
primary sources for this information are referred to as "stakeholders" in the project.
To define the system means to translate and organize the understanding of stakeholder
needs into a meaningful description of the system to be built. Early in system definition,
decisions are made on what constitutes a requirement, documentation format, language
formality, degree of requirements, request priority and estimated effort, technical and
management risks, and scope. Part of this activity may include early prototypes and
design models directly related to the most important stakeholder requests.
We use the word "description" rather than "document" to avoid the perceived limitation
inherent in the common use of the latter. A description may be a written document,
electronic file, a picture, or any other representation meant to communicate system
requirements short of the system itself.
The outcome of system definition is a description of the system that is both natural
language and graphical. Some suggested formats for the description are provided in later
sections.
If you write the formal model first, the tendency will be to write natural
language that describes the model instead of the solution system. Consider
the following examples:
To make a long distance call, the user should lift the phone. The system shall
respond with a dial tone. The user should dial a "9". The system shall respond
with a distinctive dial tone…
The system consists of four states: Idle, Dial Tone, Distinctive Dial Tone,
and Connected. To get from the idle state to the dial tone state, lift the phone.
To get from the dial tone state to the distinctive dial tone state, dial a "9."
The scope of a project is defined by the set of requirements allocated to it. Managing
project scope to fit the available resources (time, people, and money) is key to managing
successful projects. Managing scope is a continuous activity that requires iterative or
incremental development, which breaks project scope into smaller more manageable
pieces.
Using requirement attributes, such as priority, effort, and risk, as the basis for negotiating
the inclusion of a requirement is a particularly useful technique for managing scope.
Focusing on the attributes rather than the requirements themselves helps desensitize
negotiations that are otherwise contentious.
It is also helpful for team leaders to be trained in negotiation skills and for the project to
have a champion in the organization, as well as on the customer side. Product/project
champions should have the organizational power to refuse scope changes beyond the
available resources or to expand resources to accommodate additional scope.
With an agreed-upon high-level system definition and a fairly well understood initial
scope, it is both possible and economical to invest resources in more refined system
definitions. Refining the system definition includes two key considerations: developing
more detailed descriptions of the high-level system definition, and verifying that the
system will comply with stakeholder needs and behave as described.
The descriptions are often the critical reference materials for project teams. Descriptions
are best done with the audience in mind. A common mistake is to represent what is
complex to build with a complex definition, particularly when the audience may be
unable or unwilling to invest the critical thinking necessary to gain agreement. This leads
to difficulties in explaining the purpose of the system to people both inside and outside
the project team. Instead, you may discover the need to produce different kinds of
descriptions for different audiences. This paper includes suggested formats for detailed
natural language, formal text, and graphical descriptions. Once the description format is
established, refinement continues throughout the project lifecycle.
No matter how carefully you define your requirements, they will change. In fact, some
requirement change is desirable! It means that your team is engaging your stakeholders.
A changed requirement means that more or less time has to be spent on implementing a
particular feature, and a change to one requirement may have an impact on other
requirements. Managing requirement change includes activities such as establishing a
baseline, keeping track of the history of each requirement, determining which
dependencies are important to trace, establishing traceable relationships between related
items, and maintaining version control. As Figure 3 illustrates, it is also important to
establish a change control or approval process, requiring all proposed changes to be
reviewed by designated team members. Sometimes this single channel of change control
is called a Change Control Board (CCB).
• Requirements types
• Cross-functional teams
• Traceability
• Multi-dimensional attributes
Requirement Types
The larger and more intricate the system, the more types of requirements appear. A
requirement type is simply a class of requirements. By identifying types of requirements,
teams can organize large numbers of requirements into meaningful and more manageable
groups. Establishing different types of requirements in a project helps team members
classify requests for changes and communicate more clearly.
Usually, one type of requirement can be broken down, or decomposed, into other types.
Business rules and vision statements can be types of high-level requirements from which
teams derive user needs, features, and product requirement types. Use cases and other
forms of modeling drive design requirements that can be decomposed to software
requirements and represented in analysis & design models. Test requirements are derived
from the software requirements and decompose to specific test procedures. When there
are hundreds, thousands, or even tens of thousands of instances of requirements in a
given project, classifying requirements into types makes the project more manageable.
Cross-Functional Teams
Unlike other processes, such as testing or application modeling, which can be managed
within a single business group, requirements management should involve everyone who
can contribute their expertise to the development process. It should include people who
represent the customer and the business expectations. Development managers, product
managers, analysts, systems engineers, and even customers should participate.
Requirements teams should also include those who create the system solution –
engineers, architects, designers, programmers, technical writers, and other technical
contributors. Testers and other QA personnel should be counted as important team
members.
Often, the responsibility for authoring and maintaining a requirement type can be
allocated by functional area, further contributing to better large project management. The
cross-functional nature of requirements management is one of the more challenging
aspects of the discipline.
Traceability
Multi-Dimensional Attributes
Each type of requirement has attributes, and each individual requirement has different
attribute values. For example, requirements may be assigned priorities, identified by
source and rationale, delegated to specific sub-teams within a functional area, given a
degree-of-difficulty designation, or associated with a particular iteration of the system.
To illustrate, Figure 6 displays attributes for a Feature Requirement Type from a
Learning Project in Rational RequisitePro requirements management tool. As implied by
the title of the screen, the requirement type and attributes for each type are defined for the
entire project, ensuring usage consistency across the team.
Change History
Both individual requirements and a collection of requirements have histories that become
meaningful over time. Change is inevitable and desirable to keep pace with a changing
environment and evolving technology. Recording the versions of project requirements
enables team leaders to capture the reasons for changing the project, such as a new
system release. Understanding that a collection of requirements may be associated with a
particular version of software allows you to manage change incrementally, reducing risk
and improving the probability of meeting milestones. As individual requirements evolve,
it is important to understand their history: what changed, why, when, and even by whose
authorization.
To build a system that truly meets customers’ needs, the project team must first define the
problem to be solved by the system. Next, the team must identify stakeholders from
whom business and user needs are elicited, described, and prioritized. From this set of
high-level expectations or needs, a set of product or system features should be agreed
upon.
Common sense and experience teach that the decision is not whether but how
to document requirements. Document templates provide a consistent format
for requirements management. Rational RequisitePro offers these templates
and the additional feature of linking requirements within a document to a
database containing all project requirements. This unique feature allows
requirements to be documented naturally while being made more accessible
and manageable in a relational database.
The following workflow diagrams are from the Rational Unified Process [6],
Requirements Workflow Details. These workflows are expressed in terms of workers,
activities and artifacts (input or output) as summarized in the activity diagram shown in
Figure 9. The accompanying text in this paper describes each workflow detail briefly, in
the hopes of stimulating your thoughts and interest in improving your requirements
management process. More information on the Rational Unified Process can be found at
www.rational.com.
In Problem Analysis, the primary activity is to develop the vision for the project. Output
from this activity is a vision document that identifies the high-level user or customer view
of the system to be built. The vision expresses initial requirements as key features the
system must possess in order to solve the most critical problems and meet key
stakeholder needs. The system analyst has the primary role in this workflow. The system
analyst should have problem domain expertise and an understanding of the problem, and
should be able to describe a process that he or she believes will solve the problem. Active
involvement from various project stakeholders is required and all relevant stakeholder
requests should be considered.
To begin the Manage Dependencies activity, features should be assigned attributes such
as rationale, relative value or priority, and source of request. As the vision develops, the
analyst identifies users and systems (the actors) of possible use cases. Actors are the first
Initiation: One or more stakeholders who perceive a problem will initiate the workflow.
A system analyst in a development team may facilitate a session to help the initial
stakeholders describe the problem they want solved. It is important to gain agreement on
a concise statement of the perceived problem. Key elements of a problem statement are
shown in the following table:
The problem statement succinctly explains the purpose of the project. Problem analysis
stimulates further investigation into all stakeholder requests and the initial business case
including compelling benefits and roughly estimated costs. In parallel with defining
problem statements, the team should also compile a glossary by keeping track of
commonly used terms and agreeing on their definitions.
A use-case model consists of actors, use cases, and relations among them.
Actors represent everything that must exchange information with the system,
including what are typically called users. When an actor uses the system, the
system performs a use case. A good use case is a sequence of transactions
that yields a measurable result of value for an actor. The collection of use
cases is the system’s complete functionality.
Problem analysis also identifies the main system actors. Actors are users of the system or
any other system that will exchange information with it. At this stage, problem analysis
should briefly identify some obvious ways that the actors will interact with the system.
Descriptions should be oriented towards business process rather than system behavior.
For example, a budgeting program may allow one type of actor to "Create departmental
budget," while another actor will be able to "Consolidate departmental budgets." The
system analyst may later break them into additional use cases that align more
meaningfully with specific system behavior. For example, "Create departmental budget"
could result in system use cases such as "Import spreadsheet information" and "Create
budget views."
The problem analysis session described above is often performed more than once, maybe
with different stakeholders, and intermingled with internal development team sessions.
The system analyst who conducted the meeting with the stakeholders will lead a session
with members of the development team to envision a technical solution to the problems,
derive features from the initial stakeholder inputs, and draft the vision description, the
first definition of the system to be built. To facilitate understanding of the proposed
solution among the initial stakeholders, the system analyst may use modeling tools or
manual drawing techniques to complement the vision description.
The initiating stakeholders are consulted at multiple points to help refine the problem
description and constrain the number and scope of possible solutions. Stakeholders and
system analysts manage dependencies in this workflow by negotiating the priority of key
features and gaining a general understanding of the resources and effort needed to
develop them. While priority and effort/resource estimates inevitably change, managing
dependencies early establishes an important pattern that continues throughout the
development lifecycle. It is the essence of the scope management and an early predictor
of project success.
After several drafts, the vision reaches a point at which the team must decide whether to
invest in additional requirements elicitation. By the same time, the business case approval
The system analyst and key stakeholders identify additional stakeholders, elicit their
requests and determine key needs and features via interviews, workshops, storyboards,
The analyst (or team representing the analyst role) must review all requests,
interpreting, grouping, perhaps retyping (without rewriting), and translating
them into key stakeholder needs and system features in the vision document.
Depending on the rigor applied in your development and the availability of
tools, traceability between some or all stakeholder requests, needs and
features can be applied to help stakeholders understand how their requests
and needs are accounted for in determining the requirements of the system.
Key stakeholders are consulted at multiple points to negotiate priorities of new features
derived from understanding stakeholder needs and gain a current understanding of
resources and effort needed to develop them. As with problem analysis, managing
dependencies in this workflow helps manage scope. It also establishes traceability
The first two Requirements workflow details, Analyze the Problem and Understand
Stakeholder Needs, create early iterations of key system definitions, including features
specified in the vision document, a first outline to the use-case model, and initial
requirement attributes. The next workflow detail, Define the System, completes the
description of the high-level system requirements with refinement of the feature
definitions, the addition of new actors, use cases, and supplementary specifications.
The glossary is updated to reflect current understanding about the terms used to describe
features and the requirements captured in the use-case model and the Supplementary
Specifications.
The system analyst uses the feature set defined in the refined vision to derive and
describe the use cases that elaborate the users' view of the system’s expected behavior.
The use-case model serves as a contract between the customer, the users, and the system
developers on how the selected features will function in the system. It helps set realistic
expectations and goals for system developers and helps customers and users to validate
that the system will meet these expectations.
Some system requirements do not fit well in use cases. The system analyst describes
these in a supplementary specification. Many non-functional requirements, such as
usability, reliability, performance, and supportability requirements often end up here. It
In this workflow detail, the system analyst creates and sets attributes for the
supplementary requirements (such as priority and related use cases). In addition, the
system analyst adds and updates attribute values for the initial and new use cases.
Finally, the system analyst manages dependencies by tracing important user needs and
critical features to related use cases and requirements described in supplementary
specifications.
After identifying feature-level requirements, describing most actors, use cases, and other
requirements specified in the supplementary specifications, the system analyst should
gather and assign values as accurately as possible to requirement attributes such as
priority, effort, cost, and risk. This allows a better understanding of how to determine the
initial scope of the system release and can also enable the architect to identify the
architecturally significant use cases.
The iteration plan, developed in parallel by project and development management, first
appears in this workflow detail: Manage the Scope of the System. Also known as a
development plan, the iteration plan defines the number and frequency of iterations
planned for the release. The highest risk elements within scope should be planned for
early iterations.
Other important outputs from the Managing Scope workflow include the initial iteration
of the software architecture document and a revised vision that reflects analysts and key
stakeholders’ increased understanding of system functionality and project resources.
Like the business case, mentioned earlier, and first issue of the iteration plan, the
software architecture document is not an artifact of requirements management
workflows, although it is related and is part of the Rational Unified Process. It is not the
subject of this paper.
Experience teaches that the keys to managing scope successfully are the well-
considered attribute values assigned to stakeholder needs, features, use cases,
and other requirements specified in supplementary specifications; along with
regular, open, and honest interaction with representative stakeholders.
Architects prioritize use cases for their risk coverage, architectural significance, and
architectural coverage. While the system may be defined with many use-case and
supplementary specification requirements, only a subset of use cases are usually critical
to good system architecture. With prioritized use cases, architects refine the iteration or
development plan and model a use-case view of the system architecture in tools such as
Rational Rose.
This step is among the most important in the entire project. For the first time the breadth
of knowledge about the proposed system is available to make serious commitments on
requirements, project resources and delivery dates. At the same time, it must be
understood that these requirements will change as the depth of knowledge increases. If
Throughout the life of the project, as situations and environments change, this workflow
detail is revisited many times as system analysts must negotiate revised project scope and
vision with key stakeholders. Managing the scope of the project to match available
resources is successful only if stakeholders and development team members view this
step as a natural progression – not an ambush on users’ expectations or an attempt to
blackmail the organization for more time and money. This workflow will need to be
repeated at major milestones in the project to assess whether new insight into the system
and its problems requires change to the scope. While committed requirements, budgets,
and deadlines are hard to change, an in-depth understanding of prioritized use cases,
supplementary specifications, and early system iterations inevitably lead to scope
reconsideration.
Once again, it is critical that the project team engages in habitual scope management
before reaching the refinement stage, as well as throughout the project lifecycle as
changes occur. Representative stakeholders must understand and trust that their priorities
and interests are taken seriously during increasingly difficult scope negotiations. By the
time system requirements are refined, only important requirements remain to be
negotiated or modified. Unless effective scope management habits have been established,
your project may be doomed as a "death march" – a hopelessly over-scoped project
moving inexorably towards delays and cost overruns.
Moving forward to Refine the System Definition, this workflow detail assumes that
system-level use cases have been outlined and actors have been described, at least briefly.
Through managing the project scope, the features in the vision have been re-prioritized
and are now believed to be achievable by fairly firm budgets and dates. The output of this
workflow is a more in-depth understanding of system functionality expressed in detailed
use cases, revised supplementary specifications, and early iterations of the system itself.
Obviously, not all systems will have user interfaces and not all early iterations will
include GUI elements. We use them here only as an example of an early iteration. Other
examples includes prototypes, models, and storyboards.
The use-case specifier details the definition of the flow of events, pre- and post-
conditions, and other textual properties of each use case. To minimize the effort and
enhance readability, it is advisable to use a standard document format or a use case
specification template, to capture textual information about each use case. Creating well-
thought-out use case specifications is critical to the quality of the system. This
specification development requires a thorough understanding of the stakeholder needs
and features related to the use case. It is desirable to have several members of the project
team (such as software engineers) participate in creating the use cases.
In parallel, the use case specifier revises the supplementary specification with additional
requirements that are not specific to the use case.
The user-interface designer models and prototypes the user interface of the system. This
work is highly correlated to the evolution of the use cases.
The use-case specifier and the system analyst revise the effort, cost, risk, and other
attribute values for each requirement that is understood better.
As changes occur -- and they inevitably will -- the Manage Changing Requirements
workflow detail needs to be applied continuously throughout the life of the project, as
discussed for the Manage the Scope of the System workflow detail. The output of this
workflow can cause modification to every artifact, which in turn requires effective
communication among all project team members and stakeholders.
In this workflow we introduce additional artifacts that are affected by the requirements
workflows. Changes to requirements naturally affect the system models that are
represented in the analysis & design workflows. Requirement changes also affect tests
created to validate the proper implementation of the requirements. As in earlier examples,
these artifacts are part of the Rational Unified Process but are not the subjects of this
paper. Traceability relationships identified in the process of managing dependencies are
keys to understanding these impacts.
Traceability
Requests for changes to requirements may be initiated by any stakeholder or project team
member for many various reasons. All Change Requests (Cr.'s) including changes to
requirements or enhancement requests, as well as defects, should all be channeled
through the same Change Request Management (CRM) process. At a minimum, this
should include logging and tracking the request in a centralized database system and
should enforce review by a central review authority. See other sections of the Rational
Unified Process for more details of such a CRM process.
The system analyst should coordinate the review activity, preferably by a CCB (Change
Control Board), collecting and reviewing all change requests, and classify them as:
Once classified, the proposed changes to requirements are assigned attributes and values
as described in other requirements workflows.
The requirements reviewers (developers, testers, managers, and other project team
members) evaluate the impact of changes to requirements on their work by reviewing
requirement history. Finally, they implement the change and make appropriate changes to
related requirements for which they have authority.
Summary
The need to manage requirements is not new. So, what makes the preceding information
worth considering now?
First, if your projects are not regularly satisfying customers, meeting deadlines, and
staying within budget, you have reason to reconsider your development approach. If in
doing so, you determine that requirements-related problems are undermining your
development efforts, you have reason to consider better requirements-management
practices.
Second, the requirements management practices summarized in this paper embody the
collective experience of thousands, and are the well-considered opinions of a number of
individuals who have spent years working with customers in the field of requirements
management. We suggest that this overview of their contributions -- and the more
thorough presentation of them made in Rational’s Unified Process -- represent a "best
practice" in requirements management. You will not find more proven advice on
requirements anywhere.
The authors would like to acknowledge the direct and indirect contributions of Dr. Ivar
Jacobson, and those of Dean Leffingwell, Dr. Alan Davis, Ed Yourdon, and Elemer
Magaziner. Most importantly, we appreciate the Rational Software customers who have
applied and improved these practices in hundreds of development projects.
Finally, in the past two years Rational Software, a leader in the business of producing
effective software development solutions, has taken on the challenge of requirements
management and emerged with the tools to automate this difficult task. The chronic,
pervasive problems of requirements management are solvable. And that, ultimately, may
be the best reason to start practicing excellence in requirements management today.
References
[1] CHAOS, The Standish Group International, Inc., Dennis, MA, 1994, 1997.
[3] Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,
Los Alamitos, CA, 1997 pp. 79.
[4] Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,
Los Alamitos, CA, 1997 pp. 80.
[5] Spence, Ian and Leslee Probasco, "Traceability Strategies for Managing
Requirements with Use Cases", White Paper, Rational Software Corporation, 1998.
[6] Rational Unified Process™, Rational Software Corporation, Cupertino, CA, 1999.
[7] Leffingwell, Dean and Don Widrig, Managing Software Requirements - A Unified
Approach, Addison-Wesley, 2000.
TABLE OF CONTENTS
1. Abstract
2. Introduction / Background
2. Introduction / Background
Capturing and tracking these other kinds of traceability item helps us in effectively
managing our project’s requirements.
Any textual, or model item, which needs to be explicitly traced from another textual, or
model item, in order to keep track of the dependencies between them.
• Naming conventions
i.e. the class in the design model called Fred is implemented by the class in the
implementation model called Fred
• The creation of different perspectives illustrating how the elements of one model satisfy
the demands implicit in the elements of another model
i.e. the use case realizations in the design model demonstrate how the model elements
of the design model collaborate to fulfill a use case. These provide a use case
perspective onto the design model which validates and supplements the static
packaging of the classes and packages in the design model.
All of these examples provide a level of traceability and allow impact analysis to be
undertaken using the information held in the development models.
As shown in the figure below, use case driven development involves a series of inter-
related models.
When undertaking a use case driven development some supporting artifacts are required
to support the use-case model and enable the definition of a complete software
requirements specification. In the Rational Unified Process these are the Supplementary
Specifications and the Glossary. Also of interest are the Business Case and Vision
documents, which will contain the definitions of the needs, goals and features for the
project.
The relationships between the models do not involve these supporting artifacts and so
they are not covered by the implicit traceability built into the development process.
These implicit relationships are fundamental to the development process and benefit from
being built as a natural part of the developer’s work. These relationships are central to
the modeling process and are constructed, and maintained, as the models are matured.
The following figure shows an example traceability hierarchy showing the relationship
between "features" defined in a vision document and "software requirements" defined in
a use case model and a supplementary specification. It also shows how the software
requirements are traced into the Test Requirements, Design and User Documentation
This is a good example of an additional level of explicit traceability that is often required
on a project. Many requirements trace through the whole series of models due to their
implicit relationship with the use-case model. The supplementary requirements, which
are captured alongside the use-case model in the supplementary specification, are not
directly related to any of the packages in the design model that need to consider them or
to any of the components in the implementation model that need to fulfill them.
One of the major decisions we need to make when setting up our requirements
traceability process is the level of traceability we require and how much explicit
traceability is required to meet this goal. We would like our approach to requirements,
and traceability, management to facilitate the development process, not complicate and
restrict it.
As we can see the addition of explicit traceability to our development artifacts could have
a significant cost to our project. This is especially significant when we consider the long-
term cost of populating and maintaining this additional information. What we need to do
is ensure that we establish a suitable level of traceability for our project and that we will
get a return on investment on any additional explicit traceability we decide to maintain.
We want our developers to spend their time developing not tracing. To this end we need
to establish and evaluate our traceability strategy before we add the cost of explicit
traceability to our project.
The traceability strategy will define the level of explicit traceability we wish to add to our
software development process.
The thing to note here is that the Use Case Model and the Supplementary Specification
form our complete Software Requirements Specification (SRS). This means that there is
no need for us to have a formal Software Requirements Specification document as
required by traditional requirements management techniques.
This relationship is often misinterpreted as implying that the two models of Requirements
Management cannot co-exist. People often think that they must choose between
traditional requirements management techniques, using a formal Software Requirement
Specification document, and use case model based requirements management techniques
using a use case model and a supplementary specification. In fact in certain
circumstances it is necessary for the two forms of Software Requirements Specification
to co-exist within the same project.
In this case the use-case model is the only statement of the systems requirements.
Projects that choose this approach are characterized by close association and trust
between customer and developer.
The Use-Case Model and Glossary and Supplementary Specifications form the entire
statement of the system’s requirements – no additional definitions of Needs, Product
Features or software requirements exist.
This is the default strategy recommended by the Rational Unified Process. The Use-
Case Model and Supplementary Specifications form a complete software
requirements specification. Features are documented in the Vision Document and are
traced to use cases. If they are not reflected in the Use Case Model then they are
traced to supplementary requirements in the Supplementary Specifications.
In this case the Use-Case Model acts as the main statement of the functional
requirements. The Use Case Model and Supplementary Requirements are complemented
with Needs and Product Features in addition to the Glossary and Supplementary
Requirements.
The Features trace into a formal Software Requirement Specification document (as in
traditional requirements management) but the software requirements are then traced,
explicitly, into the Use-Case Model.
4. The Use Case Model reconciles multiple sets of traditional software requirements
The Use Case Model is the interpretation of a set of formal Software Requirement
Specifications from multiple sources and provides the specification of a single
common system.
In this case each stakeholder has their own set of Product Features and Software
Requirements which are detailed within their own Vision and Software Requirements
Specification documents. These multiple viewpoints, and possibly conflicting desires
are then reconciled within a single Use-Case Model which specifies what the system
will do. This strategy can be very effective when dealing with a large set of
independent stakeholders.
In all of the cases except option 1 we combine our use-case model with elements of the
traditional requirements traceability process.
There are of course many other possible options one of which is to not have a Use-Case
Model at all. We will call this option "No Use-Case Model".
These, and other approaches, are discussed in more detail in the Traceability Strategy
Catalogue below.
This is the "Features Drive the Use Case Model" option above and is probably the most
efficient traceability strategy but it should be noted that even when the Rational Unified
Process has been adopted this approach is not always the most effective.
Examples where using Use-Case Modeling as the sole mechanism for functional software
requirement specification can prove problematical include:
• Where there are many, contradictory requirement sources (i.e. many contradictory
desires will need to be tracked and managed).
In our opinion the decision about which approach should be adopted must be made within
the context of each project and development organization. There is not a one-size-fits-all
solution to this problem and it is foolish to attempt to force all projects into a single
approach to requirements management.
It should be remembered that the Rational Unified Process is a configurable process and
can cope will all of the traceability strategies presented in this document except for the
"No Use Case Model" approach (the use-case driven nature of the Rational Unified
Process precludes the adoption of this option). The decision about which approach to
adopt is one of the decisions to be made during the production of the Rational Unified
Process development case.
1. Identify the set of traceability types required to define our traceability items.
The Traceability Strategy Catalogue facilitates the first two of these steps by
documenting known sets of traceability items and their traceability relationships. It does
not cover the third activity as the definition of the appropriate attributes for the
traceability types is, currently, outside the scope of this paper).
The traceability strategies described in the catalogue all make use of subsets of the same
basic set of traceability types.
1 Needs
4 Glossary Items
5 Use Cases
7 Actors
Note: often when use case modeling the only software requirements will be the
supplementary requirements defined by the supplementary specification.
Having the potential to trace between all of the traditional traceability types and the
component parts of the use-case model opens up the number of traceability strategies
available to the project.
1. Basic Traceability
There is basic traceability that applies whichever traceability strategy is chosen. This
traceability is implicit in the nature of the traceability types. This covers things like
the relationship between Use Cases and Use Case Sections or between Use Cases and
Actors.
When reading the overview diagrams in the Traceability Strategies Section below this
basic traceability is not repeated for each strategy but is included in the applicable
traceability strategies by default.
2. Extended Traceability
This is the traceability that is introduced to support one of the specific traceability
Note: RequisitePro allows any traceability item to be traced to any other item. What the
traceability strategy defines is the meaningful traceability links that will be at the heart of
the project’s requirement management strategy.
In this section we define a set of supporting traceability types that can be used to support
whichever traceability strategy is selected.
4.2.2 Overview
Note: These supporting traceability types can be traced to any of the other traceability
types involved in the chosen traceability strategy.
In this case there is no use-case model. The Needs give rise to Product Features which in
turn give rise to Software Requirements documented in a formal Software Requirements
Specification.
Typified by project managers who say, "I don't need no stinkin' Use-Case Model!"
4.3.2 Characteristics
Traceability Overview
Pros:
- Well understood
- Is thought to be good for legal contracts (see the many on-going court cases related to
delivered software's ability / inability to satisfy the requirements specified).
- Does not upset the status quo by introducing "darned new-fangled" ideas
Cons:
- Hard to complete the requirements capture - it is very easy to get stuck in the
requirements phase.
- High maintenance costs. The lack of any implicit traceability leaves projects with the
cost of maintaining large amounts of explicit traceability relationships.
4.3.7 Examples
The no use case model approach to requirements traceability is used widely in many
projects in many business areas. Many organizations require a formal, traditional
Software Requirements Specification as the basis for formal contractual negotiation.
This leads them to think that the traditional requirements management approach is the
only approach appropriate for their projects.
In this case the use-case model is the only statement of the systems requirements.
The Use-Case Model, Glossary and Supplementary Specifications form the entire
statement of the system’s requirements.
4.4.2 Characteristics
Pros:
- Good support for scope management, impact analysis and incremental development.
Cons:
- Some people consider it difficult to accept a contract based on just a use case model.
- Without undertaking any needs analysis it can be difficult to know when the use case
model itself describes a suitable solution. It is easy to let your imagination run away
with you when writing the use cases.
- If performing regular releases it can become difficult to product manage and continually
manage the stakeholders expectations without any information at a higher level than
the use cases themselves.
4.4.7 Examples
In this case use-case modeling is used as the main requirement elicitation method and the
Use-Case Model becomes the definition of the Product Features to be provided by the
system as well as the statement of the software requirements.
This option is only suitable for small developments, with short life cycles, as it does not
scale. Even if each use case represents a feature of the system there will be more features
than use cases and, in reality, many features may impact upon many use cases. As the
system evolves the new features of each release are less and less likely to take the form of
new use cases.
4.5.2 Characteristics
This is a variation on the previous "Use Case Model Only" approach. We have only
noted the few differences when discussing this approach.
Pros:
- In this case the use case model is related back to the stakeholder needs which helps to
assess the suitability of the use case model.
Cons:
- The use cases may appear to define the features of the system in the early stages of the
project but the two concepts will diverge as the project matures.
- Use cases are not features - what appears to be a time and labor saving strategy will
quite quickly become an un-maintainable mess.
4.5.7 Examples
Although attempts to use this traceability strategy have been observed on small internal
projects this approach is not recommended because of the scalability and long term
product evolution problems. It is recommended that the "Features Drive the Use Case
Model" strategy is adopted if the use case model is to be supplemented with traceability
back to the stakeholder needs.
"The Use-Case Model and Supplementary Specifications comprise my SRS." This is the
strategy outlined and recommended by the RUP. The Needs and Product Features are
documented in the Vision Document and are traced to use cases. If they are not reflected
in the Use Case Model, then they are traced into the Supplementary Specifications.
In this case the Use-Case Model acts as the main statement of the software requirements.
This is complemented by a supplementary specification containing the software
requirements that cannot easily be expressed in the use cases themselves.
4.6.2 Characteristics
*each Product Feature must trace to at least one Use Case Section or Supplementary
Software Requirement. If it doesn't then it will not be included in the Software.
This approach maximizes the benefits provided by both the use case and traditional
requirements management approaches whilst minimizing the disadvantages.
Pros:
- Well understood
- Having both a Product Feature and Use Case perspective on the Software Requirements
facilitates the completion of the requirements capture - this minimizes the chances of
getting stuck in the requirements elicitation and capture activities.
- The individual requirements have context supplied by the use cases and / or the product
features. This makes it easy to identify meaningful sub-sets of the requirements.
This in turn makes scope management, and the incremental delivery of the product,
much easier.
- This solution scales well. If performing regular releases the ability to scope manage at
both the feature and use case level allows all of the stakeholders to track the progress
of the project at the level of detail they find appropriate.
- In this case the use case model is related back to the stakeholder needs via the product
features which helps all the stakeholders to assess the suitability of the use case
model.
Cons:
4.6.7 Examples
This approach is applicable to all projects where use cases are accepted as a suitable
format for the expression of the majority of the Software Requirements.
"The Use-Case Model is an interpretation of the formal SRS". This is most often used
when a formal SRS is mandated due to regulatory or internal protocol.
In these cases the use-case model is used to model and reinterpret all of the software
requirements within the scope of the project. When this approach is adopted it is usual
for the SRS to come first - there are other techniques available to render the information
held by a use case model in a format that looks like a formal, traditional SRS (especially
when the "Features Drive the Use Case Model" approach has been adopted) without
creating a second Software Requirements definition.
Note: when adopting this approach there is no need for the set of "traditional" Software
Requirements to be a complete statement of the functionality required - the Use-Case
Model will provide / ensure completeness of the functional specification. The
"traditional" Software Requirements may just be used to capture the Software
Requirements directly identified or raised by the stakeholders.
4.7.2 Characteristics
Traceability Overview
This approach is to be completely honest a little bit over the top. It is really only
appropriate for projects that are presented with a traditional SRS and wish to use use-case
modeling to attain an understanding of the supplied requirements and to facilitate a use
case driven approach.
Pros:
- The individual requirements have context supplied by the use cases and / or the product
features. The presence of the use case model makes it easy to identify meaningful
sub-sets of the requirements. This in turn makes scope management, and the
incremental delivery of the product, much easier.
- In this case the use case model is eventually related back to the stakeholder needs via
the software requirements and the product features which helps all the stakeholders to
assess the suitability of the use case model.
- Acceptable (with caveats) in most organizations - this approach is all things to all
people. This approach is often used on initial use case projects as a form of parallel
requirements process (i.e. the project is running both the old way and the new way) or
it can be adopted to hide the fact that the developers are using use cases.
- Good for minimizing the disruption to the organization when first adopting, or
experimenting with, use cases. The outside world continues to see the traditional SRS
which allows the standard procedures and contracts to be used.
Cons:
- Not well understood - people will get confused by having both the traditional statements
of requirements and the use case model.
- Having both traditional Software Requirement Specification and a Use Case Model
gives you two places to get stuck in the requirements activities. It is easy to become
confused over which should be the complete Software Requirement Specification
4.7.7 Examples
This approach is useful for development companies using use case driven development
techniques that are given a traditional Software Requirements Specification as part of
their contract. The introduction of use cases will enable the development company to
demonstrate their understanding of the requirements and deliver the software in an
iterative and incremental fashion.
It can also be a useful strategy when introducing use case techniques into a company that
uses traditional requirements capture techniques and has a resistance to changing to a use
case driven approach. In this case the intention is for the use cases to prove their value to
the development organization and for the traditional Software Requirements
Specification to be phased out as confidence in use cases grows. This could be the first
step in moving towards the "Features Drive the Use Case Model" approach.
"The Use-Case Model is the interpretation of formal SRS's from multiple sources and
provide the specification of a single common system."
This is a variation on the "the Use Case Model is an interpretation of the Software
Requirements Specification" except in this case there are multiple traditional SRS's
supplied by multiple, independent sets of stakeholders. This situation often arises for
software houses that are developing a single application to satisfy the requirements of
many different, independent, un-connected customers. In this case the Use Case Model is
the developers consolidated view of the system's requirements and the individual SRSs
are the individual stakeholders view of their own requirements (with no integration or
reflection of the other stakeholder's requirements). Tracing between the many, individual
sets of requirements and the Use Case Model allows the developers to assess how well
they are doing in assessing the needs of the various stakeholder.
4.8.2 Characteristics
This strategy is a variation on the previous "Use Case Model is an interpretation of the
Software Requirements Specification" approach. We have only noted the few differences
when discussing this approach.
Traceability Overview
This strategy is a variation on the previous "Use Case Model is an interpretation of the
Software Requirements Specification" approach and has much the same benefits and
disadvantages.
The benefit of this approach that differentiates it from the other strategies is its ability to
deal with, and preserve the viewpoints of independent stakeholders in the form of their
own formal, individual SRSs.
It also has the additional disadvantage of generating an even bigger document set to
maintain and trace.
4.8.7 Examples
A software house in the UK was developing a system to support Insurance Brokers that
would allow the Insurance companies to electronically distribute new products.
This project had in the region of 22 stakeholders of which approximately two thirds were
Brokerage companies and one third was Insurance companies. Amongst these
In this case it was decided to produce a Software Requirement Specification for each
stakeholder company detailing their specific requirements and allowing their individual
perspectives to be easily maintained. The use case model was used to present the
consolidated vision of the system to all of the stakeholders. Traceability from their
original SRS's into the use case model allowed the stakeholder to see exactly which of
their requirements would be met by the system and to validate that the system was
suitable for their needs. It also allowed the software house to track their progress against
their target of fulfilling 80% of all stakeholder requirements for each stakeholder.
Interactive systems rely on their ability to accommodate the needs of users for their
success. This means not only identifying diverse user communities but also recognizing
the range of skills, experience and preferences of individual users.
While it is tempting for developers and managers to feel that they understand user needs,
this is seldom the case in practice. Attention is frequently focused on how users ought to
perform tasks rather than how they prefer to perform them. In many cases the issue of
preference is much more than simply feeling in control, although that is an important
issue in itself. Preference will also be determined by experience, ability and the context of
use. These issues are considered sufficiently important to the design process to warrant an
international standard, ISO 13407, entitled human-centred design processes for
interactive systems. The standard and related issues are discussed in general terms in the
remainder of this paper.
Users understand and interact with a system through its user interface. The concepts,
images and terminology presented in the interface must be appropriate to users’ needs.
For example, a system that allows customers to buy their own tickets would be very
The user interface must also cater for a potentially wide range of experience along at least
two dimensions, computer and domain experience, as shown in Figure 1 below.
Computer experience includes not only general familiarity with computers, but also
experience of the system under development. Users with little experience of either
computers or the problem domain, in the near left corner of the figure, will require a
substantially different approach in the user interface to expert users, shown here in the far
right corner.
Figure 1: The effects of computer and domain experience on ease of learning versus ease of use
Beware that it is not a forgone conclusion that inexperienced users will become experts
over time. A number of factors may conspire to prevent this, for example low frequency
of use, low motivation or high complexity. Conversely some systems may have
predominately expert users. Factors here might be training, high frequency of use or high
motivation (job dependence). Some of these issues and their effects on user interface
design are shown in Table 1.
Low High
Computer experience Simple question and answer, Complex form-fill, web
simple form-fill, web (hyper (hyper linked) or menu
linked) or menu interface style interface style (question and
answer or simple form-fill
would be very frustrating to
experienced users)
Domain experience Common terminology and Domain-specific terminology
concepts and concepts
Training Focus on ease of learning Focus on ease of use (direct,
(consistent, predictable, customizable, non-intrusive)
memorable)
Interactive systems must either be designed to cater for an appropriate range of user
experience and circumstances, or steps must be taken to restrict the design universe. For
instance, training can be used to reduce the requirement for ease of learning in a complex
system. Alternatively a system might be reduced in its scope in order that it better meets
the core requirements of its users (a suggestion made by Alan Cooper in his book The
Inmates Are Running the Asylum COO99).
As part of user-centered design, we need to consider the skills and physical attributes of
users. These issues are now being increasingly embodied in legislation. This is mostly
directed at accommodating users with disabilities. However, making systems accessible
to a wider range of users is generally seen as benefiting the user community as a whole.
The table below shows the relevant legislation and resources for many parts of the world:
AUSTRALIA
Disability Discrimination Act http://www.deakin.edu.au/extern/rdlu/ddaindex.html
Disability Rights http://www.hreoc.gov.au/disability_rights/index.html
EUROPE
Treaty of Amsterdam http://www.edf.unicall.be/teu/en/index.asp
European Disability Forum http://www.edf.unicall.be
UNITED KINGDOM
Disability Discrimination Act http://www.hmso.gov.uk/acts/acts1995/1995050.htm
New Deal for Disabled People http://www.disability.gov.uk
Digital Access Campaign http://www.rnib.org.uk/digital/welcome.htm
UNITED STATES
Americans with Disabilities http://www.usdoj.gov/crt/ada/
Act (ADA): US Department
of Justice
Section 508 of the Workforce http://www.usdoj.gov/crt/508/508home.html
Investment Act: US
Department of Justice
US Access Board Electronic http://www.access-board.gov/pubs/eitaacrpt.htm
and Information Technology
Advisory Committee
(EITAAC)
World Wide Web Consortium http://www.w3.org/wai/
Web Accessibility Campaign
OTHER RESOURCES
Disability-Related Internet http://www.webable.com/
Resources
Aside from legislation, user-centered design and user interface design are increasingly
becoming the subject of standardization as shown below.
ANSI www.ansi.org
ISO www.iso.ch
Table 2b, ANSI and ISO user interface and user-centered design standards
Focus on users
Gould suggests that developers should decide who the users will be and to involve them
at the earliest possible opportunity. He suggests a number of ways of becoming familiar
with users, their tasks and requirements:
Integrated design
Usability tasks should be performed in parallel early in development. These tasks would
include sketching the user interface, drafting the user guides or online help, Gould also
makes the point that usability should be the responsibility of one group.
An important feature of integrated design is that the overall approach – the framework –
for detailed user interface design is developed and tested at an early stage. This is an
important difference between user-centered design and other purely incremental
techniques. It ensures that incremental design carried out in later phases fits seamlessly
into the framework and that the user interface is consistent in appearance, terminology
and concept.
Within RUP, this framework can be established by using a domain model to ensure that
all terminology and concepts that will appear in the user interface are known and
understood within the business in general and with users in particular. (There will also be
subsets of the domain model that will be relevant only to specific groups of users. Care
should be taken to ensure that the domain model is organized so that these subsets can be
easily identified.) As user interface design progresses in the requirements workflow,
many of the domain classes will be represented as boundary classes in the interface. The
boundary classes, and the relationships between them, should be consistent with the
domain model and should be represented consistently through all parts of the system
under design. (This not only assists users, but also improves reuse of user interface
components.)
Early user testing means early prototyping, typically drawings and mockups described as
low-fidelity prototypes. Hi-fidelity prototypes will follow later in the process.
Mockups can be used in conjunction with use cases to write concrete scenarios of use for
the system under design. These can take the form narrative, illustrated narrative (using
the mockups for illustration), storyboards, walk-throughs (with users) and the basis of
user focus groups. While these approaches are unfamiliar to many software developers,
they are clearly more cost effective than the discovery of inappropriate design or
misunderstood requirements once implementation is under way.
Iterative design
Note that in user-centered methods, iterative design takes place within an integrated
framework. We deliberately avoid incremental development, outside of an agreed
framework, that might lead to a “patchwork” solution.
"...go where the customer works, observe the customer as he or she works, and talk to the
customer about the work."
(Some concrete examples of this have already been listed under Focus on Users.) This
approach is used not only to have a better understanding of system requirements, but also
of the users themselves, their tasks and environments. Each have their own attributes and
taken together are referred to as the context of use. They are detailed in the ISO standard
for user-centered design, described below.
Contexts of use
ISO’s Human-centred design processes for interactive systems (ISO13407) identifies the
first step in design as understanding and specifying the context of use. The attributes
suggested are:
Context Attributes
It is useful to split the user context into its two constituent parts (user type and role) and
then to consider the relationships between all four contexts:
Figure 2 shows that every task is performed in a role taken by a user within an
environment. These contexts correspond to RUP artifacts as shown in Table 4.
o Use Case
Table 4, ISO user-centered design standard contexts and their RUP artifacts
Each of these contexts could have a significant impact on the design of an appropriate
user interface. As a result we are faced with a potentially large number of permutations.
Even for a small system, there may be 2 environments (e.g. office and customer site), 3
types of user (sales novice, sales expert and management) and 6 roles (telephone sales
assistant, external sales representative, etc.). That means up to 36 potential variations per
task, although the set of realistic combinations is usually much smaller.
Each user role description includes details of the role itself plus its users (referred to as
role incumbents) and environment. This approach can be adopted with RUP by choosing
actors that correspond to user roles.
The terms scenarios, use cases and essential use cases have a confusing degree of overlap
and are used in different design approaches to mean slightly different things. For
example, within RUP "scenario" means a use-case instance; simply a specific "path"
through the possible basic and alternative flows. However, it is common to find user-
centered and user-interface design methods describing scenarios as stories of use,
containing substantially more detail than just the flow of events. While this additional
information may be irrelevant in later design phases, it does form part of the
understanding of users, tasks and environments. Consequently, scenarios may be used
extensively (in storyboarding and role playing) during the Business Modeling workflow,
but the focus moves towards use cases in the Requirements workflow.
Figure 3: Overlap in concepts between scenarios and use cases in user-centered design
The differences between system use cases and essential use cases are best illustrated by
example. Table 5 shows a use case from Constantine and Lockwood's Software for Use
(CON99):
This use case captures the essence of the getting cash interaction. The User Action and
System Response headings have been replaced by User Intention and System
Responsibility to reflect the change in emphasis. Good interface design centers on user
goals and intentions; these are often hidden in conventional use cases.
However, essential use cases do have their drawbacks. Perfectly straightforward use
cases such as that in Table 5 can be subject to considerable debate when it comes to
distilling their essence. For example, does inserting a card identify the customer or the
account? In most existing ATMs, it is the later although Constantine and Lockwood have
chosen to interpret this as identifying the customer. This may have been a deliberate
decision in light of newer technology such as retina scanning and fingerprint
identification, or it may have been an oversight. The consequences in this case is an
additional choice that has to be made by customers who hold more than one account.
Another difficulty that essential use cases present is that they are not as suitable for
review with end users and other stakeholders because of their abstract nature. Part of this
problem stems from having to translate essential use cases back to a concrete form
representing user actions. This can be done once a design model is available by writing
scenarios that describe the interaction in concrete terms (similar in concept to a Use Case
Realization, although concerned with user-system interaction rather than internal object
collaboration).
RUP does not explicitly refer to essential use cases, but in the Activity: Model the User
Interface, essential use cases are used as a starting point, then developed and augmented
• Start by clarifying the use case itself - not its user interface. Start by keeping
the description independent of the user interface, especially if the use case is
unexplored. Then, later on, as the use case is understood, the flow of events -
storyboard can be augmented with user interface and usability aspects. [from
Guidelines: Use-Case Storyboard]
This means removing all design or current implementation detail so that only the
semantics - the meaning of the interaction - remain. Then, as various design alternatives
are explored, syntactic detail - how the interaction takes place - is added to the essential
use case as a type of realization. (Each alternative design is, in effect, a realization of the
same essential use case.)
These use-case storyboards are used as input to the Activity: Prototype the User Interface
to develop the user-interface prototypes.
The use-case view shows an architecturally significant subset of the use-case model, a
subset of the use cases and actors.
There are four additional views: the Logical View, Process View, Deployment View,
and Implementation View. These views are handled in the Analysis & Design and
Implementation workflows.