Combining Software Requirements Specifications with Use-Case Modeling
By Leslee Probasco and Dean Leffingwell
Rational Software
Many software teams are discovering that mixing use-case modeling techniques for
requirements expression along with traditional methods of documenting specific
requirements within a “software requirements specification” (SRS) document provides an
efficient means to record the complete set of detailed requirements for a system or
application to be built.
The Rational Unified Process provides the following definitions:
A requirement describes a condition or capability to which a system must
conform; either derived directly from user needs, or stated in a contract, standard,
specification, or other formally imposed document.
A use case describes a sequence of actions a system performs that yields an
observable result of value to a particular actor.
In our experience, we have found that a fully specified set of use cases for a system often
does a great job of stating many of the requirements for that system. But just as often
there are also a significant number of requirements that do not fit well within this
modeling technique. Especially for non-functional requirements (e.g., specifications for
usability, reliability, performance, maintainability, supportability), it is usually best to use
the good-ol’ tried-and-true traditional method for stating requirements.
Traditionally, requirements specified in an SRS are simple declarative statements written
in a text-based natural-language style (e.g., “ When the user logs in, the system displays
the splash screen described in Figure x.”). Use cases should be viewed merely as an
alternative for specifying requirements; moreover they describe complete threads, or
scenarios, through the system which provide additional value in understanding the
intended behavior of the system. Use-case modeling is a hallmark of the Unified
Modeling Language (UML) and the Rational Unified Process (RUP) as well as being a
central feature provided by visual modeling tools, such as Rational Rose. In most
circumstances use cases should simply be applied as an added form of expression which
increases understandability, as opposed to simply replacing the specification of
requirements in the traditional fashion.
We need to be able to support the traditional requirements approach in all of our
processes, specifications and tools since it may well will be needed whether or not a
project decides to use the use-case methodology (e.g., in specifying requirements that do
not fit easily in the use-case model, especially non-functional requirements). It does not
have to be an "either-or". Neither approach is "best" in all circumstances - although it
could definitely be argued as to which approach might be "better" for a particular
application.
A common concern that we hear from development teams first trying to apply use-case
modeling is that they do not want to maintain redundant specifications of their
requirements - one expression in use-case form and another in the traditional SRS form.
They like use cases for working with their customers to specify the functional
requirements of a system in the customers’ language, however they are often more
familiar with the more traditional form of expression (and perhaps they are required by
their boss, or management or an outside agency) to produce a Software Requirements
Specification (SRS) that contains the “complete” set of detailed software requirements
for the system. A key concept of good requirements management advocates minimizing
redundancy, so this is definitely a valid concern that should be addressed.
To facilitate the combination of traditional SRS methods and use cases, we have defined
a simple construct called the “SRS Package”. This “package” pulls together the complete
set of software requirements for a system (or portion of a system) which may be
contained in a single document, multiple documents, a requirements repository
(consisting of the requirements’ text, attributes and traceability), use case specifications
and even the graphical use case model diagrams which describes relationships amongst
the use cases and actors. We’ve found this simple combination to be effective in most all
application development projects, and it’s an easy way to kickstart your teams ability to
realize the additional benefits provided by the use case technique.
The Purpose of a Software Requirements Specification
The SRS provides an organized way to collect all software requirements surrounding a
project (or perhaps at a subsystem or feature level) into one document. In these days of
automation and visual modeling, we often find ourselves with several different tools for
collecting these requirements. The complete set of requirements may indeed be found in
several different artifacts accessible by multiple tools. For example, you might find it
useful to collect some (or all) of the functional requirements of your system in use cases
and you might find it handy to use a tool appropriate to the needs of defining the use-case
model. On the other hand, you might find it appropriate to collect traditionally stated
natural-language requirements (such as non-functional requirements, design constraints,
etc.) with a word processing tool in “supplementary specifications”. And a requirements
management tool must be able to access all requirements for maintaining requirement
attributes and traceability.
Arguably, some combination of the use case and traditional specification technique
should be used in all projects. To facilitate this, we will collect the requirements for our
SRS in a UML “package” construct that may include a single document, multiple
documents, use case specifications and even the graphical use case model which
describes relationships amongst the use cases.
The “SRS package” controls the evolution of the system throughout the development and
release phases of the project. In the Rational Unified Process, the following workers use
the SRS Package:

The system analyst creates and maintains the Vision, the use-case model
overview and supplementary specifications, which serve as input to the SRS and
are the communication medium between the system analyst, the customer, and
other developers.

The use-case specifier creates and maintains the individual use cases of the usecase model and other components of the SRS package,

Designers use the SRS Package as a reference when defining responsibilities,
operations, and attributes on classes, and when adjusting classes to the
implementation environment.

Implementers refer to the SRS Package for input when implementing classes.

The project manager refers to the SRS Package for input when planning
iterations.

The testers use the SRS Package to verify system compliance.
From Vision to SRS
In the Requirements workflow of the Rational Unified Process, our requirements artifact
structure starts with an artifact called the Vision which describes the user's or customer's
view of the product to be developed, specified at the level of key user needs and features
of the system.
The SRS Package is obviously related to the Vision document. Indeed, the Vision
document serves as the input to the SRS. But the two artifacts serve different needs and
are typically written by different authors. At this stage in the project, the focus of the
project moves from the broad statement of user needs, goals and objectives, target
markets and features of the system to the details of how these features are going to be
implemented in the solution.
What we need now is a collection, or package, of artifacts that describes the complete
external behavior of the system - i.e., an artifact that says specifically: “Here is what the
system has to do to deliver those features.” That is what we refer to as the SRS Package.
A Living Artifact
The SRS Package is an active, living artifact. Indeed it plays a number of crucial roles as
the developers embark upon their implementation effort: It serves as a basis of
communication between all parties - i.e., between the developers themselves, and
between the developers and the external groups (users and other stakeholders) with whom
they must communicate. Formally or informally, it represents a contractual agreement
between the various parties - if it’s not in the SRS Package, the developers shouldn’t be
working on it. And if it is in the SRS Package, then they are accountable to deliver that
functionality.
The Project Manager’s Reference Standard
The SRS serves as the project manager’s reference standard. The project manager is
unlikely to have the time, energy, or skills to read the code being generated by the
developers and compare that directly to the Vision document. He or she must use the SRS
as the standard reference for discussions with the project team.
As noted earlier, it serves as input to the design and implementation groups. Depending
on how the project is organized, the implementers may have been involved in the earlier
problem-solving and feature-definition activities that ultimately produced the Vision
document. But it’s the SRS they need to focus on for deciding what their code must do. It
serves as input to the software testing and QA groups. These groups should also have
been involved in some of the earlier discussions, and it’s obviously helpful for them to
have a good understanding of the “vision” laid out in the Vision documents. But their
charter is to create test cases and QA procedures to ensure that the developed system does
indeed fulfill the requirements laid out in the SRS. The SRS also serves as the standard
reference for their planning and testing activities.
Sample Templates for an SRS Package
In support of these concepts, two separate SRS document templates have been developed
and are enclosed:

An SRS template for use with projects using use-case modeling, and

An SRS template for projects using only traditional requirements specification
techniques.
See the Rational Unified Process (v5.5) for more information on these and other artifacts,
along with best practices for developing software with UML.
Summary
In this brief article, we’ve defined a simple construct, the SRS Package, which provides a
means of combining the traditional requirements specification technique with the use
case method. We’ve found this simple combination to be effective in most all application
development projects, and it’s an easy way to kickstart your teams ability to realize the
additional benefits provided by the use case technique.
About the Authors
Dean Leffingwell is a Vice President at Rational Software Corporation where he leads
the company’s efforts in methodology, software development process, and customer
education and training. He is lead author of the upcoming book “Managing Software
Requirements”, which will be published by Addison Wesley later this year.
Leslee Probasco is a senior process engineer involved in development of the Rational
Unified Process. She has twenty years of software engineering experience in the areas of
military and aerospace systems, telecommunications, oil and gas, and electrical
engineering, working as both a manager and a developer on large software projects.
References
1. Booch, Grady et al., UML User’s Guide, Addison-Wesley-Longman, Reading, MA
(1999)
2. IEEE Std 830-1993, Recommended Practice for Software Requirements
Specifications, Software Engineering Standards Committee of the IEEE Computer
Society, New York (1993)
3. Jacobson, Ivar, et al., Object-oriented Software Engineering—A Use Case Driven
Approach, Addison-Wesley (1992).
4. Jacobson, Ivar, Grady Booch, Jim Rumbaugh, The Unified Software Development
Process, Addison-Wesley-Longman (1999)
5. Kruchten, Philippe, The Rational Unified Process—An Introduction, AddisonWesley-Longman, Reading, MA (1999)
6. Rational Unified Process, version 5.5, Rational Software Corporation, Cupertino, CA
(1999)