Functional Requirements and Use Cases

Functional Requirements

Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform.

In product development, it is useful to distinguish between the baseline functionality necessary for any system to compete in that product domain, and features that differentiate the system from competitors’ products, and from variants in your company’s own product line/family. Features may be additional functionality, or differ from the basic functionality along some quality attribute (such as performance or memory utilization).

One strategy for quickly penetrating a market, is to produce the core, or stripped down, basic product, adding features to variants of the product to be released shortly thereafter. This release strategy is obviously also beneficial in information systems development, staging core functionality for early releases and adding features over the course of several subsequent releases.

In many industries, companies produce product lines with different cost/feature variations per product in the line, and product families that include a number of product lines targeted at somewhat different markets or usage situations. What makes these product lines part of a family, are some common elements of functionality and identity. A platform-based development approach leverages this commonality, utilizing a set of reusable assets across the family.

These strategies have important implications for software architecture. In particular, it is not just the functional requirements of the first product or release that must be supported by the architecture. The functional requirements of early (nearly concurrent) releases need to be explicitly taken into account. Later releases are accommodated through architectural qualities such as extensibility, flexibility, etc. The latter are expressed as non-functional requirements.

Use cases have quickly become a widespread practice for capturing functional requirements. This is especially true in the object-oriented community where they originated, but their applicability is not limited to object-oriented systems.

Use Cases

A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system (UML 1999, pp. 2.113- 2.123). An actor may be a class of users, roles users can play, or other systems. Cockburn (1997) distinguishes between primary and secondary actors. A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance.

A use case is initiated by a user with a particular goal in mind, and completes successfully when that goal is satisfied. It describes the sequence of interactions between actors and the system necessary to deliver the service that satisfies the goal. It also includes possible variants of this sequence, e.g., alternative sequences that may also satisfy the goal, as well as sequences that may lead to failure to complete the service because of exceptional behavior, error handling, etc. The system is treated as a "black box", and the interactions with system, including system responses, are as perceived from outside the system.

Thus, use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.

Generally, use case steps are written in an easy-to-understand structured narrative using the vocabulary of the domain. This is engaging for users who can easily follow and validate the use cases, and the accessibility encourages users to be actively involved in defining the requirements.

Scenarios

A scenario is an instance of a use case, and represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation of flow through the use case (e.g., triggered by options, error conditions, security breaches, etc.). Scenarios may be depicted using sequence diagrams.

Role of Use Cases in Architecting

See the "Functional Requirements and Use Cases" white paper by Ruth Malan and Dana Bredemeyer, for the role of use cases in the architecting process. This paper also contains an updated version of Derek Coleman's use case template (Coleman, 1998) and a full use case bibliography.

Downloads the documents related to the above topic below:

1. Functional Requirements and Use Cases : PDF File
2. Use Case Presentation : PPT file
3. Use Case Modelling : PPT File
4. Use Case modelling, Requirements Analysis and Requirements Specification : PPT File
5. SRS with Use Cases : Doc File
6. Use Case Template : Doc File
7. Use Case Example (Cafeteria Ordering System) : Doc File
8. UML Use Case Exercise : Doc File
9. Use Case Management with Rational Rose : PDF File
10. Rational Rose: Creating Use Case : PPT File
11. Creating Use Cases in Rational Rose : PDF File
12. Use Case Diagram in Rational Rose : PDF File

Video for Use Case