This behavior may be expressed as services, tasks or functions the system is required to perform. This white paper lays out important con- cepts and discusses capturing functional requirements in such a way that they can drive architectural decisions and be used to validate the architecture.
by Ruth Malan and Dana Bredemeyer
In product development, it is useful to distinguish between the baseline functionality necessary for any system to compete in that product domain, andfeatures that differentiate the system from competitors\u2019 products, and from variants in your company\u2019s own product line/family. Features may be additional func- tionality, or differ from the basic functionality along some quality attribute (such as performance or mem- ory utilization).
One strategy for quickly penetrating a market, is to produce the core, or stripped down, basic product, and adding features to variants of the product to be released shortly thereafter. This release strategy is obvi- ously 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 mar- kets 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 func- tional 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 lim- ited to object-oriented systems.
A use case defines a goal-oriented set of interactions between external actors and the system under consid- eration.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. Aprimary actor is one having a goal requiring the assistance of the system. Asecondary 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 ser- vice because of exceptional behavior, error handling, etc. The system is treated as a \u201cblack box\u201d, and the interactions with system, including system responses, are as perceived from outside the system.
Thus, use cases capturewho (actor) doesw h a t (interaction) with the system, for whatpurpose (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 accessi- bility encourages users to be actively involved in defining the requirements.
UML (1999) provides three relationships that can be used to structure use cases. These are generalization, include and extends. Aninclude relationship between two use cases means that the sequence of behavior described in the included (orsub) use case is included in the sequence of the base (including) use case. Including a use case is thus analogous to the notion of calling a subroutine (Coleman, 1998).
Theextends relationship provides a way of capturing a variant to a use case. Extensions are not true use cases but changes to steps in an existing use case. Typically extensions are used to specify the changes in steps that occur in order to accommodate an assumption that is false (Coleman, 1998). The extends rela- tionship includes the condition that must be satisfied if the extension is to take place, and references to the extension points which define the locations in the base (extended) use case where the additions are to be made.
Ageneralization relationship between use cases \u201cimplies that the child use case contains all the attributes, sequences of behavior, and extension points defined in the parent use case, and participates in all relationships of the parent use case.\u201d The child use case may define new behavior sequences, as well as add behavior into and specialize existing behavior of the parent. (UML, 1999)
Now bringing you back...
Does that email address look wrong? Try again with a different email.