Regular Paper

Use Cases for Systems

Engineering—An Approach
and Empirical Evaluation*
Magnus Eriksson1, 2, †, Kjell Borg,1 and Jürgen Börstler2

1
BAE Systems Hägglunds AB, SE-891 82 Örnsköldsvik, Sweden
2
Umeå University, SE-901 87 Umeå, Sweden
USE CASES FOR SYSTEMS ENGINEERING

Received 10 April 2007; Revised 1 July 2007; Accepted 21 August 2007, after one or more revisions
Published online 13 December 2007 in Wiley InterScience (www.interscience.wiley.com).
DOI 10.1002/sys.20087

ABSTRACT
This paper describes a use case driven approach for functional analysis/allocation and
requirements flowdown. The approach utilizes use cases and use case realizations for func-
tional architecture modeling, which in turn form the basis for design synthesis and require-
ments flowdown. We refer to this approach as the FAR (Functional Architecture by use case
Realizations) approach. The FAR approach is currently applied in several large-scale defense
projects within BAE Systems Hägglunds AB. This paper also presents an empirical study where
FAR is applied and evaluated in two large-scale defense projects. Our results indicate that
the FAR approach performs better than the previously used document based approach in the
organization. © 2007 Wiley Periodicals, Inc. Syst Eng 11: 39–60, 2008

Key words: use case; use case realization; functional architecture; requirements flowdown;
pilot projects

1. INTRODUCTION
* This article is an extended and revised version of the papers by the Organizations developing software-intense defense
authors [Eriksson, Borg, and Börstler, 2006; Eriksson, Börstler, and systems, for example vehicles, are today faced with a
Borg, 2006] which were presented at the 2006 INCOSE Symposium.
†
Author to whom all correspondence should be addressed (e-mail:
number of challenges. These challenges are related to
magnus.eriksson@bae syste ms.se ; [email protected]; the characteristics of both the market place and the
[email protected]; [email protected]). system domain.
.

Systems Engineering, Vol. 11, No. 1, 2008

© 2007 Wiley Periodicals, Inc.

39
40 ERIKSSON, BORG, AND BÖRSTLER

• Complexity. Systems are growing ever more and Sykes, 1992], it does not resolve the second short-
complex, consisting of tightly integrated me- coming. Most object-oriented approaches are based on
chanical, electrical/electronic and software com- the UML [OMG, 2007a], which is not well known to
ponents. nonsoftware stakeholders. Adopting an UML based
• Long life-cycles. Systems have very long life approach would certainly ease communication between
spans, typically 30 years or longer. the systems- and the software engineering team(s), but
• Few units. Often, relatively few systems are de- hardly with other stakeholders such as customers, end
veloped and manufactured, ranging from only a users, marketing, and mechanical and electrical engi-
few to several hundred units. neering. However, use case modeling [Adolph et al.,
• High degree of customization. Systems are often 2003], which is a technique traditionally used in object-
part of a product line of related systems; however, oriented development, produces outputs that can be
they are always customized for specific customer easily communicated to both nontechnical stakeholders
needs. and other engineering disciplines [Kruchten, 2000].
Use case modeling is a functional decomposition tech-
For an organization to be competitive in a market nique that provides a semi-formal framework for struc-
like this it is important to achieve efficient development turing the system functionality into user goals [Adolph
and maintenance. This makes it necessary to avoid et al., 2003]. These user goals are further specified by a
multiple implementations of the same functionality and number of scenarios describing the interaction between
to achieve high levels of reuse. It is furthermore very a system and its actors (users and environment) with the
important that the different engineering disciplines in- purpose of achieving these goals.
volved in development can communicate effectively. Several proposals on how to utilize use cases as part
Development processes should be tightly integrated to of the systems engineering process have been described
ensure that all disciplines are working towards a com- in the literature (see section 2). Our main contribution
mon goal. in this area, which is presented in this paper, is twofold.
Systems engineering is a key function in any organi- First, we have developed a method for functional analy-
zation trying to address such complexity. However, sis/allocation [INCOSE, 2004] and requirements flow-
traditional systems engineering methods and tools suf- down [Dorfman and Thayer, 1997] that utilizes use
fer from two major shortcomings regarding these chal- cases and use case realizations [Kruchten, 2000]. This
lenges: approach, called FAR (Functional Architecture by use
case Realizations), provides new insights on how to
1. Traditional systems engineering typically utilizes derive subsystem requirements from goal-oriented use
classical structured analysis techniques [Lykins, case models. Second, we provide an industrial evalu-
Friedenthal, and Meilich, 2000]. These tradi-
ation of this approach in the context of software-inten-
tional techniques provide little support for
sive defense systems.
achieving high levels of reuse. The reason for this
The remainder of the paper is structured as follows:
is that the top down process of traditional func-
Section 2 presents related work regarding use case
tional decomposition does not have any built in
modeling in the context of systems engineering. Section
mechanisms for developing requirements that
3 introduces the activities and artifacts of the FAR
maps well to existing reusable components
approach. Sections 4 and 5 describe how to manage
[Rickman, 2000].
scope creep and how to adjust the level of specification
2. Traditional systems engineering utilizes modeling
detail using the FAR approach. Section 6 presents an
techniques, such as IDEFØ diagrams [NIST,
industrial study where FAR was applied and evaluated
1993], that are not commonly known to nontech-
in the software-intensive defense system domain, and
nical stakeholders or even other engineering dis-
section 7 presents the results of the evaluation. Section
ciplines. This is a problem, since systems
engineering is the means by which stakeholder 8 summarizes the paper and presents some future work
needs are translated and communicated to other in the area.
engineering disciplines [INCOSE, 2004].
2. RELATED WORK
An interesting approach to address the first short-
coming could be to adopt an object-oriented approach. Lykins, Friedenthal, and Meilich [2000] suggested us-
Although object-orientation provides stronger means ing UML in an Object Oriented Systems Engineering
than structured analysis for achieving high levels of Method (OOSEM). In OOSEM use cases are used to
reuse [Jacobson, Griss, and Jonsson, 1997; McGregor capture key functionality in the system to be developed,

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 41

much as in traditional object oriented software engi- nario-steps by subsystem, relevant sequencing informa-
neering. OOSEM also provides some guidance on how tion and possible preconditions are lost; this could yield
to tailor use case modeling to systems engineering. invalid results (see section 3.10).
Based on experiences from Daimler-Chrysler, Alex- Daniels, Botta, and Bohill [2004] suggest that sys-
ander and Zink [2002] argue that use case modeling has tem-level functional requirements can be derived from
real and substantial benefits in systems engineering. use case scenarios by extracting the described behavior
The authors introduce the concept of black-box and and reformulating it as shall statements. According to
white-box use cases based on terminology from testing. the authors, this would make requirements specifica-
Black-box use cases only consider the system from the tions more robust since the benefits of easy to under-
outside (i.e., as a “black box”), whereas white-box use stand use cases are combined with the precision of shall
cases consider the role of each subsystem inside this statements.
“black box” when realizing a use case. Furthermore, the The OMG SysML [OMG, 2007b] is a graphical
authors describe how use case modeling can be applied modeling language that supports specification, analy-
on different system levels and how white-box use cases sis, design, verification, and validation of complex sys-
on one system level relate to black-box use cases on the tems. OMG SysML is a profile of UML 2.0 [OMG,
next level. 2007a] that also incorporates UML’s use case diagrams.
In the RUP-SE initiative from IBM-Rational [Ra- UML/SysML is methodology and tool independent and
tional Software, 2002] a tabular text-based notation for does not provide any practical guidance on how to
black-box and white-box use case scenarios are intro- utilize use cases as part of the systems engineering
duced. These notations are used in context of the so- process. Several attempts to provide such guidance
called use case flowdown activity which aims to derive have been made (see, for example, the I-Logix initiative
functional requirements for subsystems. In RUP-SE, [Hoffman, 2005]). However, these approaches do not
subsystem-level black-box use cases are equal to sys- address requirements flowdown based on use cases.
tem-level white-box use case scenario steps. This
means that surveys of all use cases for each subsystem
can be generated by sorting system-level white-box use 3. THE FAR APPROACH
case scenarios according to participating subsystems.
In theory this is a simple and appealing approach for The purpose of the functional analysis and allocation
deriving use cases for subsystems. However, our expe- activity in System Engineering is to clearly describe the
rience from experimenting with this approach has re- system functionality, divide functions into subfunctions
vealed several issues. Our approach to use case and to allocate them appropriately to subsystems [IN-
modeling is very goal-oriented (see section 3.4), how- COSE, 2004]. As shown in Figure 1, functional analysis
ever using the RUP-SE strategy typically does not result and allocation is based on input provided by require-
in “good” goal-oriented subsystem use cases. Instead, ments analysis, which also receives feedback via the
such subsystem use cases often represent a subsystem requirements loop from functional analysis and alloca-
task. That is, only part of a complete-goal that the users tion. Furthermore, functional analysis and allocation
of the subsystem want to achieve by interacting with the also provides input to design synthesis and receives
subsystem. Furthermore, when sorting white-box sce- feedback through the design loop.

Figure 1. Overview of the systems engineering process [DoD, 2001].

Systems Engineering DOI 10.1002/sys

42 ERIKSSON, BORG, AND BÖRSTLER

Being a use case driven method, FAR closes the subsystems collaborate to solve a specific use case
requirements loop by producing a use case model as [Kruchten, 2000].
output of the functional analysis and allocation func- After specifying a system’s functional- and physical
tion. As shown in Figure 2, this use case model consists architecture and allocating system level requirements to
of a survey of all use cases included in the system and subsystems, the next step of the systems engineering
detailed specifications of each use case within that process is commonly referred to as Requirements flow-
survey. Furthermore, in addition to a traditional use case down. The flowdown activity consists of deriving re-
model, the FAR approach also produces a Functional quirements specifications for each element of the
Breakdown Structure (FBS). The purpose of this FBS systems architecture based on the allocated system re-
is to provide an overview of the system functionality,
quirements [Dorfman and Thayer, 1997]. As shown in
which we feel, is missing in traditional use case models.
Figure 5, the FAD and the RAS are input to the require-
The produced use case model also serves as input to the
ments flowdown activity, which produce requirements
Design Synthesis, as shown in Figure 2, and is thereby
specifications for different subsystems as output.
also part of the design loop (see Fig. 1).
The feedback loop from Design Synthesis to Func-
tional Analysis and Allocation includes a description of 3.1. The System Context Diagram
the physical architecture of the system. Details regard- One important artifact, according to our experience, to
ing development of this Physical Architecture Descrip-
develop and agree upon before starting functional
tion (PAD) is not within the scope of this paper and will
analysis and allocation is a system context diagram. The
not be further discussed; however, for some useful
system context diagram clearly visualizes the system-
insights in this area, see, for example, Bass, Clements,
of-interest [ISO, 2002], its external interfaces, and its
and Kazman [1998], Bosch [2000], and Hause and
Thom [2004]. As shown in Figure 2, the physical archi- users. It defines the set of allowed entities for describing
tecture enters the functional analysis and allocation the black-box functional view of the system. This helps
function as a control. This control triggers allocations analysts maintain focus on functions within the scope
which in turn will result in what we refer to as the of the system. As shown in Figure 3, our system context
Functional Architecture Description (FAD) and a Re- diagrams contain less information than, for example,
quirements Allocation Sheet (RAS). A FAD is a collec- the “elaborated system context diagram” used in
tion of all use case realizations for a system, where a OOSEM [Lykins, Friedenthal, and Meilich, 2000] or an
use case realization is a description of how different IDEFØ context diagram [NIST, 1993]. By omitting

Figure 2. An IDEFØ context diagram for the FAR approach.

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 43

Figure 3. An example FAR system context diagram for an ATM system.

details regarding provided services and input/output tions. The first four of these subfunctions regard func-
data, we improve the readability of the diagram. tional analysis by development of a use case model. The
A use case actor is some type of entity, external to last two subfunctions regard allocation of functions and
the system-of-interest, which can interact with the sys- quality attributes to subsystems. In the following sub-
tem by exchanging information [OMG, 2007a]. A use sections, we will discuss these different subfunctions
case actor can either be a human user or an external and the different modeling artifacts they result in.
system. A use case actor can have “association” rela-
tionships to use cases, and “specialization” relation- 3.3. The “Develop FBS” Function
ships to other actors. An association relationship to a
The first step of the functional analysis is to develop a
use case means that the actor either initiates the use case
preliminary FBS based on the output from the require-
or takes part in performing the behavior defined by the
ments analysis activity. As shown in Figure 5, this FBS
use case. If an actor can initiate a specific use case, it is
should include all major function groups and services
a primary actor of that use case, else a secondary actor. provided by the system-of-interest.
In FAR, “specialization” relationships between actors
are shown as closed-head arrows between actors in the
3.4. The “Identify Use Cases” Function
system context diagram (see Technician/Teller relation-
ship to Bank Personnel in Figure 3). A specialization Our way of working with use cases has to a large extent
means that the more specialized actor inherits all asso- been inspired by the work on Patterns for Effective Use
ciation relationships from the more general actor. It can Cases by Adolph et al. [2003], in particular their goal-
communicate with all use cases as the more general oriented approach to use case modeling. A use case
actor, but it can also have association relationships to must either be a complete goal of the primary actors of
further use cases. In the FAR approach, this relation is that use case or a sub-goal derived from another use case
utilized for creating groups of users that can initiate a (see Fig. 6). A complete-goal use case is achieved
common set of use cases. We have chosen to include through interaction among use case actors and a system;
these relationships between actors in our system context this is in contrast to traditional functions which are more
diagram so that it may provide a full overview of all system-task oriented. Complete-goal use cases shall be
entities that can interact with the system-of-interest. derived from and be traceable to system requirements.
Included subgoal use cases are typically identified by
3.2. The “Perform Functional Analysis and finding common behavior in several complete-goal use
Allocation” Function cases that can be factored out and referenced, and
thereby only be specified once in the model. Use cases
As shown in Figure 4, the Perform functional analysis are named as verb-phrase-goals and depicted in UML
and allocation function is decomposed into six subfunc- use case diagrams [OMG, 2007a] as shown in Figure 6.

Systems Engineering DOI 10.1002/sys

44 ERIKSSON, BORG, AND BÖRSTLER

Figure 4. The “Perform Functional Analysis and Allocation” function in IDEFØ.

Figure 5. Example FBS for an ATM system.

Figure 6. A use case decomposition example.

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 45

A difference between the FAR approach and tradi- • Alternative Scenarios,” which describe alterna-
tional use case modeling is that we do not use UML use tive ways of achieving the goal stated in the use
case diagrams to provide an overview over system case name
functionality and system scope; we use a FBS for this • Exceptional Scenarios,” which describe how dif-
purpose. We utilize use case diagrams only to visualize ferent failures are detected and handled by the
relations between individual use cases and to provide system.
an overview of the primary and secondary actors of each
use case. We provide this actor overview by using Each of these scenarios should be named in a way
directed associations for primary actors and undirected that clearly describes what is unique about it. The only
associations for secondary actors of each use case (see exception from this naming rule is the main success
Fig. 6). These individual use case diagrams are then scenario, which is not named if the normal procedure is
linked to their corresponding elements in the FBS. For obvious from the scenario context or use case name.
example, the use case diagram in Figure 6 would be
linked to the “Cash Withdrawal” element in the FBS in 3.6. The “Specify Use Case Scenarios”
Figure 5. Furthermore, there would also be another use Function
case diagram describing the details regarding the sub-
We describe use case scenarios in a tabular natural
goal use case “Authenticate Customer” which would be
language notation. This notation is based on the RUP-
linked to the “Security” element of the FBS, as indi-
SE black-box flow of events [Rational Software, 2003],
cated by the parenthesis under the use case name in
which we consider to have three major advantages
Figure 6.
compared to traditional textual descriptions:
Since FAR provides an overview of the model using
a FBS rather than using a use case diagram, we usually
1. The notation is slightly more formalized and
do not factor out scenarios from use cases using the
thereby easier to manage using tools.
UML “extend” relation, unless it is needed for struc-
2. The notation has separate fields for actor actions
tural reasons in the model or to improve readability.
and system responses to those actions. This sim-
This strategy helps us to reduce the number of docu-
ple fact forces analysts to always think about
ments (use case specifications) in the model.
interfaces, which is a key success factor for main-
By tagging suitable sub-trees of the FBS as use case
taining focus in the modeling of complex sys-
packages [Kruchten, 2000], and utilizing links between
tems.
the FBS and use case diagrams, a “Use Case Model
3. The “Blackbox Budgeted Requirements” field
Survey” for the system can be created. This survey
(rightmost column in Fig. 7) of the notation pro-
contains the following elements:
vides an intuitive way to allocate quality attrib-
utes to a use case scenario, which is not present
• A system context diagram.
in traditional notations.
• Descriptions of all use case actors.
• An overview picture of the elements of the FBS
It would also be possible to apply the FAR method-
which are tagged as use case packages. These
ology utilizing UML/SysML sequence or activity dia-
elements form the use case model hierarchy and
grams [OMG, 2007b] for describing use case scenarios
will therefore also have a corresponding heading
and use case realizations. However, at this time, we
in the survey outline.
consider our natural language notation to be easier to
• UML use case diagrams for all use case packages.
understand for a more diverse set of system-stakehold-
• Brief descriptions of all use cases.
ers.
As illustrated in Figure 7, we describe alternative
3.5. The “Identify Use Case Scenarios”
and exceptional scenarios as so-called scenario frag-
Function
ments [Adolph et al., 2003]. These scenario fragments
Each use case is described by one or more scenarios. are specified as deltas to the main success scenario. The
Like Adolph et al. [2003], we distinguish between the first step identifier of the fragment determines the posi-
following three types of scenarios: tion where the fragment should be inserted into the main
success scenario. A fragment can either return to the
• A “Main Success Scenario,” which describes the main success scenario, as “Incorrect Unique_ID” in
“normal” way of achieving the goal stated in the Figure 7, or terminate as “Incorrect Unique_ID, Gen-
use case name eral_ID captured” in Figure 7.

Systems Engineering DOI 10.1002/sys

46 ERIKSSON, BORG, AND BÖRSTLER

Figure 7. Example black-box scenario descriptions.

Besides the actual tabular scenarios, our use case factored out as a subgoal use case and referenced
specifications also include introductory information by the source use cases using the UML “include”
such as context information regarding the use case goal relation [OMG, 2007a]. We avoid using the “spe-
and possible pre-conditions and post-conditions. If cialization” relation to reuse use case behavior,
needed, it is also possible to add this type of information since we consider it unclear on how it maps to
to individual scenarios (see “Incorrect Unique_ID, scenarios.
General_ID captured” in Fig. 7). • Scenarios should not have complex control struc-
Even though we have chosen to exclude feedback tures such as nested loops or if-statements. If such
loops to improve the readability of Figure 4, develop- are needed, a use case should rather be divided
ment of these types of use case models is highly itera- into sub-goal use cases to maintain high readabil-
tive. Identifying use cases and linking these to the FBS, ity.
as well as identification of alternative and exceptional
use case scenarios, will typically result in the identifi- 3.7. The “Specify Use Case Realizations”
cation of new or modified elements in the FBS. Further- Function
more, describing use case scenarios often results in new
use cases being discovered and other use cases are being Development of FAR use case realizations is in essence
merged. The reasons for this type of restructuring of the the processes of allocating functions, modeled as use
use case model are usually to ensure that certain rules cases, to subsystems defined by a system’s physical
of thumb regarding use case quality are fulfilled. Exam- architecture. As shown in Figure 8, our notation for use
ples of such rules are: case realizations is based on the RUP-SE white-box
flow-of-events [Rational Software, 2003]. Each black-
• A main success scenario should have between box step of a use case scenario is decomposed into a
three and ten steps. number of so called white-box steps. These white-box
• There should not be common behavior described steps describe how different subsystems collaborate to
in several use cases. Common behavior should be solve each use case scenario black-box step. During this

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 47

Figure 8. An example use case realization.

process, each “Blackbox Budgeted Requirement” must allocating this responsibility to domain engineers, we
be decomposed into one or more “Whitebox Budgeted force them to analyze the origin of subsystem require-
Requirements.” Development of these use case realiza- ments, which will give them a better system under-
tions usually involves tradeoff analyses to evaluate dif- standing. Systems engineering is responsible for
ferent allocations, considering, for example, quality initiating this activity and to guide the process to ensure
attributes such as availability, reliability, and cost. that the resulting subsystem requirements still represent
the intent of the original system-level requirements and
3.8. The “Allocate Quality Attributes to their corresponding allocations.
Subsystems” Function
Not all system requirements are suitable for use case 3.10. The “Analyze Functional
modeling. System-wide quality attributes, like environ- Architecture” and the “Analyze
mental constraints, legislations, standards, etc., are such Requirements Allocations” Functions
examples. These requirements must be handled in par- These activities serve as controls to enable specification
allel to requirements modeled as use cases. We manage of subsystem requirements. During these activities also
these requirements in a Requirements Allocation Sheet subsystem context diagram for each of the defined
(RAS). A RAS documents which subsystems are in- subsystems are developed. However, in contrast to the
volved in fulfilling each requirement. When performing previously mentioned system context diagram, these
this activity, it is important to capture background in- diagrams visualize the internal, rather than the external,
formation and rationale(s) for allocations. As shown in interfaces of a system. This means that the use case
Figure 9, we also utilize the RAS to maintain traceabil- actors of a subsystem context diagram will typically not
ity between system requirements and use cases. be system users, but rather other subsystems.
Analysis of the FAD, focus on identifying interfaces
3.9. The “Perform Requirements between subsystems, and allocation of responsibilities
Flowdown” Function for sub-functions. It is important that FAD white-box
In the FAR approach, specifying subsystem require- steps are analyzed in the correct context. Without cor-
ments is the responsibility of domain engineers (see rect sequence and other background information such
Fig. 10). This is in contrast to the traditional view, where as possible preconditions, analysis may yield invalid
systems engineering is responsible for this activity. results. Analysis of a RAS consists to a large extent of
Experience has shown that passing specifications be- understanding the rationale(s) behind each allocation
tween, for example, systems- and software engineering and the effect of every allocation for a particular sub-
does not yield satisfactory results [INCOSE, 2004]. By system.

Systems Engineering DOI 10.1002/sys

48 ERIKSSON, BORG, AND BÖRSTLER

Figure 9. An example of a FAR Requirements Allocation Sheet (RAS).

3.11. The “Specify Subsystem white-box step. As shown in Figure 11, these subsystem
Requirements” Function requirements are typically of input, output, or func-
tional character. Analysis of the RAS will result in one
The purpose of this activity is to produce subsystem
or more subsystem requirements being specified for
requirements that later will form the basis for detailed
each “X” in the “Subsystems” part of the matrix. These
design. The analysis of the FAD should result in one or
resulting subsystem requirements are usually quality
more subsystem requirements being specified for each

Figure 10. The “Perform Requirement Flowdown” function in IDEFØ.

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 49

Figure 11. Example of subsystem requirements derived from use case realizations.

attributes constraining the development of the subsys- In the FAR approach, “gold plating” and “prepared
tems. for” requirements are modeled by means of so-called
change cases. Change cases, first proposed by Ecklund,
3.12. The “Review Subsystem Delcambre, and Freilung [1996], are basically use cases
Requirements” Function that specify anticipated changes to a system. Each
change case has “impact links” to all use cases that are
Although the responsibility of specifying subsystem affected, when the change case is realized. These impact
requirements is allocated to domain engineers, systems links provide a good basis for change impact analysis.
engineering must still verify that the derived subsystem In FAR, change cases are used to mark proposed, but
requirements represent the original intent of the system- not yet accepted functionality. Whenever there is a
level requirements. The resulting subsystem require- discussion if a function is gold plating or not, the
ments must therefore be reviewed by systems function should be marked as a change case. However,
engineering before they can be baselined. once accepted for implementation within the system,
these change cases are transformed to use cases.
As shown in Figure 12, we utilize the UML stereo-
4. MANAGING SCOPE CREEP type mechanism [OMG, 2007a] to model change cases
in UML use case diagrams. Impact links are modeled
It is often hard to draw a sharp line between fulfilling
as “dependency” relations stereotyped with “impacts”
customer expectations and “gold plating” a system.
and change cases are modeled as use cases stereotyped
Also preparing a system’s architecture for anticipated with “change case”. Besides from impact links, change
changes may result in many additional internal require- cases can also have “include” and “extend” relations to
ments. These “prepared for” requirements are often other use cases as defined for use cases in the UML
unclear and can have a significant impact on the system standard [OMG, 2007a]. For example, if a change case
architecture. Therefore, it is very important to keep adds one or more scenarios to an existing use case it is
track of these types of requirements. modeled by creating a UML “extend”-relation from the
change case to the existing use case.

5. MANAGING THE LEVEL OF DETAIL

There is no straight answer to the question: “How much

systems engineering is enough?” A decision to baseline
the systems engineering output and ramp-up the de-
tailed design effort is a matter of risk management. A
better question would be: “On what level of specifica-
tion detail can an organization ramp-up the detailed
design effort with acceptable risks?” In FAR, there are
basically two ways to manage this level of specification
Figure 12. An example change case. detail:

Systems Engineering DOI 10.1002/sys

50 ERIKSSON, BORG, AND BÖRSTLER

1. Reduce or increase the number of subsystems in described in the Functional Description to physical
the design. More subsystems mean more white- interfaces and physical components. The Function
box steps and more detail in the FAD and vice Specification is also document-based. Traceability be-
versa. The two extremes on this scale would be tween the two documents is maintained by keeping a
an architecture comprising a single subsystem common heading outline. A problem with this approach
(the system itself), or an architecture where each was that two entire documents had to be read, front to
configuration unit is a separate subsystem. In the back, to understand a single function. If only parts of
first case, FAD white-box steps would actually the documents are read it may leave some parts of the
be equal to their respective black-box steps. Ba- function open for interpretation. Another problem was
sically no design decisions are made. The second that these descriptions where too tightly coupled to the
case would lead to a totally specified system, physical architecture. Reusing parts of these documents
where there is no room for consecutive detailed in other projects would require considerable restructur-
design. Our experience has shown that a number ing to make them fit the architecture of the target
of subsystems leading to typically two to four project. In practice, this made reuse almost pointless.
white-box steps per black-box step result in The study hypothesis to be tested and its null hy-
specifications with high readability. pothesis were:
2. Apply FAR recursively. Complex/high risk sub-
systems may be further analyzed and described H1: The FAR approach performs better than man-
by moving to the next lower level of abstraction aging the functional view according to the com-
and treating them as the system-of-interest. This pany process baseline in the current industrial
enables us to apply the FAR methodology recur- setting.
sively, since the inputs to and outputs of the FAR H0: The FAR approach performs equal to, or
process are basically the same (requirements worse than, managing the functional view ac-
statements). cording to the company process baseline in the
current industrial setting.

6. EMPIRICAL EVALUATION To measure performance of FAR the research team

defined a number of response variables (also referred to
To evaluate the feasibility of FAR, an empirical study
as dependent variables). These response variables were
was planned and executed in the approach’s target
derived from the issues and needs discussed in section
domain, long-lived software-intensive defense systems.
1, and the approach’s general feasibility. The resulting
The study was preformed with the Swedish defense
response variables were:
contractor BAE Systems Hägglunds AB, a leading
manufacturer of combat vehicles, all terrain vehicles,
• Multi-disciplinary communication. Are the nota-
and a supplier of various turret systems. The evaluation
tions used easy to understand and use for a divers
was designed as a blocked subject-project study [Sea-
set of system stakeholders?
man, 1999], where data were collected from two differ-
• Expressiveness. Are notations expressive enough
ent pilot projects and compared to subjects’ experiences
to adequately describe the modeled domain?
from the company process baseline for managing the
• Usefulness of artifacts. Does all prescribed devel-
system functional view.
opment artifacts provide value?
The company process baseline prescribes develop-
• Basis for detailed design. How useful is the re-
ment of two artifacts, the “Functional Description” and
sulting documentation for domain engineers?
the “Functional Specification.” The Functional De-
• Reuse infrastructure. Does the approach provide
scription is a traditional document, structured accord-
an improved reuse infrastructure?
ing to the system physical architecture, where all logical
• Finding common subfunctions. Dose the ap-
subsystems have a corresponding heading in the docu-
proach aid in finding common subfunctions to
ment outline. Each of these subsystem’s functions is
avoid multiple implementations?
described with logical interfaces, possible states, con-
ditions, and exceptions. There are also references to
6.1. Study Context
functions allocated to other subsystems in each section.
The purpose of these references is to enable tracing of Adequate tool support is an important factor when
functions from the originating subsystem throughout managing models of complex systems. We have chosen
the rest of the system. The Functional Specification to utilize the commercial requirements management
allocates the logical interfaces and logical subsystems tool Telelogic DOORS to manage our FAR models. To

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 51

make work more efficient, we have developed a number founding factors that could influence the evaluation.
of tool extensions using DOORS’ integrated scripting The information was later taken into account during
language DXL [Telelogic, 2004]. These extensions are data analysis. However, questionnaires were designed
a subset of The PLUSS Toolkit, which is described in to have both specific and open-ended questions to also
detail in Eriksson et al. [2005]. elicit unexpected types of information.
The two pilot projects studied during the evaluation A total number of 11 subjects, representing systems
regarded development of a turret system and a vehicle engineering, electrical engineering, and software engi-
system. The systems engineering team of the first of neering, were interviewed during the study. The pur-
these projects utilized the provided tool support from pose of these interviews was to gather their views on
the start. The second project team, on the other hand, the usefulness of the resulting models, and on possible
first started using only word processors and moved to pros and cons, problems, and risks with FAR. Inter-
the provided tool environment only after approximately views began with a short introduction to the research
50% of the use case descriptions were already finished. being performed. After the introduction, the FAR proc-
At the time of the study, the first of these projects was ess descriptions and the ATM artifact examples pre-
in the process of finalizing the systems engineering sented in this paper were shown and discussed with
output, and the second project had already ramped up each interviewee. There were two reasons why this
the detailed design and development effort. relatively trivial domain was chosen, rather than the real
full-size models of each project. The first reason was to
6.2. Data Collection prevent subjects from losing focus on the interview
questions and instead start focusing on some project
Data were collected in four different ways: document specific issue. The second reason was the ability to
examination, participant observation, questionnaires, provide all subjects in the study with exactly the same
and interviews [Lethbridge, Sim, and Singer, 2005]. introduction to the interview situation. Interviews then
The majority of the collected data was of qualitative proceeded in a semistructured manner, to elicit as much
type. Qualitative data are richer in information content information as possible about opinions and impressions
than quantitative data [Seaman, 1999]. It was therefore regarding FAR.
considered a better choice since data from only two
pilot projects would result in too few data points for a 6.3. Data Analysis
meaningful statistical analysis.
During document examination the modeling arti- The different types of data were first analyzed individu-
facts were inspected to identify possible common mod- ally to find patterns and trends in the responses. The
eling errors and misunderstanding with FAR. We also data were then grouped in two stages and analyzed
examined inspection records for these artifacts to iden- again:
tify possible common errors that were captured during
inspections. Furthermore, a number of meeting minutes • Per development project, to capture views related
and product documents from two historical projects that to possible differences between the projects in
developed similar products to the pilot projects were regard to how the method was applied.
reviewed. A better understanding of both the organiza- • Per engineering discipline, to capture differences
tion process baseline and the systems being developed between the views of software, electrical, and
could thereby be gained. systems engineering staff.
For participant observation the research team as-
sumed a mentoring role for the systems engineers ap- Findings were documented in the form of bullet list
plying the FAR approach. This mentoring activity field memos [Seaman, 1999]. Based on these findings,
consisted of answering questions during a number of conclusions were finally drawn about the case study
modeling sessions where we passively participated, and hypothesis.
also via phone and e-mail. This enabled us to get
first-hand information regarding possible problems
6.4. Threats to Validity
with FAR.
All systems engineers in the study, in total six per- To minimize threats to the study’s construct validity,
sons, also filled out questionnaires. These question- data were collected using several different methods that
naires collected data regarding their experience also allowed unexpected types of information to be
applying the approach and their views on the tools and elicited. Furthermore, the study hypothesis and its null
notations used. The main purpose of these question- hypothesis were stated as clearly and as early as possi-
naires was to elicit information about possible con- ble in the case study design to aid in identifying correct

Systems Engineering DOI 10.1002/sys

52 ERIKSSON, BORG, AND BÖRSTLER

and relevant measures [Kitchenham, Pickard, and were not considered. We discuss this issue further in the
Pfeeger, 1995]. future work section of this paper.
To minimize threats to the study’s internal validity,
pilot projects were staffed using the organizations nor-
mal staff-allocation procedures. The study also cap- 7. SUMMARY OF STUDY RESULTS
tured information regarding each subject’s level of
The following sections summarize the results of the
experience from the company process baseline, and the
study. Sections 7.1–7.4 present the results gained from
information was taken into account during data analysis
document examination, participant observations, ques-
[Kitchenham, Pickard, and Pfeeger, 1995]. Further-
tionnaires and interviews, respectively. In section 7.5
more, subjects were chosen in collaboration with the
organization’s management to ensure that they properly we relate results to our initial case study hypothesis and
represented their group of stakeholders. All chosen draw conclusions. Besides results relating directly to
subjects agreed to participating in the study. To avoid the case study hypothesis, we have chosen to also
the Hawthorne effect [Mayo, 1933], attitudes towards present more general results that are likely to be of
the company process baseline were collected from sub- interest to practitioners.
jects and taken into account during data analysis. It was
also pointed out to subjects that no “correct” answers 7.1. Document Examination
existed, and that it was important that their answers Document examination indicated that the teams had
correctly reflected their views. One confounding factor problems identifying “good” goal-oriented use cases. It
that may have affected the internal validity of the study
was often possible to sense the structure of the formerly
is the close involvement of the research team with the
used Function Description in the resulting use case
systems engineering teams during participant observa-
models. This meant that use cases often ended up being
tion. However, we do judge this risk to be minor and
subsystem task oriented instead of being end-user goal
not a serious threat study’s validity for the following
oriented. This in turn led to a very flat FBS with too
reasons:
many and too small use cases.
• The mentoring activity consisted of question- Other indicators of structural problems were the
and-answer sessions rather than actively partici- existence of use cases named “Handle…” and “Man-
pating in the modeling effort. age….” In such use cases, alternative scenarios where
• The teams performed most of the modeling with- typically used for describing different task within spe-
out researchers present. cific groups of functions, instead of describing different
• The risk was taken into account during data ways of achieving goals of primary use case actors. This
analysis; special attention was paid to finding led to problems with the goal oriented use case specifi-
inconsistencies between observations and other cation template. Examples of such problems were the
types of collected data. need of specifying different pre- and post-conditions for
each scenario and problems describing exceptional sce-
To minimize threats to the study’s external validity, narios.
the study was conducted in the target domain of long- One team also experienced problems maintaining a
lived software intensive systems, and projects were consistent abstraction level in their use case scenario
selected to be of typical size and complexity for the descriptions. This team hade chosen not to develop a
organization [Kitchenham, Pickard, and Pfeeger, FAR system context diagram which we believe this to
1995]. be a major reason for this problem.
To minimize threats to the study’s conclusion valid-
ity, results were triangulated by collecting data with 7.2. Participant Observation
four different methods from several different sources
[Seaman, 1999]. Furthermore, member checking [Sea- Also participant observation indicated that it was hard
man, 1999] was performed by allowing subjects to to identify “good” use cases. Another problem noticed
review and comment on draft versions of this paper to was that it seemed to be hard to keep use case scenarios
assure that their opinions were correctly represented. free from unnecessary user interface design constraints,
One confounding factor that affects the conclusion va- even though they should be free of such details. Often
lidity of the study is the limited types of stakeholders knowledge from earlier systems and possible proto-
that participated in the study. By only including systems types had a tendency to influence the descriptions and
engineering, software engineering, and electrical engi- thereby more or less force the same interaction methods
neering, opinions of other important stakeholder groups and sequences.

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 53

It was also noticed that teams experienced problems tion to capture in scenarios. However, applying this
defining stimuli-response in use case scenarios for practice may render scenarios that are very hard to read,
functions with little information handling, i.e., func- and alternative scenarios that are hard to understand
tions which typically end up with mechanical imple- why they were initiated. For example, consider the
mentations. Examples of such functions from our scenario in Figure 13. Depending on the information
domain are applying the turret transport lock, manual passed via the voice channel between the actors in step
laying of the weapon, etc. This problem was, however, 2, the remainder of the scenario may look very different.
resolved during the mentoring meetings when the issue So, even though this information is hidden from the
was discussed and the teams agreed that also mechani- system and therefore typically would have been ex-
cal functions have input/output information such as for cluded from the description, it can have large impact on
example requested speed, torque, etc. the remainder of the scenario. Our recommendation is
Teams also experienced problems modeling func- therefore to include such interaction between use case
tions with extensive information handling. Examples of actors if it improves the readability of scenarios. How-
such functions are reading logs, manuals, user instruc- ever, such interactions between actors should be merged
tions, etc. In Hägglunds system architectures, these with the next actor action that actually results in a
types of functions are typically allocated to a single system response. Doing so enforces one of our good
subsystem, the Vehicle Information System (VIS). practice guidelines; all actor action steps of a scenario
Modeling these functions, teams often ended up de-
should result in a system response.
scribing how functions are to be performed, instead of
Yet another problem noticed during the modeling
simply stating that they are performed. This can impose
sessions was a tendency to model end-user business
unnecessary constraints on the detailed design of VIS
processes instead of system usage. This phenomenon
and might also result in redundant information in the
was known as the “should/could-problem” within the
model, since subsystem-level details are ending up in
organization. In defense systems there are often require-
system-level specifications. Analyzing this issue, it be-
ments stating that mission critical functions, such as
came clear that this problem could affect any function
that to a large extent is allocated to a single subsystem. fire, should be available to several of the system users.
This is a severe problem since it is, without good Modeling such functions, teams tried to model how
domain knowledge, basically impossible to catch be- they believed the system should be used, instead of
fore allocation is performed. However, once allocation modeling how the system could be used, which is more
is done, it is relatively easy to identify such problems relevant from the perspective of finding subsystem re-
and restructure the model to correct them. The rule-of- quirements. Modeling should usage as normal and
thumb to use in these cases is: If several consecutive use could usage as exceptions, can also lead to new require-
case realization (white-box) steps are equivalent to their ments being invented, for example regarding different
respective use case scenario (black-box) steps, merge usage modes. However, knowledge about intended us-
these black-box steps into a single step, by describing age is important information to capture, for example as
the collected intent of all the original steps. input to the human factors team. Our recommendation
Teams also experienced problems describing func- is therefore that use case scenarios shall describe could
tions that relied on using the intercom system. Common usage. However, intended usage should be captured as
practice in use case modeling says that only interaction background information in the introductory part of a
between the system and its actors are relevant informa- use case specification.

Figure 13. An example scenario with communication between actors.

Systems Engineering DOI 10.1002/sys

54 ERIKSSON, BORG, AND BÖRSTLER

A question raised during the mentoring sessions was projects had a tendency to believe that FAR specifica-
how to handle Government Furnished Equipment tions were pure software specifications and therefore a
(GFE). Applying common practice in use case model- software engineering rather than a systems engineering
ing would result in viewing GFE as use case actors. The responsibility. We believe that these problems are re-
reason for this is that GFE is not developed by the lated to the fact that Hägglunds develops software ac-
organization and therefore external to the system-of-in- cording to a tailored version of the IBM-Rational
terest. This would however in some cases result in Unified Process [Kruchten, 2000]. This process utilizes
scenarios with much interaction between actors, and
similar modeling concepts as the FAR approach, but is
little interaction between actors and the system. Such
restricted to object-oriented software analysis and de-
scenarios are according to our experience not very
sign. However, these problems where only noted during
intuitive and provide little support for design synthesis.
Consider, for example, if the intercom system used in the early phases of the pilot projects with subjects new
the scenario in Figure 13 would be GFE and seen as a to the FAR methodology. Therefore, they were not
use case actor instead of part of the system. This would considered a real threat to the general feasibility of the
result in the scenario shown in Figure 14. Our recom- approach.
mendation is therefore to view GFE as subsystems
instead of actors. One exception from recommendation 7.3. Questionnaires
is however GFE that provides external interfaces to the
system-of-interest on the next higher system level. In Questionnaires showed that a majority of the systems
our domain this could, for example, be a Battlefield engineers considered the major artifacts of the FAR
Management System (BMS). Such GFE should instead approach either useful or very useful (see Fig. 15).
be viewed as use case actors. Such a view supports Questionnaires also showed that subjects considered
abstraction; systems engineers only analyze the internal the FAR notations to be relatively easy to understand
GFE interface, and not what is on the external side of and use.
the interface. Furthermore, questionnaires also showed that sub-
Another problem noticed was that experienced soft- jects considered the FAR tool support to have a number
ware engineers in particular could get confused by
of positive characteristics. Examples of these charac-
FAR’s “usage” of use case modeling. They assume,
teristics are strong support for traceability and the pos-
based on their experience from software development,
sibility to maintain one, well-organized and
that developing use case realizations is detailed design
and should result in identified classes. However, since version-controlled database with all the systems engi-
FAR utilizes use case realizations for the purpose of neering process outputs. From the answers, it was,
functional allocation as part of the systems engineering however, obvious that the graphical user interface of
process, the goal is not to identify classes but rather to DOORS was causing a lot of annoyance among the
identify subsystem requirements. Similar confusion subjects. Examples of problems pointed out were the
was also noticed in other parts of the organization. lack of shortcut keys, user interfaces bugs and that the
People that had not been directly involved in the pilot user interface does not follow MS Windows standards.

Figure 14. Viewing the intercom system as a use case actor.

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 55

Figure 15. Usefulness of artifacts according to questionnaires.

7.4. Interviews hard to get these specialists to document their

knowledge.
Interviews with systems engineers showed that they
• The FAR approach is more formalized than the
considered FAR to have a number of positive charac-
previous approach, which makes everything
teristics. Examples of theses positive aspects pointed
out during the interviews were: slower.
• The FAR approach is a more advanced way of
• The FAR approach is better at giving the whole managing the functional view. This means that it
picture. It provides more context information by takes more time to get everyone to understand the
answering the question: “Why is this function methodology.
important?” • Some functions are hard to describe as use cases.
• Being end-user oriented, the resulting artifacts Examples of such are functions triggered by tim-
provide better input to the ILS (Integrated Logis- ers or sensors.
tics Support) team responsible for developing • It is hard to identify good use cases and scenarios.
user instructions and manuals. Mining information from historic projects often
• It provides a good and powerful framework for results in too detailed scenarios.
analyzing functionality using end-user goals. • Maintaining a “single voice” and consistent ab-
• This goal-orientation also means that the ap- straction levels when several people where in-
proach provides better input to the human factors volved in writing use cases is problematic.
team. • Some team members have earlier experiences of
• Applying the FAR approach provides better use case modeling which differs from the FAR
means of understanding the product in contrast to approach. This leads to problems agreeing on the
only understanding the system. use case model structure.
• It has stronger support for finding unclear re- • The FAR approach is harder to perform if tele-
quirements and other issues so that they can be
commuting, as it seems to work best as team-
clarified early in the development life cycle.
work.
• Being scenario based, it provides stronger means
for early architecture evaluations.
Systems engineering also identified a number of
• Focus on traceability makes the origin of subsys-
tem requirements obvious. risks using the FAR approach compared to the previous
• Good that domain engineers are specifying sub- document based approach:
system requirements to force a deeper under-
standing of the requirements. • Using more advanced tools and methodology
• Generally easy to work with notations used. might cause some very skilled and field experi-
enced people, for example in the verification
Systems engineering also identified a number of team or the production team, to be left outside the
negative characteristics and problems applying the FAR loop.
approach: • Teams new to the methodology may develop use
case models that have an unsuitable structure due
• When developing FAR models, more access to to previous experiences from use case modeling.
specialists is required. It can sometimes also be They should therefore have access to a method-

Systems Engineering DOI 10.1002/sys

56 ERIKSSON, BORG, AND BÖRSTLER

ology mentor and have scheduled mentoring used and that the FAR approach is the right path to
meetings to force them to ask questions. follow also in future projects.
• Using a more formalized approach may cause Also electrical engineering expressed a number of
domain engineers to get too trusting when read- positive characteristics of the FAR approach during
ing specifications. This could cause them not to interviews:
notice if domain specialists forget to put some-
thing in a specifications. • The FAR approach is better at forcing people to
really understand the intent of the requirements.
Even considering these drawbacks, problems and • Goal and end-user focus provide stronger means
risks, all systems engineers in the study agreed that the to find “good” system solutions.
FAR approach is a better method than the previous. • The resulting artifacts are also good input to the
They considered the FAR approach to be an efficient ILS team writing user instructions.
way of managing the functional view, and that it is the • FAR models works very well for finding subsys-
proper approach for future projects. All systems engi- tem requirements.
neers in the study also agreed that most of the problems • It provides good support for early architecture
experienced could be related to the fact that the meth- evaluations from the perspectives of necessary
odology had been applied in pilot projects with too few interfaces, system safety considerations, etc.
good examples and instructions to follow.
Also software engineering expressed a number of Drawbacks with the FAR approach compared to the
positive characteristics of the FAR approach during previous method raised by one electrical engineer was
interviews: that the FAR approach requires access to a lot of spe-
cialists and that it might require more time to finish
• FAR models provide a good overview of the specifications. A problem mentioned by electrical engi-
functional scope of the system and it puts func- neering was that it can sometimes be hard to understand
tions in their correct context. complex scenarios in the notation used, and that a
• The FAR approach is better at bringing unclear supplementary diagram would be very useful in those
requirements up on the agenda early in the project cases. Electrical engineering identified mainly two
and could thereby make detailed design much risks with applying FAR. The first risk is that if devel-
more efficient. It furthermore provides strong opment of the FAD is not performed by multidiscipli-
support for finding software requirements, as nary teams, it might result in unrealistic specifications.
long as the quality attributes are not forgotten. The second risk, which was identified by one electrical
• The FAR approach provides better support for engineer, is that if the FAD is not mature enough at the
reuse of specifications between projects, since the start of the detailed hardware design it might not be
resulting artifacts are structured around end-user used. Due to long lead-times on hardware it is some-
goals rather than the physical architecture. This times hard to postpone the start of the detailed design.
provides a possibility for the organization to sig- Also all electrical engineers in the study agreed that the
nificantly reduce its development costs in the FAR approach is generally better than the earlier
future. method used and that FAR is the proper path to follow
in future projects.
Software engineering mainly pointed at two nega- Interviews also elicited information regarding pos-
tive characteristic of the FAR approach compared to the sible shortcoming of the notations used for describing
previous method used. The first of these was that it is use case scenarios and use case realizations. The sub-
harder to verify that everything fits together using sev- jects identified the following problems:
eral small artifacts instead of one large artifact. The
second was that it is much harder to write a good use • It is hard to describe conditions that have to be
case than to fill out sections in a traditional document fulfilled only during part of a scenario. The use
structure. This fact significantly reduces the available case template provides the possibility to specify
resources able to do the job. One individual also pointed pre-conditions for a scenario, but no intuitive way
at a “risk” with the approach. Since these artifacts are to specify for example that the dead-mans-grip
better means of communication with customers, it may has to be held down during step four to step seven.
provide customers with better opportunities to sneak in • The semantics of the notation is unclear regarding
new requirements during common reviews. Also all whether a scenario is just one way of performing
software engineers in the study agreed that the FAR the function or a required sequence of actions: for
approach is generally better than the earlier method example, a drive sequence, [accelerate → use

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 57

turning signal → turn → use horn → break], All subjects considered Use Case Specifications to
versus a fire sequence, [aim → arm → fire]. be important artifacts for the following reasons:
How to specify if the order of sequence is impor-
• They force people to really think about how the
tant or not?
system is intended to be used in the field.
• It is hard to describe state dependent behavior.
• They are good for reuse and change impact analy-
• Using scenario fragments may result in a single
sis, when developing a new system within the
alternative scenario, which should contain sev-
same product line.
eral unconnected fragments, describing several
• They are an effective way to capture the func-
deltas to the main success scenario. There is no
tional view of a system.
intuitive way to describe this situation in the
notation. However, one problem regarding use case specifica-
tions was pointed out during interviews. Use case speci-
On the question of experienced usefulness of FAR fications were sometimes considered almost ridicules
modeling artifacts, all subjects in the study considered by specialists because of their lack of implementation
the System Context Diagram to be an important artifact details.
for the following reasons: All subjects considered Use Case Realizations to be
important artifacts for the following reasons:
• The context diagram makes everything easier; it
is inefficient to work without it. • They are an effective way to perform functional
• It is important to agree on naming conventions allocation.
and scope early; the context diagram is helpful in • They lead to higher reusability of the resulting
this area. solutions.
• The context diagram improves the quality of use • They are a good tool for architecture evaluation.
cases since it specifies all entities that are allowed • They are a good source for clear subsystem re-
to appear in use case scenarios. quirements.
• They provide good input to the verification team
A majority of the systems engineers, all software when specifying test cases.
engineers, and a majority of the electrical engineers in • They provide a good basis for detailed hardware
the study considered the Functional Breakdown Struc- design.
ture to be an important artifact for the following rea-
Problems pointed out during interviews regarding de-
sons:
velopment of use case realizations was that they require
access to lots of system knowledge and that they are
• It is important to agree on the model structure more expensive to develop than use case specifications.
early. All subjects considered the resulting models to be a
• It provides a good overview of the system’s capa- good means of communication both with nontechnical
bilities. stakeholders such as customers, and between different
• It provides help to find use cases, and also to engineering disciplines. FAR models were considered
say—Stop, we found all use cases. to help the different engineering disciplines to commu-
• It provides context to the use cases in the model. nicate on a common abstraction level. However, one
• It is fun to develop. issue pointed out was that some engineers seem to want
• It helps to keep track of the progress of the more details in the specifications. Several engineers
systems engineering effort. also had practical experience discussing FAR specifica-
tion with customers. These experiences had been very
A majority of the systems engineers, half of the positive except for one issue; customers sometimes
software engineers, and a majority of the electrical have problems understanding the specifications be-
engineers in the study considered the Use Case Model cause they contain too much organization specific ter-
Survey to be an important artifact. Reasons given for minology. It was also pointed out that the specifications
this were that it provides a good overview of the use should be supplemented with a user interface prototype
cases in the model and that it helps make work more to work really well when communicating with custom-
controlled. The general comment from subjects that did ers.
not consider it to be an important artifact was that it is A majority of the systems engineers, all software
not worth the effort to develop, since all information is engineers, and a majority of the electrical engineers
basically also present in the use case specifications. considered the FAR approach to provide stronger sup-

Systems Engineering DOI 10.1002/sys

58 ERIKSSON, BORG, AND BÖRSTLER

port for finding common subfunctions and thereby prefer finite-state machines over sequence diagrams for
avoiding multiple implementations, than the previous the following reasons:
document based approach. Systems engineering also
considered the approach to be better than structured • Control logic constructs significantly reduce the
analysis in this area, because of its end-user goal focus. understandability of models for system-stake-
Software engineering considered the FAR approach to holders not familiar with UML/SysML.
provide the architect with exactly the tools needed to • The underlying semantics of interaction dia-
catch such sub-functions. Electrical engineering con- grams and our textual notations are basically the
sidered the FAR approach to be better in this area since same. Adding sequence diagrams to the model
it provides a better overview of such functions. would therefore introduce redundant informa-
All subjects in the study agreed that FAR provides tion. Finite-state machines, on the other hand, add
stronger means for achieving high levels of reuse, than a different and additional view of the problem
the previous approach. Systems engineering pointed out which we believe improves both precision and
that using this methodology improves the possibilities understandability.
to sell capabilities that can be implemented by existing
solutions rather than selling new solutions. Software Another issue noticed was the problem of identify-
engineering stated that this area is probably the strong- ing “good” goal-oriented use cases. The present study
est feature of the FAR approach. The information in the indicates that more methodological support is needed
specifications is captured in a form that is easily reus- in this area. One interesting approach to address this
able in the next project, and it thereby encourages reuse issue would be to investigate if Cognitive Task Analysis
also of the solutions, which resulted from those speci- (CTA) [Schraagen, Chipman, and Shalin, 2000] could
fications in the first place. Electrical engineering con- provide such support. CTA, which is a goal-oriented
sidered the resulting use case specifications to be almost approach used in human factors engineering, might
platform independent information that can easily be provide a good basis for goal-oriented use case model-
transferred to new projects. This fact combined with the ing. Utilizing CTA as a basis for FAR use case modeling
strong support for traceability makes the FAR approach would also have the positive side-effect of integrating
very good for reuse. the human factors team into the early systems engineer-
ing effort.
7.5. Conclusions
Triangulating the collected study data leads us to reject 8. SUMMARY AND FUTURE WORK
the study null hypothesis. The FAR approach performs
better than managing the functional view according to We have described how use case modeling can become
the company process baseline in the specified industrial an integral part of the systems engineering process
context. All subjects participating in the study consider rather than being a tool for requirements analysis. By
the FAR approach superior to the previously used ap- developing system level use case realizations, the FAR
proach. We believe that many of the problems experi- approach extends use case modeling to form the basis
enced during the study were related to the fact that FAR for functional allocation as well as requirements flow-
was applied in pilot projects. This opinion was also down.
expressed by several subjects during interviews. One important area of future work regarding the
We also conclude that all artifacts prescribed by the FAR approach is improved support for the modeling of
FAR approach provide value and are worth the effort quality attributes, such as availability and system safety
developing. However, the study has shown that the requirements. An interesting approach to support this
textual notations used in FAR are not expressive enough kind of work fitting very well within the FAR frame-
to effectively capture complex state-dependent behav- work is referred to as “Misuse Case” modeling [Sindre
ior in scenarios and realizations. We therefore recom- and Opdhal, 2005]. Sindre and Opdahl define a misuse
mended that the FAR notations be supplemented with case as the inverse of a use case; a function that the
finite-state machines to resolve ambiguities and im- system should not allow. This technique has been ap-
prove accuracy in such cases. However, to maintain plied to for example security requirements, and is likely
high readability, it is important that finite-state ma- to be applicable even to other types of quality attributes.
chines are only seen as a supplement and not a replace- From this perspective it would also be interesting to
ment for scenarios. Another possibility would be to use investigate and develop guidelines on applying Quality
UML 2 sequence diagrams with control logic and ref- Function Deployment (QFD) [Hari, Kasser, and Weiss,
erence sequences [see OMG, 2007a]. However, we 2007] together with FAR.

Systems Engineering DOI 10.1002/sys

 USE CASES FOR SYSTEMS ENGINEERING 59

The present study only included subjects from sys- cil Syst Eng (INCOSE’04), International Council on Sys-
tems engineering, software engineering, and electrical tems Engineering, 2004.
engineering. It would therefore be desirable to perform H. Hoffman, UML 2.0-based systems engineering using a
a follow-up study capturing the views of other impor- model-development approach, CrossTalk 18(11) (No-
vember 2005).
tant groups of stakeholders, such as mechanical engi-
International Council on Systems Engineering (INCOSE),
neering, the ILS team, and the verification team. From
Systems engineering handbook version 2a, INCOSE-TP-
this perspective, it would also be interesting to perform 2003-016-02, 2004.
formal experiments to compare FAR models to tradi- ISO/IEC, Systems engineering—system life cycle processes,
tional structured analysis artifacts. International Standard: ISO/IEC FDIS 15288:2002(E),
2002.
I. Jacobsson, M. Griss, and P. Jonsson, Software reuse, Ad-
REFERENCES
dison-Wesley, Boston, 1997.
S. Adolph, P. Bramble, A. Cockburn, and A. Pols, Patterns for B. Kitchenham, L. Pickard, and S. Pfleeger, Case studies for
effective use cases, Addison-Wesley, Boston, 2003. method and tool evaluation, IEEE Software 12(45) (July
I. Alexander and T. Zink, Introduction to systems engineering 1995), 52–62.
with use cases, Comput Control Eng J 13(6) (December P. Kruchten, The Rational Unified Process—an introduction,
2002), 289–297. 2nd edition, Addison-Wesley, Boston, 2000.
L. Bass, P. Clements, and R. Kazman, Software architecture T. Lethbridge, S. Sim, and J. Singer, Studying software engi-
in practice, Addison-Wesley, Boston, 1998. neers: Data collection techniques for software field stud-
J. Bosch, Design & use of software architectures: Adopting ies, Empirical Software Eng 10(1) (July 2005), 311–341.
and evolving a product-line approach, Addison-Wesley, H. Lykins, S. Friedenthal, and A. Meilich, Adapting UML for
Boston, 2000. an Object Oriented Systems Engineering Method
J. Daniels, R. Botta, and T. Bahill, The hybrid process that (OOSEM), Proc 10th Annu Int Symp International Coun-
combines traditional requirements and use cases, Syst Eng cil Syst Eng (INCOSE’00), International Council on Sys-
7(4) (2004), 303–319. tems Engineering, 2000.
Department of Defense (DoD), Systems engineering funda- E. Mayo, The human problems of an industrial civilization,
mentals, Defense Acquisition University Press, Fort MacMillan, New York, 1933.
Belvoir, VA, 2001. J. McGregor and D. Sykes, Object-oriented software devel-
M. Dorfman and R. Thayer, Software requirements engineer- opment: Engineering software for reuse, Van Nostrand
ing, IEEE Computer Society Press, Los Alamitos, CA, Reinhold, New York, 1992.
1997. National Institute of Standards and Technology (NIST), Inte-
E. Ecklund, L. Delcambre, and M. Freiling, Change cases— gration Definition for Function Modeling (IDEF0), Fed-
use cases that identify future requirements, Proc OOP- eral Information Processing Standards 183, 1993.
SLA’96, San Jose, CA, October 6–10, 1996, pp. 342–358. Object Management Group (OMG), Unified Modeling Lan-
M. Eriksson, H. Morast, J. Börstler, and K. Borg, The PLUSS guage Version 2.0, http://www.uml.org, 2007a.
toolkit—extending telelogic DOORS and IBM-Rational Object Management Group (OMG), OMG Systems Model-
Rose to support product line use case modeling, Proc 20th ing Language—OMG SysML, http://www.omg-
IEEE/ACM Int Conf Automated Software Eng, 2005, pp. sysml.org, 2007b.
300–304. Rational Software, The Rational Unified Process for systems
M. Eriksson, K. Borg, and J. Börstler, The FAR approach— engineering —Whitepaper Ver. 1.1, http://www.ra-
functional analysis/allocation and requirements flowdown tional.com/media/whitepapers/TP165.pdf, 2003.
using use case realizations, Proc 16th Annu Symp Int D. Rickman, A process for combining object oriented and
Council Syst Eng (INCOSE’06), International Council on structured analysis and design, Proc 3rd Annu Syst Eng
Systems Engineering, 2006. Supportability Conf, National Defense Industrial Associa-
M. Eriksson, J. Börstler, and K. Borg, Performing functional tion (NDIA), 2000.
analysis/allocation and requirements flowdown using use J. Schraagen, S. Chipman, and V. Shalin, Cognitive task
case realizations—an empirical evaluation, Proc 16th analysis, Lawrence Earlbaum, London, 2000
Annu Int Symp Int Council Syst Eng (INCOSE’06), In- C. Seaman, Qualitative methods in empirical studies of soft-
ternational Council on Systems Engineering, 2006. ware engineering, IEEE Trans Software Eng 25(4)
A. Hari, J. Kasser, and M. Weiss, How lessons learned from (July/August 1999), 557–572.
using QFD led to the evolution of a process for creating G. Sindre and A. Opdahl, Eliciting security requirements with
quality requirements for complex systems, Syst Eng 10(1) misuse cases, Requirements Eng 10(1) (January 2005),
(2007), 45–63. 33–44.
M. Hause and F. Thom, Creating flexible architectures for Telelogic AB, DXL reference manual, DOORS 7.1, Manual
systems engineering, Proc 14th Annu Int Symp Int Coun- creation date May 3, 2004.

Systems Engineering DOI 10.1002/sys

60 ERIKSSON, BORG, AND BÖRSTLER

Magnus Eriksson is a systems engineer with BAE Systems Hägglunds AB in Örnsköldsvik, Sweden. Since
he joined Hägglunds, Magnus has been a key contributor in areas such as requirements engineering, system
architecture, and process improvement. He is currently also active as doctorial candidate at Umeå
University in Sweden, from where he also earned his Master of Science and Licentiate of Engineering
degrees. His main research interests are in the areas software product line development and systems
engineering. Magnus is a member of the ACM, IEEE, and INCOSE. Magnus was also the 2006 INCOSE
Brian Mar Award recipient.

Kjell Borg is currently software quality manager at BAE Systems Hägglunds in Örnsköldsvik, Sweden,
and has over 20 years of experience in software engineering and research. He holds a BSc in Mathematics
(1984) and a PhLic in Computer Science (1991) from Umeå University in Sweden. Mr. Borg has
experience in the fields of Usability Design, Requirements Engineering, Software Engineering, Quality
Management, Embedded Systems, Project Management, and Systems Engineering. He has business
experience, both as an employee and consultant, in areas of Telecom, Defence, Transport, Process Industry,
etc. He is a member of the Association of Computer Machinery (ACM) and INCOSE.

Jürgen Börstler is an associate professor and director of studies in computing science at Umeå University,
Umeå, Sweden. He received a Masters degree in Computer Science, with Economics as a subsidiary
subject, from Saarland University, Saarbrücken, Germany and a PhD in Computer Science from Aachen
University of Technology, Aachen, Germany. His main research interests are in the areas object-oriented
software development, requirements management, process improvement, and educational issues in
computer science.

Systems Engineering DOI 10.1002/sys