Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
functreq

functreq

Ratings: (0)|Views: 5 |Likes:
Published by api-3715003

More info:

Published by: api-3715003 on Oct 18, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/18/2014

pdf

text

original

A
R
RCHITECTURE ESOURCES
For Enterprise Advantage
http://www.bredemeyer.com
B
C
REDEMEYER ONSULTING, Tel: (812) 335-1653
Architectur
e
Architectin
g
Arc hitec ts
Functional Requirements and Use Cases
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. 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
Bredemeyer Consulting
ruth_malan@bredemeyer.com
dana@bredemeyer.com

\u00a9 2001 BREDEMEYER CONSULTING
WHITE PAPER 8/3/01
2
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, 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.

Use Cases

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.

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
\u00a9 2001 BREDEMEYER CONSULTING
WHITE PAPER 8/3/01
3
of flow through the use case (e.g., triggered by options, error conditions, security breaches, etc.). Scenarios
may be depicted using sequence diagrams.
Structuring Use Cases

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)

Use Case Diagram
Figure 1. Example use case diagram (adapted from the UML V1.3 document)
The use case structure is graphically summarized in a use case diagram (UML, 1999, pp. 3-83 to 3-
88), which also shows which actors interact with which use cases.
Telephone Catalog
Check Status
Supply Customer
Data
Order Product
Arrange Payment
Request Catalog
<<include>>
<<include>>
<<include>>
<<extend>>
Place Order
Extension points
additional requests: after
creation of the order
Customer
Salesperson
EstablishCredit
Supervisor

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->