Kel 1

Introduction to Requirements
• Purpose
• Relation to Other Workflows

Concepts

• Requirements
• Requirements Management
• Types of Requirements
• Traceability
• User-Centered Design
• Use-Case View

Purpose

The purpose of the Requirements workflow is:

• 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.

Hal 1 dari 117

The Vision document provides a complete vision for the software system under
development and supports the contract between the funding authority and the
development organization. Every project needs a source for capturing the expectations
among stakeholders. The vision document is written from the customers' perspective,
focusing on the essential features of the system and acceptable levels of quality. The
Vision should include a description of what features will be included as well as those
considered but not included. It should also specify operational capacities (volumes,
response times, accuracies), user profiles, and interoperational interfaces with entities
outside the system boundary, where applicable. The Vision document provides the
contractual basis for the requirements visible to the stakeholders.

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.

The Supplementary Specifications are an important complement to the use-case model,

because together they capture all software requirements (functional and nonfunctional)
that need to be described to serve as a complete software requirements specification.

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 Glossary is important because it defines a common terminology which is used

consistently across the project or organization.

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.

Hal 2 dari 117

These artifacts provide important feedback mechanisms in later iterations for discovering
unknown or unclear requirements.

Relation to Other Workflows

The Requirements workflow is related to other process workflows.

• The Business Modeling workflow provides Business Rules, a Business Use-Case

Model and a Business Object Model, including a Domain Model and an
organizational context for the system.
• The Analysis & Design workflow gets its primary input (the use-case model and
the Glossary) from Requirements. Flaws in the use-case model can be discovered
during analysis & design; change requests are then generated, and applied to the
use-case model.
• The Test workflow tests the system to verify the code against the Use-Case
Model. Use Cases and Supplementary Specifications provide input on
requirements used in planning and designing tests.
• The Environment workflow, develops and maintains the supporting artifacts that
are used during requirements management and use-case modeling, such as the
Use-Case-Modeling Guidelines and User-Interface Guidelines.
• The Management workflow plans the project, develops the Requirements
Management Plan, and each iteration (described in an Iteration Plan). The use-
case model is an important input to the iteration planning activities.

Hal 3 dari 117

Concepts: Requirements
More Information: Concepts: Requirements Management
Concepts: Types of Requirements
Concepts: Traceability
Concepts: User-Centered Design
White Paper: Applying Requirements Management with Use Cases

A requirement defined as "a condition or capability to which a system must conform".

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.

(See also [IEEE Std 610.12.1990].)

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.

Hal 4 dari 117

Functionality

Functional requirements may include:

• feature sets,
• capabilities, and
• security.

Usability

Usability requirements may include such sub-categories as:

• human factors (see: Concepts: User-Centered Design),

• aesthetics,
• consistency in the user interface (see: Guidelines: User-Interface),
• online and context-sensitive help,
• wizards and agents,
• user documentation, and
• training materials.

Reliability

Reliability requirements to be considered are:

• frequency / severity of failure,

• recoverability,
• predictability,
• accuracy, and
• mean time between failure (MTBF).

Performance

A performance requirement imposes conditions on functional requirements. For example,

for a given action, it may specify performance parameters for:

• speed,
• efficiency,
• availability,
• accuracy,
• throughput,
• response time,
• recovery time, or
• resource usage.

Supportability

Hal 5 dari 117

Supportability requirements may include:

• 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

An implementation requirement specifies or constrains the coding or construction of a

system. Examples are:

• required standards,
• implementation languages,
• policies for database integrity,
• resource limits, and
• operation environments.

Interface Requirement

An interface requirement specifies

• an external item with which a system must interact, or

• constraints on formats, timings, or other factors used by such an interaction.

Physical Requirement

A physical requirement specifies a physical characteristic that a system must possess; for
example,

• material,
• shape,
• size, and
• weight.

Hal 6 dari 117

This type of requirement can be used to represent hardware requirements, such as

• the physical network configurations required.

Hal 7 dari 117

Concepts: Requirements Management
• What is Requirements Management?
• Problem analysis
• Understanding stakeholder needs
• Defining the system
• Managing scope of the project
• Refining the system definition
• Managing changing requirements

More Information: Concepts: Requirements

Concepts: Types of Requirements
Concepts: Traceability
White Paper: Applying Requirements Management with Use Cases

What is Requirements Management?

Requirements management is a systematic approach to finding, documenting, organizing

and tracking the changing requirements of a system.

We define a requirement as:

A condition or capability to which the system must conform.

Our formal definition of requirements management is that it is a systematic approach to

• eliciting, organizing, and documenting the requirements of the system, and

• establishing and maintaining agreement between the customer and the project
team on the changing requirements of the system.

Keys to effective requirements management include maintaining a clear statement of the

requirements, along with applicable attributes for each requirement type and traceability
to other requirements and other project artifacts.

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.

Hal 8 dari 117

 • Requirements have unique properties or property values. For example, they are
neither equally important nor equally easy to meet.
• There are many interested parties, which means requirements need to be managed
by cross-functional groups of people.
• Requirements change.

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.

See also Workflow Detail: Analyze the Problem.

Understanding Stakeholder Needs

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.

Elicitation activities may occur using techniques such as interviews, brainstorming,

conceptual prototyping, questionnaires, and competitive analysis. The result of the
elicitation would be a list of requests or needs that are described textually and
graphically, and that have been given priority relative one another.

Hal 9 dari 117

See also Workflow Detail: Understand Stakeholder Needs.

Defining the System

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.

See also Workflow Detail: Define the System.

Managing the Scope of the Project

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.

See also Workflow Detail: Manage the Scope of the System.

Refining the System Definition

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.

Hal 10 dari 117

We have seen that the use-case methodology, often in combination with simple visual
prototypes, is a very efficient way of communicating the purpose of the system and
defining the details of the system. Use cases help put requirements into a context, they
tell a story of how the system will be used.

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.

See also Workflow Detail: Refine the System Definition.

Managing Changing Requirements

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.

See also Workflow Detail: Manage Changing Requirements.

Hal 11 dari 117

Kel 2
Concepts: Types of Requirements
More Information: Concepts: Requirements
Concepts: Requirements Management
Concepts: Traceability
White Paper: Applying Requirements Management with Use Cases

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".

To perform effective requirements management, we have learned that it helps to extend

what we maintain as requirements beyond only the detailed "software requirements". We
introduce the notion of requirements types to help separate the different levels of
abstraction and purposes of our requirements. Each requirement type will have a unique
set of attributes associated with each requirement defined at that level.

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

Hal 12 dari 117

requirements on our system. 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.

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.

Copyright © 1987 - 2000 Rational Software Corporation

Hal 13 dari 117

Concepts: Traceability
More Information:

• 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

The purpose of establishing traceability is to help:

• Understand the source of requirements

• Manage the scope of the project
• Manage changes to requirements
• Assess the project impact of a change in a requirement
• Assess the impact of a failure of a test on requirements (i.e. if test fails the
requirement may not be satisfied)
• Verify that all requirements of the system are fulfilled by the implementation.
• Verify that the application does only what it was intended to do.

The traceability hierarchy.

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

Hal 14 dari 117

turn, outlines the how these features are translated to the functionality of the system. The
details of how the system interacts with the outside world are captured in use cases, with
other important requirements (such as non-functional requirements, design constraints,
etc.) in the Supplementary Specifications. Traceability allows you to also follow how
these detailed specifications are translated into a design, how it is tested, and how it is
documented for the user. For a large system, use cases and Supplementary Specifications
may be packaged together to define a Software Requirements Specification (SRS) for a
particular "feature" or other subsystem grouping.

A key concept in helping to manage changes in requirements is that of a "suspect"

traceability link. When a requirement (or other traceability item) changes at either end
of a traceability link, all links associated with that requirement are marked as "suspect".
This flags the responsible worker to review the change and determine if the associated
items will need to change also. This concept also helps in analyzing the impact of
potential changes.

Traceabilities may be set up to help answer the following sample set of queries:

• Show me user needs that are not linked to product features.

• Show me the status of tests on all use cases in iteration #n.
• Show me all supplementary requirements linked to tests whose status is untested.
• Show me the results of all tests that failed, in order of criticality.
• Show me the features scheduled for this release, which user needs they satisfy,
and their status.

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.

This feature is traced to a use case "Add New Bottle Type":

• 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.

Hal 15 dari 117

Guidelines: Going from Business Models to Systems
Topics

• 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

Business Models and System Architecture

From an architectural perspective, having business models in place is particularly useful

if your intent is to build one of the following kinds of systems:

Hal 16 dari 117

 • Customized systems for one or more companies in a particular type of industry,
such as banks and insurance companies.
• A family of applications for the open market, such as order handling systems,
billing systems, and air-traffic control systems.

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.

The following should be considered:

• 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.

Hal 17 dari 117

In a four-layered system architecture, business models give input to the top two layers

Business Models and Actors to the System

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:

• Decide if the business worker will use the information system.

• If so, identify an actor for the information system in the information system’s use-
case model. Give the actor the same name as the business worker.
• For each business use case in which the business worker participates, create a
system use case.

Hal 18 dari 117

 • Repeat these steps for all business workers.

Example:

Based on business models of a bank, you can derive candidate system actors and system
use cases.

Automated Business Workers

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.

• Responsibilities of the Clerk will be moved to the Customer.

• Create a system actor Customer corresponding to the business actor Customer.
• Remove the system actor Clerk.
• Modify the system use case Money Transaction 1 to work with the system actor
Customer, instead of Clerk.

Hal 19 dari 117

Completely automating business workers changes the way the business process is
realized, as well as how you find system actors and use cases

Business Models and Entity Classes in the Analysis Model

For each business entity, create a class in the system's analysis model

A business entity to be managed by an information system will correspond to an entity in

the analysis model of the information system. In some cases, however, it might be
suitable to let attributes of the business entity correspond to entities in the information-
system model. Several business workers can access a business entity. Consequently, the
corresponding entities in the system can participate in several information-system use
cases.

Example:

Hal 20 dari 117

The business entities Customer Profile, Account, and Loan are all candidates for
automation.

Interaction between Business Workers Translated to System

Requirements

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.

Using the Business Object Model for Resource Planning

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

Hal 21 dari 117

problems that can be solved with new kinds of solutions. Here's an example of a
procedure to consider:

• 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.

• The Clerk business worker is completely automated and becomes an Automated

Clerk. The bank will only do on-line banking.
• The Loan Specialist is partly automated, and is split into an Automated Loan
Specialist and a Loan Specialist.

The business workers are modified to reflect automation

Summary Table

The following table summarizes the relationship between the business models and the
system models.

Hal 22 dari 117

 System Models How to find candidates, using Business Models
information in the business models
Actor Actor candidates are found among Business worker
business workers.
Actor Other actor candidates are found among Business actor
the different business actors (customers,
vendors) that will directly use the
system.
Use case Use-case candidates are found among Business
business-workers’ operations. Look for workers’
operations, and areas of responsibility, operations
that involve interactions with the
information system. Ideally one
information system use case supports
all the worker’s operations within one
business model use-case realization.
Entity class Entity class candidates are found among Business entity
business entities. Look for business
entities that should be maintained or
represented in the information system.
Entity class Entity class candidates are found among Attributes
attributes in the business object model.
Look for attributes that should be
maintained or represented in the
information system.
Relationships Relationships between business entities Relationships
between entity often indicate a corresponding between business
classes relationship between the classes in the entities
information system model.

Hal 23 dari 117

Kel 3 dan 4
Applying Requirements Management with Use Cases
by Roger Oberg, Leslee Probasco and Maria Ericsson ©Copyright 2000 by Rational
Software Corporation. All Rights Reserved. Technical Paper TP505 (Version 1.4)

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

Use Cases and Software Requirements Specifications (SRS)

To make requirements management workflows more meaningful to readers,

the authors have chosen specific document types and other requirements
management artifacts from Rational Software’s Unified Process and the
industry-standard Unified Modeling Language, both of which recommend a
use-case-driven software engineering process.

Therefore, a use-case-driven approach for specifying software requirements

is described here. These workflows may also be used with the more
traditional Software Requirements Specifications (e.g., IEEE standards) in
place of or in addition to use-case models and use cases.

Software and System Development in the Age of Process

For most software and system development teams, the 1990s have been process-intensive
when compared to the more freewheeling days of the past. Standards for measuring and
certifying effective software development process have been introduced and popularized.
Many books and articles on software development process and related material on
business process modeling and re-engineering have been published. Increasing numbers
of software tools have helped define and apply effective software development process.
The global economy’s dependence on software accelerated in the decade, enabling
development processes and improving system quality.

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

Hal 24 dari 117

software development, yet relatively little attention has been focused on improving the
practice of this discipline.

This paper presents the elements of an effective requirements management process and
highlights some of the obstacles to its successful implementation.

Requirements management applies equally to software-only projects and to projects in

which software is only a part of the end result or not included at all. For convenience, the
paper will hereafter use the term "system" to mean any or all of these things. However, it
is the abstract nature of software development, alone or in combination with hardware
that complicates requirements management, and is therefore the primary focus of the
paper.

Why Manage Requirements?

Simply put, system development teams who manage requirements do so because they
want their projects to succeed. Meeting their project’s requirements defines success.
Failing to manage requirements decreases the probability of meeting these objectives.

Recent evidence is supportive:

• 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]

Avoiding failure should be sufficient motivation to manage requirements. Increasing the

probability of a successful project and other benefits of managing requirements may be
equally motivational. The Standish Group’s CHAOS report further established that
managing requirements well was the factor most related to successful projects.

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.

Well-known requirements engineering authors Merlin Dorfman and Richard H. Thayer

offer a compatible and more refined definition that is specific – but not necessarily
limited – to software:

Hal 25 dari 117

"A software requirement can be defined as:

• A software capability needed by the user to solve a problem or achieve an

objective.
• A software capability that must be met or possessed by a system or system
component to satisfy a contract, specification, standard, or other formally imposed
documentation." [3]

What is Requirements Management?

Since requirements are things to which the system being built must conform, and
conformance to some set of requirements defines the success or failure of projects, it
makes sense to find out what the requirements are, write them down, organize them, and
track them in the event they change.

Stated another way, Requirements Management is:

• a systematic approach to eliciting, organizing, and documenting the requirements

of the system, and
• a process that establishes and maintains agreement between the customer and the
project team on the changing requirements of the system.

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.

The Problems of Requirements Management

So what might be difficult about a process intended to ensure that a system conforms to
the expectations set for it? When put into practice on real projects, difficulties come to
light. Figure 1 displays the results of a 1996 survey of developers, managers, and quality
assurance personnel. It shows the percentage of respondents who experienced the most
frequently mentioned requirements-related problems.

Hal 26 dari 117

Figure 1 - Common Requirements Problems

A more comprehensive list of problems includes:

• Requirements are not always obvious and have 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 to other deliverables of the process in
a variety of ways.
• Requirements have unique properties or property values. For example, they are
neither equally important nor equally easy to meet.
• There are many interested and responsible parties, which means requirements
need to be managed by cross-functional groups of people.
• Requirements change.
• Requirements can be time-sensitive.

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.

Requirements Management Skills

To resolve the problems mentioned above, Rational encourages the development of key
skills. These skills are presented below in what appears to be sequential order, but in an
effective requirements management process they are applied continuously in varied
order. Here they are presented in the sequence one would likely apply to the first iteration
of a new project.

Hal 27 dari 117

Figure 2 - Steps in Problem Analysis

Key Skill 1: Analyze the Problem

Problem analysis is conducted to understand business problems, target initial stakeholder

needs, and propose high-level solutions. These acts of reasoning and analysis find "the
problem behind the problem."

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.

Key Skill 2: Understand Stakeholder Needs

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.

Hal 28 dari 117

If you are 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 at a system level. If you are developing a product to be sold to a marketplace,
you may make extensive use of your marketing people to better understand the needs of
customers in that market.

Techniques for eliciting requirements include interviews, brainstorming, conceptual

prototyping, questionnaires, and competitive analysis. The result of requirements
elicitation is a list of requests or needs that are described textually and graphically, and
that have been given priority relative to one another.

Key Skill 3: Define the System

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.

Principle 55: Write Natural Language Before A More Formal Model

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."

Hal 29 dari 117

 Note that in the latter example, the text does not help the reader at all.

- Alan M. Davis, 201 Principles of Software Development, 1995

Key Skill 4: Manage the Scope of the System

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.

Key Skill 5: Refine the System Definition

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.

Key Skill 6: Manage Changing Requirements

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.

Hal 30 dari 117

Accommodating changing requirements is a measure of your team’s stakeholder
sensitivity and operational flexibility – team attributes that contribute to successful
projects. Change is not the enemy, unmanaged change is.

Figure 3 - A Process for Managing Change

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).

Important Requirements Concepts

To apply requirements management skills to a project, certain requirements management
concepts are useful for everyone on the project to understand. They include:

• Requirements types
• Cross-functional teams
• Traceability
• Multi-dimensional attributes

Hal 31 dari 117

 • Change history

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.

Hal 32 dari 117

Figure 4 - Cross-functional Requirements Team

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

As implied in the description of requirement types, no single expression of a requirement

stands alone. Stakeholder requests are related to the product features proposed to meet
them. Product features are related to individual requirements that specify the features in
terms of functional and non-functional behavior. Test cases are related to the
requirements they verify and validate. Requirements may be dependent on other
requirements or they may be mutually exclusive. In order for teams to determine the
impact of changes and feel confident that the system conforms to expectations, these
traceability relationships must be understood, documented, and maintained. While
traceability is one of the most difficult concepts to implement in requirements
management, it is essential to accommodating change. Establishing clear requirement
types and incorporating cross-functional participation can make traceability easier to
implement and maintain. For more information on different strategies for requirements
traceability, see the white paper, "Traceability Strategies for Managing Requirements
with Use Cases" [5].

Hal 33 dari 117

Figure 5 - Requirements 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.

Figure 6 - Defining Requirement Attributes for Features

In Figure 7, instances of feature requirements are displayed for a specific project in

RequisitePro. Note that even without displaying the entire text for each requirement, we
can learn a great deal about each requirement from its attribute values. In this case, its
priority and difficulty – no doubt assigned by different members of the team – will help

Hal 34 dari 117

the team begin to scope the project to available resources and time, taking into account
both stakeholder priorities and a very rough estimate of effort reflected in the difficulty
attribute value. In more detailed types of requirements, the priority and effort attributes
may have more specific values (e.g., estimated time, lines of code, etc.) with which to
further refine scope. This multi-dimensional aspect of a requirement, compounded by
different types of requirements – each with its own attributes – is essential to organizing
large numbers of requirements and to managing the overall scope of the project.

Figure 7 - Setting Attribute Values for each Requirement

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.

Putting Requirements Management to Work

Requirements management employs the key skills and concepts presented above to
identify and resolve the problems successfully.

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.

Hal 35 dari 117

Detailed software requirements should be written in such a form as can be understood by
both the customers and the development team. We have found that using the language of
the customer to describe these software requirements is most effective in gaining the
understanding and agreement. These detailed software requirements are then used as
input for the system design specifications as well as for test plans and procedures needed
for implementation and validation. Software requirements should also drive the initial
user documentation planning and design.

Figure 8 - Overview of the Requirements Management Structure

To facilitate this, the project team should:

• Agree on a common vocabulary for the project.

• Develop a vision of the system that describes the problem to be solved by the
system, as well as its primary features.
• Elicit stakeholders needs in at least five important areas: functionality, usability,
reliability, performance, and supportability.
• Determine what requirement types to use.
• Select attributes and values for each requirement type.
• Choose the formats in which requirements are described.
• Identify team members who will author, contribute to, or simply view one or
more types of requirements.
• Decide what traceability is needed.
• Establish a procedure to propose, review, and resolve changes to requirements.
• Develop a mechanism to track requirement history.
• Create progress and status reports for team members and management.

These essential requirements management activities are independent of industry,

development methodology, or requirements tools. They are also flexible, enabling
effective requirements management in the most rigorous and the most rapid application
development environments.

Hal 36 dari 117

 A Few Words about Documents

The decision to describe requirements in documents deserves some thought.

On one hand, writing is a widely accepted form of communication and, for
most people, a natural thing to do. On the other hand, the goal of the project
is to produce a system, not documents.

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.

Requirements Management: Workflow Details

Requirements management can follow an infinite number of domain-specific paths. The
following approach prescribes six detailed workflows that apply to each of the key
requirements management skills but can be applied to any domain.

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.

Hal 37 dari 117

Figure 9 - Requirements Workflow in the Rational Unified Process

Workflow Detail: Analyze the Problem

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

Hal 38 dari 117

element of the use-case model, which will define the system’s functional and non-
functional technical requirements.

Figure 10 - Analyzing the Problem

Workflow Detail: Analyze the Problem

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 of define the problem

Affects Stakeholders
The Impact of the Problem is
A Successful Solution would
list the stakeholders affected by the
problem
describe the impact of the problem
list some key benefits of a successful
solution

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.

Hal 39 dari 117

 Introduction of the Use-Case Model

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.

Jacobson I., Christerson M., Jonsson P., Overgaard G., Object-Oriented

Software Engineering – A Use Case Driven Approach, Addison Wesley –
ACM Press, 1992

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

Hal 40 dari 117

process has been initiated separately. Although not addressed further in this paper, the
business case describes:

• the context (product domain, market, and scope),

• the technical approach,
• the management approach (schedule, risk, objective measure of success),
• and the financial forecast.

Workflow Detail: Understand Stakeholder Needs

If the initial problem analysis justifies additional investment, the Understanding

Stakeholder Needs workflow begins in earnest. The key activity is eliciting stakeholder
requests. The primary outputs are collections of prioritized stakeholder needs and
features, which enable refinement of the vision document, as well as a better
understanding of the requirements attributes. Also, during this workflow you may start
discussing the system in terms of its use cases and actors. Another important output is an
updated glossary of terms to facilitate common vocabulary among team members.

Figure 11 - Understanding Stakeholder Needs

Workflow Detail: Understand Stakeholder Needs

The system analyst and key stakeholders identify additional stakeholders, elicit their
requests and determine key needs and features via interviews, workshops, storyboards,

Hal 41 dari 117

business process use cases, and other techniques. One or more system analysts facilitate
these sessions. These requirement workshops are among the most useful elicitation
techniques. The process includes users, help-desk personnel, business owners, testers,
and others who have a stake in the outcome of the proposed project. Stakeholder requests
are often ambiguous, overlapping, and even extraneous. In addition to formal elicitation
results, stakeholder requests may be expressed in well-formatted documents, defect and
enhancement requests from databases, or e-mail and groupware threads. System analysts
record, categorize, and prioritize the identified key stakeholder needs.

Understand Stakeholder Needs: Where "Delighting Customers"

Begins

Stakeholder requests are captured as much as possible in the language and

format of the requesting stakeholder. Unlike subsequent requirement types
that are usually authored by process-educated and technically proficient
project team members, stakeholder requests are often expressed poorly. They
are duplicated or overlap. They can be expressed on anything from slips of
paper to enhancement-request databases.

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.

Demonstrating serious concern for eliciting requests and satisfying

stakeholder needs by applying the Understanding Stakeholder Needs
Workflow can be critical to establishing stakeholder confidence in the
abilities of the development team.

Based on a better understanding of stakeholder needs, the system analysts in the

development team refine the vision document, paying special attention to developing a
"product position statement". In two or three sentences, this statement establishes the
compelling value of the project. The statement should include intended users, the
problems it solves, the benefits it delivers, and the competitors it replaces. All team
members should understand this project theme. System analysts also update the glossary
to facilitate common understanding of terms.

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

Hal 42 dari 117

between stakeholder requests, needs and system features, so stakeholders can be sure
their inputs were considered.

Workflow Detail: Define the System

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.

Figure 12 - Defining the System

Workflow Detail: Define the System

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

Hal 43 dari 117

should be noted that many non-functional requirements of these types are specific to a
single use case. It is better for use case specifiers to place these requirements in the use
case specification itself (see the Refining the System workflow), leaving the
supplementary specification for system-wide non-functional requirements.

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.

Workflow Detail: Manage the Scope of the System

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.

Hal 44 dari 117

Figure 13 - Managing the Scope of the System

Workflow Detail: Manage the Scope of the System

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.

System analysts manage dependencies by refining requirement attributes for features in

the vision. They also refine requirements in use cases and supplementary specifications.
System analysts ensure that appropriate traceability* exists for stakeholder needs,
features, use-case requirements, and supplementary specification requirements. The term
"appropriate traceability" is deliberate. See the inset text on Traceability later in this
paper.

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

Hal 45 dari 117

dependencies have been managed in the previous three workflows, this step is much
easier, and future changes will be easier.

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.

Workflow Detail: Refine the System Definition

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.

Hal 46 dari 117

Figure 14 - Refining the System Definition

Workflow Detail: Refine the System Definition

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.

Hal 47 dari 117

The results of this system definition refinement are submitted to another round of the
Managing Scope workflow detail. Once you know more about the system, you may want
to change the priorities. Most definitely, the scope of the system release will need to be
reviewed and refined, if necessary.

Workflow Detail: Manage Changing Requirements

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

Much is made of traceability in the requirements field. Many promote the

virtue of tracing individual customer requirements to each related
specification, test, model element, and ultimately source code files. Certainly,
some traceability is the key to successful requirements change management.

Be forewarned, however, that all forms of traceability require an investment

to set up and maintain during the life of the project. Like all investments,
traceability has diminishing points of return depending on your specific
situation. This paper emphasizes the value of tracing between different types
of requirements. This is a good place to start and can be automated by tools
such as Rational RequisitePro, Rose, SoDA and TeamTest. We believe you
will find some level of requirements traceability to be a good investment.

For more information on different strategies for requirements traceability, see

the white paper, "Traceability Strategies for Managing Requirements with
Use Cases" [6].

Another important concept to Manage Changing Requirements is requirement history

tracking. By capturing the nature and rationale of requirements changes, reviewers
(anyone on the software project team whose work is affected by the change) receive the
information needed to respond to the change properly.

Hal 48 dari 117

Figure 15 - Managing Changing Requirements

Workflow Details: Manage Changing Requirements

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:

• defects in implementation that do not affect requirements,

• modifications to existing requirements of some type, or
• enhancement requests.

Once classified, the proposed changes to requirements are assigned attributes and values
as described in other requirements workflows.

Hal 49 dari 117

In reviewing change requests, the system analyst presents proposed prioritized
requirement changes to a CCB comprised of representative stakeholders and project team
members. Scope modifications that exceed resources should be rejected or elevated to
stakeholder representatives that are empowered to approve required changes to date and
budget commitments.

The CCB approves or rejects changes to requirements.

The system analyst communicates requirements changes to requirements specifiers or

makes changes directly to requirements in the vision, use cases, supplementary
specification documents or other requirements artifacts.

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.

Hal 50 dari 117

For a complete discussion of the above concepts, refer to the excellent book by Dean
Leffingwell on Managing Software Requirements [7].

References
[1] CHAOS, The Standish Group International, Inc., Dennis, MA, 1994, 1997.

[2] Computer Industry Daily, December 12, 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.

Hal 51 dari 117

Kel 5 dan 6
Traceability Strategies for Managing Requirements with
Use Cases
by Ian Spence, Rational U.K. and Leslee Probasco, Rational Canada, ©Copyright 1998
by Rational Software Corporation. All Rights Reserved. (Version 1.0)

TABLE OF CONTENTS

1. Abstract

2. Introduction / Background

2.1 Traceability Items

2.2 Implicit and Explicit Traceability

2.3 Managing the Supporting Artifacts

2.4 Possible Traceability Strategies

2.5 Why Would We Want To Adopt One of the Hybrid Approaches?

3. About the Traceability Strategy Catalogue

4. Traceability Strategy Catalogue

4.1 Diagramming Notation

4.2 Supporting Traceability Types

4.3 No Use Case Model

4.4 Use Case Model Only

4.5 The Use-Case Model defines the Product Features

4.6 Features Drive the Use Case Model

4.7 The Use-Case Model is an interpretation of the Software Requirements

Specification

Hal 52 dari 117

4.8 The Use Case Model Reconciles Multiple Sets of Traditional Software
Requirements

Hal 53 dari 117

1. Abstract
In many commercial applications of use case modeling techniques the use case model
must be combined with more traditional requirements capture techniques to provide a
requirements management process acceptable to all of the stakeholders involved in the
project. This paper explores the traceability strategies available to organizations adopting
use case modeling techniques as part of their requirements management strategy.

2. Introduction / Background

2.1 Traceability Items

A common point of confusion when discussing Requirements Management, especially
when using a tool such as RequisitePro, is the overloading of the term “requirement”. In
addition to items commonly defined as “requirements”, we need to capture and track the
attributes of, and traceability between, many other kinds of item. These other traceability
items include issues, assumptions, requests, glossary terms, Actors, Tests etc.

Capturing and tracking these other kinds of traceability item helps us in effectively
managing our project’s requirements.

Definition: Traceability Item

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.

With respect to RequisitePro this definition can be rephrased as:

Any textual or model item represented within RequisitePro by an instance of a

RequisitePro requirement type.

Hal 54 dari 117

RequisitePro itself provides an excellent tool for defining, capturing and tracking the
values, attributes and traceability links between the many kinds of traceability item
involved in software development.

2.2 Implicit and Explicit Traceability

There is a certain amount of traceability implicit in any development process. This is
usually supplied by the formal relationships between the artifacts in the process.

Examples of this sort of implicit traceability are:

• Naming conventions
i.e. the class in the design model called Fred is implemented by the class in the
implementation model called Fred

• The construction of mappings between the models

i.e. the component view in Rose allows the packages and classes in the logical view
in Rose to be explicitly mapped to packages in the implementation model. This
mapping can contain re-naming between the models and the application of different
packaging strategies

• Relationships between the model items themselves

i.e. in the Rational Unified Process the use case realizations in the design model are
traced back to the use-cases they realize.

• 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.

Hal 55 dari 117

The figure shows the models and the implicit relationships between these models. The
relationship between the models provides a level of traceability that is implicit to the
development process.

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.

Hal 56 dari 117

The implicit traceability is limited to the relationships available in our modeling notation.

So why would we want any additional explicit traceability?

Well if we are to adopt the principles of requirements traceability we would need to

integrate the Requirements, model items and other traceability items into a traceability
hierarchy. We may also want to add additional traceability relationships into our
development process.

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

Hal 57 dari 117

If we look at the relationship between the supplementary requirements (defined in the
Supplementary Specifications document) and the design, and implementation, models we
will see that this is not covered by the implicit traceability between the models.

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.

Other examples include the relationships between:

Hal 58 dari 117

- the features of the system and the use case model

- the use case model and the user documentation

- the use case model and the test requirements.

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.

2.3 Managing the Supporting Artifacts

Figure 1 above shows the artifacts involved in requirements specification in the RUP.

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.

Hal 59 dari 117

Figure 2 below shows how a traditional SRS document is often related to the RUP
artifacts. The traditional SRS is just an alternative way of documenting the Software
Requirements. It is important to realize that both approaches can provide us with a
Software Requirements Specification that defines the complete external behavior of the
system to be built.

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.

2.4 Possible Traceability Strategies

2.4.1 Is there more than one acceptable traceability strategy?

Hal 60 dari 117

There are many traceability strategies that could be used to facilitate the requirements
management process, even working within the framework of the Rational Unified
Process many approaches are possible. Four of the most common, all of which the
authors have seen in use, are:

1. Use-Case Model Only.

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.

2. Features Drive the Use Case Model

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.

3. The Use-Case Model is an interpretation of the Software Requirements Specification

Hal 61 dari 117

 In this case the Use Case Model is an interpretation of a formal, traditional Software
Requirements Specification. This is most often used when a formal, traditional
Software Requirement Specification is mandated due to regulatory, or internal,
protocol and a use case model is required to enable the practice of use case driven
development.

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.

Hal 62 dari 117

2.5 Why Would We Want To Adopt One of the Hybrid
Approaches?
As we can see the two extreme solutions (Use Case Model Only and No Use Case
Model) above take a very purist view only allowing one form of requirement’s capture.
Both of them assume that a one-size-fits-all approach is applicable to all projects and all
stakeholder communities. Both approaches have seen their fair share of success but have
fallen into disrepute because of their inflexibility and inability to handle all of the
complex situations, and sets of stakeholder relationships, that arise in "real world"
projects.

The Rational Unified Process recommends the following traceability hierarchy:

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).

Hal 63 dari 117

• Where the project is being undertaken within an organization that insists upon
compliance with an existing traditional requirements capture process.
• Where there are problems in getting the stakeholders to attend modeling workshops to
produce a single, consensus requirements model.
• Where Use-Case Modeling is to be used to enable Object Oriented software
development within the constraints of an existing requirements capture process.
• Where the stakeholder community is unable, or unwilling, to express all of their
functional software requirement level desires directly within the use-case model.
• Where the customer has defined the product to be delivered in the form of a set of
traditional software requirements. This is a very common situation when a
development is put out to tender – the traditional requirement statement then becomes
part of the contract for delivery.

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.

Hal 64 dari 117

3. About the Traceability Strategy Catalogue
To be able to define our traceability strategies we need a mechanism to categories and
define our traceability items:

Definition: Traceability Type

A categorization of traceability item (e.g. need, product feature, use case,

software requirement, test requirement, actor, glossary term, etc) based on
common characteristics and attributes.

Note: in RequisitePro Traceability Types will be represented by Requirement Types.

Setting up a traceability strategy therefore involves three closely coupled activities:

1. Identify the set of traceability types required to define our traceability items.

2. Identify the valid traceability relationships between these traceability types.

3. Identify the attributes required by the traceability items to enable effective

requirements management for the project.

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

Hal 65 dari 117

2 Product Features

3 Software Requirements (both functional and non-functional)

4 Glossary Items

5 Use Cases

6 Use Case Sections

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.

There are two levels of traceability between our traceability items:

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

Hal 66 dari 117

 strategies. This traceability is much more subjective and varies between the various
traceability strategies.

4. Traceability Strategy Catalogue

4.1 Diagramming Notation

The Traceability Types and their traceability relationships are shown as Unified
Modeling Language (UML) diagrams. The figure below shows how to interpret the
usage of the UML in this context.

Hal 67 dari 117

To fully understand the diagrams it is useful to know the implementation mapping used
when implementing the definitions in RequisitePro. The table below explains how the
diagramming notation can be mapped onto RequisitePro projects.

Diagramming RequisitePro Mapping

Notation
Class / Traceability Requirement Type
Type
Relationships The RequisitePro "trace-to" relationships
Aggregations Hierarchical Requirements
Generalization Classification of the super Requirement Type by
adding an additional "sub-classification" attribute.

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.

Hal 68 dari 117

4.2 Supporting Traceability Types
4.2.1 Description

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.

4.2.3 Traceability Types

Traceability Type Description

Glossary Term This Traceability Type defines the traceability items
representing Glossary Terms and their definitions.

This is included in the set of supporting traceability

types, as a Glossary is required regardless of which
traceability strategy you choose to adopt.
Issue This Traceability Type allows you to add traceability

Hal 69 dari 117

 items representing issues you want to track within
RequisitePro. These issues can then be associated
with whichever traceability items that they impact.

An example of using the Issue traceability type

would be to track issues associated with Glossary
Items. If a definition is uncertain, or in dispute,
issues could be raised and including in RequisitePro.
This will ensure that the issue is not forgotten and
allows a view to built reporting on all Glossary Items
with outstanding issues. Another good use of this
traceability type is to track issues raised when
reviewing the use cases and other development
artifacts.
Assumption This Traceability Type allows you to track the
assumptions that you have made. The assumptions
can then be associated with whichever traceability
items they affect.
Supporting Document This Traceability Type allows you to add any
documents that you like into the traceability
hierarchy. This is particularly useful for including
pre-existing examples or documentation that clarifies
the meaning or purpose of another traceability item.
The flexible traceability mechanisms of RequisitePro
allow you to associate supporting documentation
with any traceability item of any type.
An example of using the Supporting Document type
is to include the detailed EDI message specifications
as supporting information for the Glossary, or as
appendices to the use cases that will use the
messages.

4.2.4 Basic Traceability

Traceability Link Description

Glossary Term to This relationship allows us to capture both the name
Glossary Term of the Glossary Term and its definition using a single
traceability type.
Supporting These supporting traceability types can be traced to
Traceability Type to any of the other traceability types involved in the
any other Traceability chosen traceability strategy.
Type

Hal 70 dari 117

4.3 No Use Case Model
4.3.1 Description

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

Characteristic Value Comment

Explicit High Projects practicing requirements
Traceability management techniques without the use
of use cases typically maintain a high
level of explicit traceability between the
traceability types.
Trust Low
Accountability High
Formality High
Completeness Low It is very difficult to assess a set of
traditional software requirements for
completeness.
Document Set Large The document set is usually measured
in feet not inches.
Focus Contract The focus of the requirements capture
process is on establishing a legally
enforceable contract between the
customers and the developers rather
than establishing a shared
understanding of the problem to be
solved and the proposed solution.
Understandability Low The requirements documentation is
often inaccessible to both the user
community and the developers. It
usually consists of many individual line
items grouped by type or functional
area providing little context for
reviewers.
Process Typically Traditional requirements capture
Waterfall techniques are often practiced as part of

Hal 71 dari 117

 a waterfall development process. The
lack of context for, and the difficulty in
assessing the completeness of, any
subsets of the requirements does not
facilitate the adoption of iterative and
incremental development processes.
Development Functional The grouping of requirements by type
Style Decomposition or functional area tends to lead to
continued functional decomposition as
the requirements are translated into a
solution.

Hal 72 dari 117

4.3.3

Traceability Overview

4.3.4 Traceability Types

Requirement Type Description

Need The business or operational problem (opportunity)
that must be fulfilled in order to justify purchase
or use. Also known as Goal or Objective.
Product Feature A capability or characteristic of a system that
directly fulfills a Need. Often thought of as the
"advertised benefits" of the system.
Software Requirement A condition or capability to which the software

Hal 73 dari 117

 being built must conform.

4.3.5 Traceability Summary

Traceability Link Description

Needs trace to Product Each Need will be realized by a set of Features.
Features This relationship allows the business benefit of
each Feature to be tracked.
Product Features trace to Each Feature will be realized by a set of Software
Software Requirements. Requirements.

This relationship allows the business benefit of

each Software Requirement to be tracked and
enables the scope management of the Software
Requirements at the Product Feature level.

4.3.6 Benefits and Disadvantages

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).

- Recommended by many standard processes.

- Enables detailed, low level, formal traceability.

- 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.

- Hard to understand requirements expressed in this form.

- Impact analysis of requirements change is hard to assess.

- Individual requirements have no context.

- High maintenance costs. The lack of any implicit traceability leaves projects with the
cost of maintaining large amounts of explicit traceability relationships.

Hal 74 dari 117

- The lack of context makes it difficult to identify meaningful sub-sets of the
requirements. This in turn makes scope management, and the incremental delivery of
the product, more difficult.

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.

Hal 75 dari 117

4.4 Use Case Model Only
4.4.1 Description

"The use-case model is my requirements." A close association, and high level of

trust, between the customers and the developers usually characterize projects that
adopt this approach. It is normally used for internal, low-accountability projects
where the developers hope to demonstrate, or gain, a clear understanding of the
requirements by developing the use-case model along with (or approved by) the
customer(s).

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

Characteristic Value Comment

Explicit Low No explicit traceability required. The
Traceability implicit traceability that is provided by
adopting a use case driven approach is
considered sufficient. Probably no explicit
traceability is maintained, so no
Requirements Management tool is used.
Trust High The lack of any needs or feature level
analysis means that the developers of the
use case model are given a high level of
trust by the stakeholders to deliver the right
system.
Accountability Low
Formality Low
Completeness Low Although a use case model itself facilitates
establishing the completeness of the
software requirements specification the
lack of any traceability back to the
stakeholder needs often leads to the
production of an incomplete, or over
elaborate, system.
Document Set Small This approach involves the minimal
document set.
Focus User The use case model has a user perspective.
Understandability High The use case model is easy to understand

Hal 76 dari 117

 for all of the stakeholders in the project.
Process Typically The use cases place the software
Iterative and requirements in context facilitating
Incremental iterative and incremental development (the
use case provides a good unit of delivery).
Use cases can also be used with Waterfall
development processes.
Development Typically Typically the use cases are used to drive
Style Object object oriented software developments
Oriented although use cases will work with any style
of development. If an OO style is not
adopted then a high level of explicit
traceability will be required

Hal 77 dari 117

4.4.3 Traceability Overview

4.4.4 Traceability Types

Traceability Type Description

Use Case This Traceability Type defines the traceability
items representing the Use Cases.
Use Case Section The Use Case Section enables us to include the
sections of the Use Cases in our traceability
hierarchy.

This allows us to trace into the individual flows,

Hal 78 dari 117

 and the other properties that comprise the use case.

The presence of the hierarchical relationship to

sub-sections allows us to capture the individual
pieces of each section. For example this would
enable us to identify the individual pre-conditions
that make up the pre-conditions section.

Note: In some cases it may be applicable to

identify the individual software requirements
within the flow of events of the use case (in this
case very small sections) but this should not be
attempted until the use case itself is stable.
Actor This Traceability Type defines the traceability
items representing the Actors.

Hal 79 dari 117

4.4.5 Traceability Summary

Traceability Link Description

Use Case to Use Case Each use case is made up of a set of use case
Section sections. This relationship allows us to track
which use case sections make up which use case.
Use Case Section to Use Some of the more complex use case sections are
Case Section made up of many sub-sections. For example a
flow of events may be made up of many sub-flows
or the pre-condition section may be made up of
many pre-conditions.
Use Case to Actor This relationship allows us to see which Actors are
involved in which use case.
Actor to Actor This relationship allows us to capture both the
name of the Actor and its brief description using a
single traceability type.

4.4.6 Benefits and Disadvantages

Pros:

- Minimal document set

- Minimal effort involved in Requirements Management

- Good support for scope management, impact analysis and incremental development.

- Use cases are easy to understand.

Cons:

- There is no relationship back to the stakeholder needs. No real attempt is made to

analyze the problem before starting on the definition of the solution.

- 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

Hal 80 dari 117

This approach is usually used for small scale, informal, internal projects where the
developers and the users work very closely together.

Hal 81 dari 117

4.5 The Use-Case Model defines the Product Features.
4.5.1 Description

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.

Characteristic Value Comment

Explicit Low As Use Case Model Only. There will be
Traceability only a small set of needs and this small
amount of additional traceability still
results in small amounts of explicit
traceability being required.
Trust Medium / The addition of Needs to the Use Case
High Model makes this a slightly less trusting
strategy than having a Use Case Model
Only
Accountability Low
Formality Low
Completeness Medium The use case model itself facilitates
establishing the completeness of the
software requirements specification the
additional traceability back to the
stakeholder needs helps to validate the
applicability of the use case model.
Document Set Small This approach involves a minimal
document set. Use Case Model plus
Vision Document containing the Needs.

Hal 82 dari 117

 Focus User The use case model and the needs both
have user perspective.
Understandability High The needs and the use case model are both
easy to understand for all of the
stakeholders in the project.
Process Typically As Use Case Model Only
Iterative and
Incremental
Development Typically As Use Case Model Only
Style Object
Oriented

Hal 83 dari 117

4.5.3 Traceability Overview

4.5.4 Traceability Types

Traceability Type Description

Need As defined for "No Use Case Model"
Use Case As defined for "Use Case Model Only"

4.5.5 Traceability Summary

Traceability Link Description

Need to Use Case In this case the Needs trace directly to the use
cases. The assumption being that the use cases
can play the role of the product features when
product and scope managing.

4.5.6 Benefits and Disadvantages

Hal 84 dari 117

This approach is very similar to the "Use Case Model Only" strategy. The benefits and
disadvantages are the same with the following additions and caveats.

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.

Hal 85 dari 117

4.6 Features Drive the Use Case Model
4.6.1 Description

"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

Characteristic Value Comment

Explicit Medium In addition to the use case model's
Traceability implicit traceability, in this case, we
have to explicitly maintain the
traceability between the needs, features
and the use case model.
Trust Medium
Accountability High
Formality Medium The addition of Needs and Product
Features to the Use Case Model gives
rise to a more formal requirements
management process than just
maintaining a Use Case Model.
Completeness High Having both the Feature and the Use
Case perspective on the Software
Requirements makes it possible to
achieve a high level of completeness
with regards to capturing and
prioritizing the Software Requirements.
Document Set Medium We now have a Vision document
containing needs and features, a Use
Case Model and a Supplementary
Specification.
Focus Users, The addition of needs and features to the
Stakeholders use case model broadens the focus of
and Project the requirements activity to more
Managers actively encompass the product manager

Hal 86 dari 117

 and all of the other stakeholders as well
as the users. Features are a very
powerful tool for managing stakeholder
expectations and provide a good
complement to the use case perspective
of the software requirements.
Understandability High The definition of needs and features
alongside a use case model with
supplementary specifications provides a
requirements model that is easily
understandable by all of the
stakeholders in the project.
Process Typically As Use Case Model Only.
Iterative and
Incremental
Development Style Typically As Use Case Model Only.
Object
Oriented

Hal 87 dari 117

4.6.3 Traceability Overview

4.6.4 Traceability Types

Traceability Type Description

Need As defined for "No Use Case Model"
Product Feature As defined for "No Use Case Model"
Use Case As defined for "Use Case Model Only"
Software Requirement Any software requirements that apply to the whole
system or do not fit easily into a use case. Where
a software requirement is a condition or capability

Hal 88 dari 117

 to which the software being built must conform.
Use Case Section As defined for "Use Case Model Only"
Actor As defined for "Use Case Model Only"

Hal 89 dari 117

4.6.5 Traceability Summary

Traceability Link Description

Need to Product Feature As defined for "No Use Case Model"
Product Feature to Use Optional traceability link. The Product Feature
Case may trace directly to Use Cases. This allows the
Product Features to be assigned to Use Cases
before the Use Case Sections have been written
and allows you to do impact analysis on the Use-
Case Model at the Product Feature level and vice
versa.
Product Feature to Use The Product Features trace to the Use Case
Case Section* Sections. This allows the Use Case Model to be
scope managed on a Feature basis and facilitates
impact analysis between the Feature set and the
Use Case Model at a level more applicable than
the Use Case itself.

All Product Features traced to a Use Case must

also trace to one of the sections of the use case.
Product Feature to The Product Features also trace to the Software
Software Requirement* Requirements in the Supplementary Specification.
All Product Features that do not trace into the use
case model must trace to at least one of the
software requirements in the Supplementary
Specification.
Use Case to Actor As defined for Use Case Model Only
Use Case to Use Case As defined for Use Case Model Only.
Section

*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.

4.6.6 Benefits and Disadvantages

This approach maximizes the benefits provided by both the use case and traditional
requirements management approaches whilst minimizing the disadvantages.

Pros:

- Well understood

- Recommended by the Rational Unified Process.

Hal 90 dari 117

- Enables detailed, low level, formal traceability.

- 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 software requirements are expressed in an easy to understand form.

- Impact analysis of requirements change is facilitated by this traceability strategy - the

impact of not implementing a feature or a use case section can be clearly understood.

- 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.

- Minimal complete document set.

- Minimizes the effort involved in Requirements Management.

- 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:

- Not acceptable in all organizations

- Some people consider it difficult to write a contract based on Software Requirements

expressed mainly as a use case model although many organizations have successfully
achieved this.

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.

Hal 91 dari 117

4.7 The Use-Case Model is an interpretation of the
Software Requirements Specification.
4.7.1 Description

"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.

A traditional SRS is often considered an essential part of reaching a contractual

agreement when outsourcing or undertaking a fixed price development. This leads to two
typical situations:

1 The development organization is supplied with a traditional SRS, by the customer, as

the starting point for their system's development.

2 The SRS document is a mandatory or regulatory deliverable early in the project

lifecycle. Every project must have a traditional, formal SRS document expressing the
systems requirements in the same way as all of the other projects.

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

Characteristic Value Comment

Explicit Very High All of the explicit traceability required by
Traceability the "No Use Case Model" approach is
required to maintain the formal SRS plus

Hal 92 dari 117

 there is the additional overhead of tracing
the traditional software requirements into
the use case model.
Trust Very Low This is a very "belt and braces" approach
implying a very low level of trust.
Accountability High
Formality Very HighAgain this is a very formal approach with
two requirement management approaches
being applied in parallel.
Completeness Very High The complementing of the traditional
Software Requirements Specification
with a Use Case Model makes this a very
high completeness approach. Note: in
this case it is assumed that it is the Use
Case Model which will ensure a complete
specification of the systems functionality.
The set of Software Requirement
Specifications need not be to the same
level of completeness.
Document Set Very Large In this situation we are basically
specifying the system twice.
Focus Contracts The adoption of this approach is driven
by the need to either fulfill an existing
contract, expressed by a traditional SRS,
or fit in with an existing development
methodology requiring an SRS as the
contract between the developers and the
customers.
Understandability Medium The production of two Software
Requirement definitions can be confusing
at first but the use of the use case model
as the master software requirement
definition should lead to an easily
understandable statement of the systems
requirements.
Process OPEN There is enough stuff flying around to
support almost any development process
although the use case model is often
added to a traditional SRS to enable the
use of Iterative and Incremental
techniques.
Development Style OPEN There is enough stuff flying around to
support almost any development style
although the use case model is often
added to a traditional SRS to enable the
use of Object Oriented techniques.

Hal 93 dari 117

4.7.3

Traceability Overview

4.7.4 Traceability Types

Traceability Type Description

Need As defined for "No Use Case Model"
Product Feature As defined for "No Use Case Model"
Software Requirement As defined for "No Use Case Model"

Hal 94 dari 117

 Use Case As defined for "Use Case Model Only"
Actor As defined for "Use Case Model Only"
Use Case Section As defined for "Use Case Model Only"
Glossary Term As defined for "Use Case Model Only"
Supplementary Any software requirements that apply to the whole
Requirement system or do not fit easily into a use case. These
may not need to be restated from the original set
of software requirements but may just be the in
scope software requirements that are not traced to
the use case model.

4.7.5 Traceability Summary

Traceability Link Description

Need to Product Feature As defined for "No Use Case Model"
Product Feature to As defined for "No Use Case Model"
Software Requirement
Software Requirement to Functional Software Requirements are traced to
Use Case Use Cases.
A sub-set of non-functional Software
Requirements also trace to Use Cases.
This relationship allows the high level scoping
and assessment of the Use-Case Model in terms of
the Use Case’s requirements and business
benefits.
Note: All in scope functional requirements must
trace to use cases or to the Glossary. If they are
not reflected in this way then they will not be
implemented.
Software Requirement to The Software Requirements that are traced to a
Use Case Section Use Case must also trace to one of the Use Case’s
Use-Case Sections.
This relationship allows the verification of a Use
Case’s Use-Case Sections with regard to the
requirements placed upon the Use Case. All of
the Software Requirements traced to a Use Case
must be fulfilled by one of the sections within the
Use Case. The double traceability allows us to
verify this and to allocate the Software
Requirements to the Use Cases themselves before
considering the Use-Case Sections required.

It is possible that some sections will have no

matching Software Requirements.

Note: All functional requirements that trace to a

Hal 95 dari 117

 use case must also trace to one of the use case’s
sections. If they are not reflected in this way then
they will not be implemented.
Software Requirement to Functional and non-functional requirements may
Glossary Term trace to items in the Glossary. This is particularly
true for “static requirements” that identify the
attributes and relationships of the entities involved
in the system. If a Glossary Term is traced from a
Software Requirement then the Glossary Term
must be used in one of the use cases or it is
unlikely to be carried forward into the Design
Model.
Use Case to Actor As defined for "Use Case Model Only"
Use Case to Use Case As defined for "Use Case Model Only"
Section
Software Requirement to The Supplementary Requirements may restate the
Supplementary Software Requirements that apply to the whole
Requirements system or do not fit easily fit into the use case
model. An alternative approach is to regard all of
the in scope Software Requirements that do not
trace to the use case model as Supplementary
Requirements - this would avoid restating them.

Hal 96 dari 117

4.7.6 Benefits and Disadvantages

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:

- Enables very detailed, low level, formal traceability.

- The software requirements are expressed in an easy to understand form.

- Impact analysis of requirements change is facilitated by this traceability strategy - the

impact of not implementing a feature, a software requirement or a use case section
can be clearly understood.

- 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

- A very large document set must be maintained.

Hal 97 dari 117

- There is a lot of duplication that complicates the requirements management process.
The traditional Software Requirements are likely to fall into disuse as the use cases
are updated directly with requirement changes.

- This is a very high cost / high maintenance approach.

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.

Hal 98 dari 117

4.8 The Use Case Model Reconciles Multiple Sets of
Traditional Software Requirements
4.8.1 Description

"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.

Characteristic Value Comment

Explicit Very High As "Use Case Model is an
Traceability interpretation of the Software
Requirements Specification".
Trust Very Low As "Use Case Model is an
interpretation of the Software
Requirements Specification".
Accountability Very High In this case we preserve all of the
individual customer perspectives in
their own SRSs.
Formality Very High As "Use Case Model is an
interpretation of the Software
Requirements Specification".
Completeness Very High As "Use Case Model is an
interpretation of the Software

Hal 99 dari 117

 Requirements Specification".
Document Set Very Large In this case we have multiple
specifications of the desired system
which are reconciled by the single
Use Case Model.
Focus Managing multiple The focus of this approach is in the
independent management of multiple,
customers. independent, possibly contradictory
requirements sources who are
politically, geographically or
organizationally unable to work
closely together.
Understandability Medium As "Use Case Model is an
interpretation of the Software
Requirements Specification".
Process Typically Iterative In this case the developers use the
and Incremental. Use Case Model as their SRS. See
"Use Case Model Only"
Development Style Typically Object In this case the developers use the
Oriented Use Case Model as their SRS to
drive the software's development.
See "Use Case Model Only"

Hal 100 dari 117

4.8.3

Traceability Overview

4.8.4 Requirement Types

Requirement Type Description

Need As defined for "No Use Case Model"
Product Feature As defined for "No Use Case Model"
Software Requirement As defined for "No Use Case Model"
Use Case As defined for "Use Case Model Only"
Use Case Section As defined for "Use Case Model Only"
Glossary Term As defined for "Use Case Model Only"
Supplementary Any software requirements that apply to the whole
Requirement system or do not easily fit into a use case.

Hal 101 dari 117

4.8.5 Traceability Summary

Traceability Link Description

Need to Product Feature As defined for "No Use Case Model"
Product Feature to As defined for "No Use Case Model"
Software Requirement
Software Requirement to As for Use Case Model is interpretation of SRS
Use Case
Software Requirement to As for Use Case Model is interpretation of SRS
Use Case Section
Software Requirement to As for Use Case Model is interpretation of SRS
Glossary Term
Software Requirement to In this case the software requirements must be
Supplementary restated in the Supplementary Specifications
Specification document that supports the use case model to
allow the production of a single, consistent,
compete SRS for the development that draws open
information from the multiple, individual
stakeholder SRSs.

4.8.6 Benefits and Disadvantages

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

Hal 102 dari 117

stakeholders were widely differing requirements, in many cases the insurers had
completely contradictory requirements to the Brokers.

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.

Hal 103 dari 117

Kel 7 dan 8
Concepts: User-Centered Design
Topics

o Why user-centered design?

o Meeting users needs
o User interface design
o Legislation and standards
o What is user-centered design?
o Focus on users
o Integrated design
o Early user testing
o Iterative design
o User-centered design in RUP
o Contexts of use
o Scenarios, use cases and essential use cases
o Essential use cases in the Rational Unified Process

Why user-centered design?

Meeting user needs

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.

User interface design

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

Hal 104 dari 117

different to one used professionally by ticket sales staff. The main differences are not in
the requirements or even the detailed use cases, but the characteristics of the users and the
environments in which the systems might operate.

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.

Computer experience
Domain experience
Training
Low High
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)
Common terminology and Domain-specific terminology
concepts and concepts
Focus on ease of learning Focus on ease of use (direct,
(consistent, predictable, customizable, non-intrusive)
memorable)

Hal 105 dari 117

 Frequency of use Easy to learn and remember,
simple interface style
Motivation Rewarding to use, powerful
without seeming complex.
Easy to use, multiple
shortcuts and techniques to
allow user control
Sophisticated with many
advanced and customizable
features.

Table 1, Some factors affecting user interface design

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).

Legislation and standards

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:

Description Web Site

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

Hal 106 dari 117

 UNITED NATIONS
United Nations Standard http://www.un.org/esa/socdev/dissre00.htm
Rules on the Equalization of
Opportunities for Persons with
Disabilities
Social Development http://unescap.org/sps/sdinfo/disablinks.htm
Information on the Internet

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

Table 2a, Disability-related legislation by country, region or body

Aside from legislation, user-centered design and user interface design are increasingly
becoming the subject of standardization as shown below.

Description Web Site/Standards

ANSI www.ansi.org

ANSI ANSI and the Human Factors and Ergonomics Society

have published a number of joint standards. ANSI also
ANSI-HFES
has ANSI-NSC Z365 which relates to the control and
ANSI-NSC prevention of cumulative stress disorders (also known
as repetitive strain injury or RSI).

Hal 107 dari 117

 ANSI is drafting standards concerning human computer
interaction as part of the Information Infrastructure
Standards Panel (IISP) at
http://web.ansi.org/public/iisp/std_need/needcat.html.

ISO www.iso.ch

ISO 9241 A large series of standards mainly concerned with

ISO 10075: 1991
ISO 17041-1: 1995
ISO 11581
ISO 13407: 1999
ergonomics of workstations, but also includes guidance
on usability (part 11). Also the basis for ANSI-HFES
200, under development.
Ergonomic principles relating to mental work load
Cursor control for text editing
Series in development dealing with icons and pointers.
Standard for human-centered design processes for
interactive systems.

Table 2b, ANSI and ISO user interface and user-centered design standards

What is user-centered design?

There is no clear consensus on what constitutes user-centered design. However, John
Gould and his colleagues at IBM developed an approach in the 1980’s called Design for
Usability (GOU88) which encompasses most commonly-accepted definitions. It
developed from practical experience on a number of interactive systems, most notably
IBM’s 1984 Olympic Messaging System (GOU87). The approach has four main
components as described below.

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:

• Talk with users • Visit customer locations

• Observe users working • Videotape users working
• Learn about work organization • Try it yourself
• Get users to think aloud while working • Participative design
• Include expert users on the design team • Perform task analysis
• Make use of surveys and questionnaires • Develop testable goals

Hal 108 dari 117

 In RUP workshops are used at several key stages, but these must be complemented by
the kinds of activities Gould describes if an accurate picture is to be performed. (Part of
the argument behind this is that people frequently describe what they do quite differently
from how they do it. Commonly performed tasks and seemingly unimportant details such
as placement of work or the existence mysterious scraps of paper are often forgotten - or
omitted because they are not "officially" part of the current process.)

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

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

Hal 109 dari 117

Object-oriented development has become synonymous with an iterative process. Iterative
design is well-suited to problems that need a refinement of understanding and have
changing requirements. Not surprisingly, iterative design is a key component of user-
centered design. This is partly due to the changing needs of users over time, but also the
inherent complexity of producing design solutions that can deal with diverse needs.

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.

User-centered design in RUP

Developing systems appropriate to user needs means a significant effort in requirements
analysis. In user-centered design, this effort is focused on end users. These are a subset of
the human Business Actors (for users outside of the business) and Business Workers
found during the Business Modeling workflow. They are later described in greater detail
during the Requirements workflow as Actors. (The relationships between Actors,
Business Actors and Business Workers is discussed in Guideline: Going from Business
Models to Systems.)

However, a substantial point of emphasis in User-Centered design is that we understand

the requirements of the real people who will fill the roles described in the artifacts
mentioned above. In particular, we must avoid designing hypothetical humans for whom
it is convenient to design software systems. The artifacts describing end users must be
written only after substantial, first-hand contact with users. In user-centered design this
first-hand contact is part of a process sometimes called contextual inquiry. Hugh Beyer
and Karen Holtzblatt (in their book Contextual Design, BEY98) describe the premise of
contextual inquiry as:

"...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

Hal 110 dari 117

 Tasks Goals of use of the system, frequency and
duration of performance, health and safety
considerations, allocation of activities,
operational steps between human and
technological resources. Tasks should not be
described solely in terms of the functions or
features provided by a product or system.
Users (for each different type or Knowledge, skill, experience, education, training,
role) physical attributes, habits, preferences,
capabilities.
Environments Hardware, software, materials; physical and
social environments, relevant standards, technical
environment, ambient environment, legislative
environment, social and cultural environment

Table 3: Context of use from ISO standard for user-centered design

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: Relationships between 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.

ISO 13507 RUP Artifact

Context
Environments • High-level:
o Business Vision [Section: Customer
Environment],
o Stakeholder Requests,

o Vision [Section: User Environment]

Users • High-level:
o Business Vision [Section: Customer Profiles],
o Stakeholder Requests,

o Vision [Section: User Profiles]

Roles • High-level:
o Business Actor (external users),
o Business Worker (internal users)
• Detailed:

Hal 111 dari 117

 o Actor
Tasks • High-level:
o Stakeholder Requests,
o Vision [Section: Product Features]
• Detailed:
o Use-Case Storyboard

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.

Clearly tasks must be described individually, but a single description is unlikely to be

appropriate for all permutations. One approach is to factor the user and environment
contexts into the role description. This is the solution adopted by Constantine and
Lockwood (CON99). It involves providing a separate "user role" for each significant
permutation of role, user and environment, then naming the resulting user role with a
descriptive phrase, rather that a simple noun. Compare, for example, the role “Customer”
with the user roles “Casual Customer”, “Web Customer”, “Regular Customer” and
“Advanced Customer”.

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.

Scenarios, use cases and essential use cases

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.

Hal 112 dari 117

Figure 3 shows the nature of this overlap. The scale at the top incorporates a number of
different factors that tend to vary together. For example, as purpose moves more towards
requirements, structure usually becomes more formal. Essential use cases appear to the
right of generic use cases because user roles make them slightly more specific (see the
preceding section) and they have a more formal structure.

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):

User System Response

Action
insert card
read magnetic strip
request pint
enter PIN
verify PIN
display transaction option
menu
press key
display account menu
press key
prompt for amount
enter amount
display amount
press key
return card
take card
dispense cash
take cash

Table 5: Generic use case for getting cash from an ATM

Hal 113 dari 117

This example details the sequence of events between the actor and the system, with the
vertical line between the two columns representing the user interface. Notice that while
Constantine and Lockwood recommend this style for essential use cases, this particular
use case is not an essential one. The reason is that it based on the syntactic detail of the
interaction. That is, how the interaction takes place. An essential use case focuses on
what the interaction is about (called the semantics). Table 6 is the essential version of the
interaction.

User System Responsibility

Intention
identify self
verify identity
offer choices
choose
dispense cash
take cash

Table 6: Essential use case for getting cash from an ATM

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).

Essential use cases in the Rational Unified Process

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

Hal 114 dari 117

with usability requirements to create use-case storyboards, as explained in Guidelines:
Use-Case Storyboard.

• 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.

Hal 115 dari 117

Concepts: Use-Case View
To provide a basis for planning the technical contents of iterations, an architectural view
called the use-case view is used in the Requirements workflow. There is only one use-
case view of the system, which illustrates the use cases and scenarios that encompass
architecturally significant behavior, classes, or technical risks. The use-case view is
refined and considered initially in each iteration.

The use-case view shows an architecturally significant subset of the use-case model, a
subset of the use cases and actors.

The analysis, design, and implementation activities subsequent to requirements are

centered on the notion of an architecture. The production and validation of that
architecture is the main focus of the early iterations, especially during the Elaboration
phase. Architecture is represented by a number of different architectural views, which in
their essence are extracts illustrating the "architecturally significant" elements of the
models.

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.

The architectural views are documented in a Software Architecture Document. You

may add different views, such as a security view, to convey other specific aspects of the
software architecture.

So, in essence, architectural views can be seen as abstractions or simplifications of the

models built, in which you make important characteristics more visible by leaving the
details aside. The architecture is an important means for increasing the quality of any
model built during system development.

Hal 116 dari 117

Copyright © 1987 - 2000 Rational Software Corporation

Hal 117 dari 117