Use-Case Modeling for Requirements Specifications

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