Use Cases for Systems Engineering—An Approach and Empirical Evaluation

Use Cases for SystemsEngineering—An Approachand Empirical Evaluation*Magnus Eriksson1, 2, †, Kjell Borg,1 and Jürgen Börstler2

1BAE Systems Hägglunds AB, SE-891 82 Örnsköldsvik, Sweden

2Umeå 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 revisionsPublished 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 andrequirements 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 caseRealizations) approach. The FAR approach is currently applied in several large-scale defenseprojects within BAE Systems Hägglunds AB. This paper also presents an empirical study whereFAR is applied and evaluated in two large-scale defense projects. Our results indicate thatthe FAR approach performs better than the previously used document based approach in theorganization. © 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

Organizations developing software-intense defensesystems, for example vehicles, are today faced with anumber of challenges. These challenges are related tothe characteristics of both the market place and thesystem domain.

Regular Paper

* This article is an extended and revised version of the papers by theauthors [Eriksson, Borg, and Börstler, 2006; Eriksson, Börstler, andBorg, 2006] which were presented at the 2006 INCOSE Symposium.† Author to whom all correspondence should be addressed (e-mail:[email protected]; [email protected];[email protected]; [email protected])..

Systems Engineering, Vol. 11, No. 1, 2008© 2007 Wiley Periodicals, Inc.

39

• Complexity. Systems are growing ever morecomplex, consisting of tightly integrated me-chanical, electrical/electronic and software com-ponents.

• Long life-cycles. Systems have very long lifespans, typically 30 years or longer.

• Few units. Often, relatively few systems are de-veloped and manufactured, ranging from only afew to several hundred units.

• High degree of customization. Systems are oftenpart of a product line of related systems; however,they are always customized for specific customerneeds.

For an organization to be competitive in a marketlike this it is important to achieve efficient developmentand maintenance. This makes it necessary to avoidmultiple implementations of the same functionality andto achieve high levels of reuse. It is furthermore veryimportant that the different engineering disciplines in-volved in development can communicate effectively.Development processes should be tightly integrated toensure that all disciplines are working towards a com-mon goal.

Systems engineering is a key function in any organi-zation trying to address such complexity. However,traditional systems engineering methods and tools suf-fer from two major shortcomings regarding these chal-lenges:

1. Traditional systems engineering typically utilizesclassical structured analysis techniques [Lykins,Friedenthal, and Meilich, 2000]. These tradi-tional techniques provide little support forachieving high levels of reuse. The reason for thisis that the top down process of traditional func-tional decomposition does not have any built inmechanisms for developing requirements thatmaps well to existing reusable components[Rickman, 2000].

2. Traditional systems engineering utilizes modelingtechniques, such as IDEFØ diagrams [NIST,1993], that are not commonly known to nontech-nical stakeholders or even other engineering dis-ciplines. This is a problem, since systemsengineering is the means by which stakeholderneeds are translated and communicated to otherengineering disciplines [INCOSE, 2004].

An interesting approach to address the first short-coming could be to adopt an object-oriented approach.Although object-orientation provides stronger meansthan structured analysis for achieving high levels ofreuse [Jacobson, Griss, and Jonsson, 1997; McGregor

and Sykes, 1992], it does not resolve the second short-coming. Most object-oriented approaches are based onthe UML [OMG, 2007a], which is not well known tononsoftware stakeholders. Adopting an UML basedapproach would certainly ease communication betweenthe systems- and the software engineering team(s), buthardly with other stakeholders such as customers, endusers, marketing, and mechanical and electrical engi-neering. However, use case modeling [Adolph et al.,2003], which is a technique traditionally used in object-oriented development, produces outputs that can beeasily communicated to both nontechnical stakeholdersand other engineering disciplines [Kruchten, 2000].Use case modeling is a functional decomposition tech-nique that provides a semi-formal framework for struc-turing the system functionality into user goals [Adolphet al., 2003]. These user goals are further specified by anumber of scenarios describing the interaction betweena system and its actors (users and environment) with thepurpose of achieving these goals.

Several proposals on how to utilize use cases as partof the systems engineering process have been describedin the literature (see section 2). Our main contributionin this area, which is presented in this paper, is twofold.First, we have developed a method for functional analy-sis/allocation [INCOSE, 2004] and requirements flow-down [Dorfman and Thayer, 1997] that utilizes usecases and use case realizations [Kruchten, 2000]. Thisapproach, called FAR (Functional Architecture by usecase Realizations), provides new insights on how toderive subsystem requirements from goal-oriented usecase models. Second, we provide an industrial evalu-ation of this approach in the context of software-inten-sive defense systems.

The remainder of the paper is structured as follows:Section 2 presents related work regarding use casemodeling in the context of systems engineering. Section3 introduces the activities and artifacts of the FARapproach. Sections 4 and 5 describe how to managescope creep and how to adjust the level of specificationdetail using the FAR approach. Section 6 presents anindustrial study where FAR was applied and evaluatedin the software-intensive defense system domain, andsection 7 presents the results of the evaluation. Section8 summarizes the paper and presents some future workin the area.

2. RELATED WORK

Lykins, Friedenthal, and Meilich [2000] suggested us-ing UML in an Object Oriented Systems EngineeringMethod (OOSEM). In OOSEM use cases are used tocapture key functionality in the system to be developed,

40 ERIKSSON, BORG, AND BÖRSTLER

Systems Engineering DOI 10.1002/sys

much as in traditional object oriented software engi-neering. OOSEM also provides some guidance on howto tailor use case modeling to systems engineering.

Based on experiences from Daimler-Chrysler, Alex-ander and Zink [2002] argue that use case modeling hasreal and substantial benefits in systems engineering.The authors introduce the concept of black-box andwhite-box use cases based on terminology from testing.Black-box use cases only consider the system from theoutside (i.e., as a “black box”), whereas white-box usecases consider the role of each subsystem inside this“black box” when realizing a use case. Furthermore, theauthors describe how use case modeling can be appliedon different system levels and how white-box use caseson one system level relate to black-box use cases on thenext level.

In the RUP-SE initiative from IBM-Rational [Ra-tional Software, 2002] a tabular text-based notation forblack-box and white-box use case scenarios are intro-duced. These notations are used in context of the so-called use case flowdown activity which aims to derivefunctional requirements for subsystems. In RUP-SE,subsystem-level black-box use cases are equal to sys-tem-level white-box use case scenario steps. Thismeans that surveys of all use cases for each subsystemcan be generated by sorting system-level white-box usecase scenarios according to participating subsystems.In theory this is a simple and appealing approach forderiving use cases for subsystems. However, our expe-rience from experimenting with this approach has re-vealed several issues. Our approach to use casemodeling is very goal-oriented (see section 3.4), how-ever using the RUP-SE strategy typically does not resultin “good” goal-oriented subsystem use cases. Instead,such subsystem use cases often represent a subsystemtask. That is, only part of a complete-goal that the usersof the subsystem want to achieve by interacting with thesubsystem. Furthermore, when sorting white-box sce-

nario-steps by subsystem, relevant sequencing informa-tion and possible preconditions are lost; this could yieldinvalid results (see section 3.10).

Daniels, Botta, and Bohill [2004] suggest that sys-tem-level functional requirements can be derived fromuse case scenarios by extracting the described behaviorand reformulating it as shall statements. According tothe authors, this would make requirements specifica-tions more robust since the benefits of easy to under-stand use cases are combined with the precision of shallstatements.

The OMG SysML [OMG, 2007b] is a graphicalmodeling language that supports specification, analy-sis, design, verification, and validation of complex sys-tems. OMG SysML is a profile of UML 2.0 [OMG,2007a] that also incorporates UML’s use case diagrams.UML/SysML is methodology and tool independent anddoes not provide any practical guidance on how toutilize use cases as part of the systems engineeringprocess. Several attempts to provide such guidancehave been made (see, for example, the I-Logix initiative[Hoffman, 2005]). However, these approaches do notaddress requirements flowdown based on use cases.

3. THE FAR APPROACH

The purpose of the functional analysis and allocationactivity in System Engineering is to clearly describe thesystem functionality, divide functions into subfunctionsand to allocate them appropriately to subsystems [IN-COSE, 2004]. As shown in Figure 1, functional analysisand allocation is based on input provided by require-ments analysis, which also receives feedback via therequirements loop from functional analysis and alloca-tion. Furthermore, functional analysis and allocationalso provides input to design synthesis and receivesfeedback through the design loop.

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

USE CASES FOR SYSTEMS ENGINEERING 41


Being a use case driven method, FAR closes therequirements loop by producing a use case model asoutput of the functional analysis and allocation func-tion. As shown in Figure 2, this use case model consistsof a survey of all use cases included in the system anddetailed specifications of each use case within thatsurvey. Furthermore, in addition to a traditional use casemodel, the FAR approach also produces a FunctionalBreakdown Structure (FBS). The purpose of this FBSis to provide an overview of the system functionality,which we feel, is missing in traditional use case models.The produced use case model also serves as input to theDesign Synthesis, as shown in Figure 2, and is therebyalso part of the design loop (see Fig. 1).

The feedback loop from Design Synthesis to Func-tional Analysis and Allocation includes a description ofthe physical architecture of the system. Details regard-ing development of this Physical Architecture Descrip-tion (PAD) is not within the scope of this paper and willnot be further discussed; however, for some usefulinsights in this area, see, for example, Bass, Clements,and Kazman [1998], Bosch [2000], and Hause andThom [2004]. As shown in Figure 2, the physical archi-tecture enters the functional analysis and allocationfunction as a control. This control triggers allocationswhich in turn will result in what we refer to as theFunctional Architecture Description (FAD) and a Re-quirements Allocation Sheet (RAS). A FAD is a collec-tion of all use case realizations for a system, where ause case realization is a description of how different

subsystems collaborate to solve a specific use case[Kruchten, 2000].

After specifying a system’s functional- and physicalarchitecture and allocating system level requirements tosubsystems, the next step of the systems engineeringprocess is commonly referred to as Requirements flow-down. The flowdown activity consists of deriving re-quirements specifications for each element of thesystems architecture based on the allocated system re-quirements [Dorfman and Thayer, 1997]. As shown inFigure 5, the FAD and the RAS are input to the require-ments flowdown activity, which produce requirementsspecifications for different subsystems as output.

3.1. The System Context Diagram

One important artifact, according to our experience, todevelop and agree upon before starting functionalanalysis and allocation is a system context diagram. Thesystem context diagram clearly visualizes the system-of-interest [ISO, 2002], its external interfaces, and itsusers. It defines the set of allowed entities for describingthe black-box functional view of the system. This helpsanalysts maintain focus on functions within the scopeof the system. As shown in Figure 3, our system contextdiagrams contain less information than, for example,the “elaborated system context diagram” used inOOSEM [Lykins, Friedenthal, and Meilich, 2000] or anIDEFØ context diagram [NIST, 1993]. By omitting

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



details regarding provided services and input/outputdata, we improve the readability of the diagram.

A use case actor is some type of entity, external tothe system-of-interest, which can interact with the sys-tem by exchanging information [OMG, 2007a]. A usecase actor can either be a human user or an externalsystem. A use case actor can have “association” rela-tionships to use cases, and “specialization” relation-ships to other actors. An association relationship to ause case means that the actor either initiates the use caseor takes part in performing the behavior defined by theuse case. If an actor can initiate a specific use case, it isa primary actor of that use case, else a secondary actor.In FAR, “specialization” relationships between actorsare shown as closed-head arrows between actors in thesystem context diagram (see Technician/Teller relation-ship to Bank Personnel in Figure 3). A specializationmeans that the more specialized actor inherits all asso-ciation relationships from the more general actor. It cancommunicate with all use cases as the more generalactor, but it can also have association relationships tofurther use cases. In the FAR approach, this relation isutilized for creating groups of users that can initiate acommon set of use cases. We have chosen to includethese relationships between actors in our system contextdiagram so that it may provide a full overview of allentities that can interact with the system-of-interest.

3.2. The “Perform Functional Analysis andAllocation” Function

As shown in Figure 4, the Perform functional analysisand allocation function is decomposed into six subfunc-

tions. The first four of these subfunctions regard func-tional analysis by development of a use case model. Thelast two subfunctions regard allocation of functions andquality attributes to subsystems. In the following sub-sections, we will discuss these different subfunctionsand the different modeling artifacts they result in.

3.3. The “Develop FBS” Function

The first step of the functional analysis is to develop apreliminary FBS based on the output from the require-ments analysis activity. As shown in Figure 5, this FBSshould include all major function groups and servicesprovided by the system-of-interest.

3.4. The “Identify Use Cases” Function

Our way of working with use cases has to a large extentbeen inspired by the work on Patterns for Effective UseCases by Adolph et al. [2003], in particular their goal-oriented approach to use case modeling. A use casemust either be a complete goal of the primary actors ofthat use case or a sub-goal derived from another use case(see Fig. 6). A complete-goal use case is achievedthrough interaction among use case actors and a system;this is in contrast to traditional functions which are moresystem-task oriented. Complete-goal use cases shall bederived from and be traceable to system requirements.Included subgoal use cases are typically identified byfinding common behavior in several complete-goal usecases that can be factored out and referenced, andthereby only be specified once in the model. Use casesare named as verb-phrase-goals and depicted in UMLuse case diagrams [OMG, 2007a] as shown in Figure 6.

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



Figure 6. A use case decomposition example.

Figure 5. Example FBS for an ATM system.

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



A difference between the FAR approach and tradi-tional use case modeling is that we do not use UML usecase diagrams to provide an overview over systemfunctionality and system scope; we use a FBS for thispurpose. We utilize use case diagrams only to visualizerelations between individual use cases and to providean overview of the primary and secondary actors of eachuse case. We provide this actor overview by usingdirected associations for primary actors and undirectedassociations for secondary actors of each use case (seeFig. 6). These individual use case diagrams are thenlinked to their corresponding elements in the FBS. Forexample, the use case diagram in Figure 6 would belinked to the “Cash Withdrawal” element in the FBS inFigure 5. Furthermore, there would also be another usecase diagram describing the details regarding the sub-goal use case “Authenticate Customer” which would belinked to the “Security” element of the FBS, as indi-cated by the parenthesis under the use case name inFigure 6.

Since FAR provides an overview of the model usinga FBS rather than using a use case diagram, we usuallydo not factor out scenarios from use cases using theUML “extend” relation, unless it is needed for struc-tural reasons in the model or to improve readability.This strategy helps us to reduce the number of docu-ments (use case specifications) in the model.

By tagging suitable sub-trees of the FBS as use casepackages [Kruchten, 2000], and utilizing links betweenthe FBS and use case diagrams, a “Use Case ModelSurvey” for the system can be created. This surveycontains the following elements:

• A system context diagram.• Descriptions of all use case actors.• An overview picture of the elements of the FBS

which are tagged as use case packages. Theseelements form the use case model hierarchy andwill therefore also have a corresponding headingin the survey outline.

• UML use case diagrams for all use case packages.• Brief descriptions of all use cases.

3.5. The “Identify Use Case Scenarios”Function

Each use case is described by one or more scenarios.Like Adolph et al. [2003], we distinguish between thefollowing three types of scenarios:

• A “Main Success Scenario,” which describes the“normal” way of achieving the goal stated in theuse case name

• Alternative Scenarios,” which describe alterna-tive ways of achieving the goal stated in the usecase name

• Exceptional Scenarios,” which describe how dif-ferent failures are detected and handled by thesystem.

Each of these scenarios should be named in a waythat clearly describes what is unique about it. The onlyexception from this naming rule is the main successscenario, which is not named if the normal procedure isobvious from the scenario context or use case name.

3.6. The “Specify Use Case Scenarios”Function

We describe use case scenarios in a tabular naturallanguage notation. This notation is based on the RUP-SE black-box flow of events [Rational Software, 2003],which we consider to have three major advantagescompared to traditional textual descriptions:

1. The notation is slightly more formalized andthereby easier to manage using tools.

2. The notation has separate fields for actor actionsand system responses to those actions. This sim-ple fact forces analysts to always think aboutinterfaces, which is a key success factor for main-taining focus in the modeling of complex sys-tems.

3. The “Blackbox Budgeted Requirements” field(rightmost column in Fig. 7) of the notation pro-vides an intuitive way to allocate quality attrib-utes to a use case scenario, which is not presentin traditional notations.

It would also be possible to apply the FAR method-ology utilizing UML/SysML sequence or activity dia-grams [OMG, 2007b] for describing use case scenariosand use case realizations. However, at this time, weconsider our natural language notation to be easier tounderstand for a more diverse set of system-stakehold-ers.

As illustrated in Figure 7, we describe alternativeand exceptional scenarios as so-called scenario frag-ments [Adolph et al., 2003]. These scenario fragmentsare specified as deltas to the main success scenario. Thefirst step identifier of the fragment determines the posi-tion where the fragment should be inserted into the mainsuccess scenario. A fragment can either return to themain success scenario, as “Incorrect Unique_ID” inFigure 7, or terminate as “Incorrect Unique_ID, Gen-eral_ID captured” in Figure 7.



Besides the actual tabular scenarios, our use casespecifications also include introductory informationsuch as context information regarding the use case goaland possible pre-conditions and post-conditions. Ifneeded, it is also possible to add this type of informationto individual scenarios (see “Incorrect Unique_ID,General_ID captured” in Fig. 7).

Even though we have chosen to exclude feedbackloops to improve the readability of Figure 4, develop-ment of these types of use case models is highly itera-tive. Identifying use cases and linking these to the FBS,as well as identification of alternative and exceptionaluse case scenarios, will typically result in the identifi-cation of new or modified elements in the FBS. Further-more, describing use case scenarios often results in newuse cases being discovered and other use cases are beingmerged. The reasons for this type of restructuring of theuse case model are usually to ensure that certain rulesof thumb regarding use case quality are fulfilled. Exam-ples of such rules are:

• A main success scenario should have betweenthree and ten steps.

• There should not be common behavior describedin several use cases. Common behavior should be

factored out as a subgoal use case and referencedby the source use cases using the UML “include”relation [OMG, 2007a]. We avoid using the “spe-cialization” relation to reuse use case behavior,since we consider it unclear on how it maps toscenarios.

• Scenarios should not have complex control struc-tures such as nested loops or if-statements. If suchare needed, a use case should rather be dividedinto sub-goal use cases to maintain high readabil-ity.

3.7. The “Specify Use Case Realizations”Function

Development of FAR use case realizations is in essencethe processes of allocating functions, modeled as usecases, to subsystems defined by a system’s physicalarchitecture. As shown in Figure 8, our notation for usecase realizations is based on the RUP-SE white-boxflow-of-events [Rational Software, 2003]. Each black-box step of a use case scenario is decomposed into anumber of so called white-box steps. These white-boxsteps describe how different subsystems collaborate tosolve each use case scenario black-box step. During this

Figure 7. Example black-box scenario descriptions.



process, each “Blackbox Budgeted Requirement” mustbe decomposed into one or more “Whitebox BudgetedRequirements.” Development of these use case realiza-tions usually involves tradeoff analyses to evaluate dif-ferent allocations, considering, for example, qualityattributes such as availability, reliability, and cost.

3.8. The “Allocate Quality Attributes toSubsystems” Function

Not all system requirements are suitable for use casemodeling. System-wide quality attributes, like environ-mental constraints, legislations, standards, etc., are suchexamples. These requirements must be handled in par-allel to requirements modeled as use cases. We managethese requirements in a Requirements Allocation Sheet(RAS). A RAS documents which subsystems are in-volved in fulfilling each requirement. When performingthis activity, it is important to capture background in-formation and rationale(s) for allocations. As shown inFigure 9, we also utilize the RAS to maintain traceabil-ity between system requirements and use cases.

3.9. The “Perform RequirementsFlowdown” Function

In the FAR approach, specifying subsystem require-ments is the responsibility of domain engineers (seeFig. 10). This is in contrast to the traditional view, wheresystems engineering is responsible for this activity.Experience has shown that passing specifications be-tween, for example, systems- and software engineeringdoes not yield satisfactory results [INCOSE, 2004]. By

allocating this responsibility to domain engineers, weforce them to analyze the origin of subsystem require-ments, which will give them a better system under-standing. Systems engineering is responsible forinitiating this activity and to guide the process to ensurethat the resulting subsystem requirements still representthe intent of the original system-level requirements andtheir corresponding allocations.

3.10. The “Analyze FunctionalArchitecture” and the “AnalyzeRequirements Allocations” Functions

These activities serve as controls to enable specificationof subsystem requirements. During these activities alsosubsystem context diagram for each of the definedsubsystems are developed. However, in contrast to thepreviously mentioned system context diagram, thesediagrams visualize the internal, rather than the external,interfaces of a system. This means that the use caseactors of a subsystem context diagram will typically notbe system users, but rather other subsystems.

Analysis of the FAD, focus on identifying interfacesbetween subsystems, and allocation of responsibilitiesfor sub-functions. It is important that FAD white-boxsteps are analyzed in the correct context. Without cor-rect sequence and other background information suchas possible preconditions, analysis may yield invalidresults. Analysis of a RAS consists to a large extent ofunderstanding the rationale(s) behind each allocationand the effect of every allocation for a particular sub-system.

Figure 8. An example use case realization.



3.11. The “Specify SubsystemRequirements” Function

The purpose of this activity is to produce subsystemrequirements that later will form the basis for detaileddesign. The analysis of the FAD should result in one ormore subsystem requirements being specified for each

white-box step. As shown in Figure 11, these subsystemrequirements are typically of input, output, or func-tional character. Analysis of the RAS will result in oneor more subsystem requirements being specified foreach “X” in the “Subsystems” part of the matrix. Theseresulting subsystem requirements are usually quality

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

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



attributes constraining the development of the subsys-tems.

3.12. The “Review SubsystemRequirements” Function

Although the responsibility of specifying subsystemrequirements is allocated to domain engineers, systemsengineering must still verify that the derived subsystemrequirements represent the original intent of the system-level requirements. The resulting subsystem require-ments must therefore be reviewed by systemsengineering before they can be baselined.

4. MANAGING SCOPE CREEP

It is often hard to draw a sharp line between fulfillingcustomer expectations and “gold plating” a system.Also preparing a system’s architecture for anticipatedchanges may result in many additional internal require-ments. These “prepared for” requirements are oftenunclear and can have a significant impact on the systemarchitecture. Therefore, it is very important to keeptrack of these types of requirements.

In the FAR approach, “gold plating” and “preparedfor” requirements are modeled by means of so-calledchange cases. Change cases, first proposed by Ecklund,Delcambre, and Freilung [1996], are basically use casesthat specify anticipated changes to a system. Eachchange case has “impact links” to all use cases that areaffected, when the change case is realized. These impactlinks provide a good basis for change impact analysis.In FAR, change cases are used to mark proposed, butnot yet accepted functionality. Whenever there is adiscussion if a function is gold plating or not, thefunction should be marked as a change case. However,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-type mechanism [OMG, 2007a] to model change casesin UML use case diagrams. Impact links are modeledas “dependency” relations stereotyped with “impacts”and change cases are modeled as use cases stereotypedwith “change case”. Besides from impact links, changecases can also have “include” and “extend” relations toother use cases as defined for use cases in the UMLstandard [OMG, 2007a]. For example, if a change caseadds one or more scenarios to an existing use case it ismodeled by creating a UML “extend”-relation from thechange case to the existing use case.

5. MANAGING THE LEVEL OF DETAIL

There is no straight answer to the question: “How muchsystems engineering is enough?” A decision to baselinethe systems engineering output and ramp-up the de-tailed design effort is a matter of risk management. Abetter question would be: “On what level of specifica-tion detail can an organization ramp-up the detaileddesign effort with acceptable risks?” In FAR, there arebasically two ways to manage this level of specificationdetail:

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

Figure 12. An example change case.



1. Reduce or increase the number of subsystems inthe design. More subsystems mean more white-box steps and more detail in the FAD and viceversa. The two extremes on this scale would bean architecture comprising a single subsystem(the system itself), or an architecture where eachconfiguration unit is a separate subsystem. In thefirst case, FAD white-box steps would actuallybe equal to their respective black-box steps. Ba-sically no design decisions are made. The secondcase would lead to a totally specified system,where there is no room for consecutive detaileddesign. Our experience has shown that a numberof subsystems leading to typically two to fourwhite-box steps per black-box step result inspecifications with high readability.

2. Apply FAR recursively. Complex/high risk sub-systems may be further analyzed and describedby moving to the next lower level of abstractionand treating them as the system-of-interest. Thisenables us to apply the FAR methodology recur-sively, since the inputs to and outputs of the FARprocess are basically the same (requirementsstatements).

6. EMPIRICAL EVALUATION

To evaluate the feasibility of FAR, an empirical studywas planned and executed in the approach’s targetdomain, long-lived software-intensive defense systems.The study was preformed with the Swedish defensecontractor BAE Systems Hägglunds AB, a leadingmanufacturer of combat vehicles, all terrain vehicles,and a supplier of various turret systems. The evaluationwas designed as a blocked subject-project study [Sea-man, 1999], where data were collected from two differ-ent pilot projects and compared to subjects’ experiencesfrom the company process baseline for managing thesystem functional view.

The company process baseline prescribes develop-ment of two artifacts, the “Functional Description” andthe “Functional Specification.” The Functional De-scription is a traditional document, structured accord-ing to the system physical architecture, where all logicalsubsystems have a corresponding heading in the docu-ment outline. Each of these subsystem’s functions isdescribed with logical interfaces, possible states, con-ditions, and exceptions. There are also references tofunctions allocated to other subsystems in each section.The purpose of these references is to enable tracing offunctions from the originating subsystem throughoutthe rest of the system. The Functional Specificationallocates the logical interfaces and logical subsystems

described in the Functional Description to physicalinterfaces and physical components. The FunctionSpecification is also document-based. Traceability be-tween the two documents is maintained by keeping acommon heading outline. A problem with this approachwas that two entire documents had to be read, front toback, to understand a single function. If only parts ofthe documents are read it may leave some parts of thefunction open for interpretation. Another problem wasthat these descriptions where too tightly coupled to thephysical architecture. Reusing parts of these documentsin other projects would require considerable restructur-ing to make them fit the architecture of the targetproject. In practice, this made reuse almost pointless.

The study hypothesis to be tested and its null hy-pothesis were:

H1: The FAR approach performs better than man-aging the functional view according to the com-pany process baseline in the current industrialsetting.

H0: The FAR approach performs equal to, orworse than, managing the functional view ac-cording to the company process baseline in thecurrent industrial setting.

To measure performance of FAR the research teamdefined a number of response variables (also referred toas dependent variables). These response variables werederived from the issues and needs discussed in section1, and the approach’s general feasibility. The resultingresponse variables were:

• Multi-disciplinary communication. Are the nota-tions used easy to understand and use for a diversset of system stakeholders?

• Expressiveness. Are notations expressive enoughto adequately describe the modeled domain?

• Usefulness of artifacts. Does all prescribed devel-opment artifacts provide value?

• Basis for detailed design. How useful is the re-sulting documentation for domain engineers?

• Reuse infrastructure. Does the approach providean improved reuse infrastructure?

• Finding common subfunctions. Dose the ap-proach aid in finding common subfunctions toavoid multiple implementations?

6.1. Study Context

Adequate tool support is an important factor whenmanaging models of complex systems. We have chosento utilize the commercial requirements managementtool Telelogic DOORS to manage our FAR models. To



make work more efficient, we have developed a numberof tool extensions using DOORS’ integrated scriptinglanguage DXL [Telelogic, 2004]. These extensions area subset of The PLUSS Toolkit, which is described indetail in Eriksson et al. [2005].

The two pilot projects studied during the evaluationregarded development of a turret system and a vehiclesystem. The systems engineering team of the first ofthese projects utilized the provided tool support fromthe start. The second project team, on the other hand,first started using only word processors and moved tothe provided tool environment only after approximately50% of the use case descriptions were already finished.At the time of the study, the first of these projects wasin the process of finalizing the systems engineeringoutput, and the second project had already ramped upthe detailed design and development effort.

6.2. Data Collection

Data were collected in four different ways: documentexamination, participant observation, questionnaires,and interviews [Lethbridge, Sim, and Singer, 2005].The majority of the collected data was of qualitativetype. Qualitative data are richer in information contentthan quantitative data [Seaman, 1999]. It was thereforeconsidered a better choice since data from only twopilot projects would result in too few data points for ameaningful statistical analysis.

During document examination the modeling arti-facts were inspected to identify possible common mod-eling errors and misunderstanding with FAR. We alsoexamined inspection records for these artifacts to iden-tify possible common errors that were captured duringinspections. Furthermore, a number of meeting minutesand product documents from two historical projects thatdeveloped similar products to the pilot projects werereviewed. A better understanding of both the organiza-tion process baseline and the systems being developedcould thereby be gained.

For participant observation the research team as-sumed a mentoring role for the systems engineers ap-plying the FAR approach. This mentoring activityconsisted of answering questions during a number ofmodeling sessions where we passively participated, andalso via phone and e-mail. This enabled us to getfirst-hand information regarding possible problemswith FAR.

All systems engineers in the study, in total six per-sons, also filled out questionnaires. These question-naires collected data regarding their experienceapplying the approach and their views on the tools andnotations used. The main purpose of these question-naires was to elicit information about possible con-

founding factors that could influence the evaluation.The information was later taken into account duringdata analysis. However, questionnaires were designedto have both specific and open-ended questions to alsoelicit unexpected types of information.

A total number of 11 subjects, representing systemsengineering, electrical engineering, and software engi-neering, were interviewed during the study. The pur-pose of these interviews was to gather their views onthe usefulness of the resulting models, and on possiblepros and cons, problems, and risks with FAR. Inter-views began with a short introduction to the researchbeing performed. After the introduction, the FAR proc-ess descriptions and the ATM artifact examples pre-sented in this paper were shown and discussed witheach interviewee. There were two reasons why thisrelatively trivial domain was chosen, rather than the realfull-size models of each project. The first reason was toprevent subjects from losing focus on the interviewquestions and instead start focusing on some projectspecific issue. The second reason was the ability toprovide all subjects in the study with exactly the sameintroduction to the interview situation. Interviews thenproceeded in a semistructured manner, to elicit as muchinformation as possible about opinions and impressionsregarding FAR.

6.3. Data Analysis

The different types of data were first analyzed individu-ally to find patterns and trends in the responses. Thedata were then grouped in two stages and analyzedagain:

• Per development project, to capture views relatedto possible differences between the projects inregard to how the method was applied.

• Per engineering discipline, to capture differencesbetween the views of software, electrical, andsystems engineering staff.

Findings were documented in the form of bullet listfield memos [Seaman, 1999]. Based on these findings,conclusions were finally drawn about the case studyhypothesis.

6.4. Threats to Validity

To minimize threats to the study’s construct validity,data were collected using several different methods thatalso allowed unexpected types of information to beelicited. Furthermore, the study hypothesis and its nullhypothesis were stated as clearly and as early as possi-ble in the case study design to aid in identifying correct



and relevant measures [Kitchenham, Pickard, andPfeeger, 1995].

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-tured information regarding each subject’s level ofexperience from the company process baseline, and theinformation was taken into account during data analysis[Kitchenham, Pickard, and Pfeeger, 1995]. Further-more, subjects were chosen in collaboration with theorganization’s management to ensure that they properlyrepresented their group of stakeholders. All chosensubjects agreed to participating in the study. To avoidthe Hawthorne effect [Mayo, 1933], attitudes towardsthe company process baseline were collected from sub-jects and taken into account during data analysis. It wasalso pointed out to subjects that no “correct” answersexisted, and that it was important that their answerscorrectly reflected their views. One confounding factorthat may have affected the internal validity of the studyis the close involvement of the research team with thesystems engineering teams during participant observa-tion. However, we do judge this risk to be minor andnot a serious threat study’s validity for the followingreasons:

• The mentoring activity consisted of question-and-answer sessions rather than actively partici-pating in the modeling effort.

• The teams performed most of the modeling with-out researchers present.

• The risk was taken into account during dataanalysis; special attention was paid to findinginconsistencies between observations and othertypes of collected data.

To minimize threats to the study’s external validity,the study was conducted in the target domain of long-lived software intensive systems, and projects wereselected to be of typical size and complexity for theorganization [Kitchenham, Pickard, and Pfeeger,1995].

To minimize threats to the study’s conclusion valid-ity, results were triangulated by collecting data withfour different methods from several different sources[Seaman, 1999]. Furthermore, member checking [Sea-man, 1999] was performed by allowing subjects toreview and comment on draft versions of this paper toassure that their opinions were correctly represented.One confounding factor that affects the conclusion va-lidity of the study is the limited types of stakeholdersthat participated in the study. By only including systemsengineering, software engineering, and electrical engi-neering, opinions of other important stakeholder groups

were not considered. We discuss this issue further in thefuture work section of this paper.

7. SUMMARY OF STUDY RESULTS

The following sections summarize the results of thestudy. Sections 7.1–7.4 present the results gained fromdocument examination, participant observations, ques-tionnaires and interviews, respectively. In section 7.5we relate results to our initial case study hypothesis anddraw conclusions. Besides results relating directly tothe case study hypothesis, we have chosen to alsopresent more general results that are likely to be ofinterest to practitioners.

7.1. Document Examination

Document examination indicated that the teams hadproblems identifying “good” goal-oriented use cases. Itwas often possible to sense the structure of the formerlyused Function Description in the resulting use casemodels. This meant that use cases often ended up beingsubsystem task oriented instead of being end-user goaloriented. This in turn led to a very flat FBS with toomany and too small use cases.

Other indicators of structural problems were theexistence of use cases named “Handle…” and “Man-age….” In such use cases, alternative scenarios wheretypically used for describing different task within spe-cific groups of functions, instead of describing differentways of achieving goals of primary use case actors. Thisled to problems with the goal oriented use case specifi-cation template. Examples of such problems were theneed of specifying different pre- and post-conditions foreach scenario and problems describing exceptional sce-narios.

One team also experienced problems maintaining aconsistent abstraction level in their use case scenariodescriptions. This team hade chosen not to develop aFAR system context diagram which we believe this tobe a major reason for this problem.

7.2. Participant Observation

Also participant observation indicated that it was hardto identify “good” use cases. Another problem noticedwas that it seemed to be hard to keep use case scenariosfree from unnecessary user interface design constraints,even though they should be free of such details. Oftenknowledge from earlier systems and possible proto-types had a tendency to influence the descriptions andthereby more or less force the same interaction methodsand sequences.



It was also noticed that teams experienced problemsdefining stimuli-response in use case scenarios forfunctions with little information handling, i.e., func-tions which typically end up with mechanical imple-mentations. Examples of such functions from ourdomain are applying the turret transport lock, manuallaying of the weapon, etc. This problem was, however,resolved during the mentoring meetings when the issuewas discussed and the teams agreed that also mechani-cal functions have input/output information such as forexample requested speed, torque, etc.

Teams also experienced problems modeling func-tions with extensive information handling. Examples ofsuch functions are reading logs, manuals, user instruc-tions, etc. In Hägglunds system architectures, thesetypes of functions are typically allocated to a singlesubsystem, the Vehicle Information System (VIS).Modeling these functions, teams often ended up de-scribing how functions are to be performed, instead ofsimply stating that they are performed. This can imposeunnecessary constraints on the detailed design of VISand might also result in redundant information in themodel, since subsystem-level details are ending up insystem-level specifications. Analyzing this issue, it be-came clear that this problem could affect any functionthat to a large extent is allocated to a single subsystem.This is a severe problem since it is, without gooddomain knowledge, basically impossible to catch be-fore allocation is performed. However, once allocationis done, it is relatively easy to identify such problemsand restructure the model to correct them. The rule-of-thumb to use in these cases is: If several consecutive usecase realization (white-box) steps are equivalent to theirrespective use case scenario (black-box) steps, mergethese black-box steps into a single step, by describingthe collected intent of all the original steps.

Teams also experienced problems describing func-tions that relied on using the intercom system. Commonpractice in use case modeling says that only interactionbetween the system and its actors are relevant informa-

tion to capture in scenarios. However, applying thispractice may render scenarios that are very hard to read,and alternative scenarios that are hard to understandwhy they were initiated. For example, consider thescenario in Figure 13. Depending on the informationpassed via the voice channel between the actors in step2, the remainder of the scenario may look very different.So, even though this information is hidden from thesystem and therefore typically would have been ex-cluded from the description, it can have large impact onthe remainder of the scenario. Our recommendation istherefore to include such interaction between use caseactors if it improves the readability of scenarios. How-ever, such interactions between actors should be mergedwith the next actor action that actually results in asystem response. Doing so enforces one of our goodpractice guidelines; all actor action steps of a scenarioshould result in a system response.

Yet another problem noticed during the modelingsessions was a tendency to model end-user businessprocesses instead of system usage. This phenomenonwas known as the “should/could-problem” within theorganization. In defense systems there are often require-ments stating that mission critical functions, such asfire, should be available to several of the system users.Modeling such functions, teams tried to model howthey believed the system should be used, instead ofmodeling how the system could be used, which is morerelevant from the perspective of finding subsystem re-quirements. Modeling should usage as normal andcould usage as exceptions, can also lead to new require-ments being invented, for example regarding differentusage modes. However, knowledge about intended us-age is important information to capture, for example asinput to the human factors team. Our recommendationis therefore that use case scenarios shall describe couldusage. However, intended usage should be captured asbackground information in the introductory part of ause case specification.

Figure 13. An example scenario with communication between actors.



A question raised during the mentoring sessions washow to handle Government Furnished Equipment(GFE). Applying common practice in use case model-ing would result in viewing GFE as use case actors. Thereason for this is that GFE is not developed by theorganization and therefore external to the system-of-in-terest. This would however in some cases result inscenarios with much interaction between actors, andlittle interaction between actors and the system. Suchscenarios are according to our experience not veryintuitive and provide little support for design synthesis.Consider, for example, if the intercom system used inthe scenario in Figure 13 would be GFE and seen as ause case actor instead of part of the system. This wouldresult in the scenario shown in Figure 14. Our recom-mendation is therefore to view GFE as subsystemsinstead of actors. One exception from recommendationis however GFE that provides external interfaces to thesystem-of-interest on the next higher system level. Inour domain this could, for example, be a BattlefieldManagement System (BMS). Such GFE should insteadbe viewed as use case actors. Such a view supportsabstraction; systems engineers only analyze the internalGFE interface, and not what is on the external side ofthe interface.

Another problem noticed was that experienced soft-ware engineers in particular could get confused byFAR’s “usage” of use case modeling. They assume,based on their experience from software development,that developing use case realizations is detailed designand should result in identified classes. However, sinceFAR utilizes use case realizations for the purpose offunctional allocation as part of the systems engineeringprocess, the goal is not to identify classes but rather toidentify subsystem requirements. Similar confusionwas also noticed in other parts of the organization.People that had not been directly involved in the pilot

projects had a tendency to believe that FAR specifica-tions were pure software specifications and therefore asoftware engineering rather than a systems engineeringresponsibility. We believe that these problems are re-lated to the fact that Hägglunds develops software ac-cording to a tailored version of the IBM-RationalUnified Process [Kruchten, 2000]. This process utilizessimilar modeling concepts as the FAR approach, but isrestricted to object-oriented software analysis and de-sign. However, these problems where only noted duringthe early phases of the pilot projects with subjects newto the FAR methodology. Therefore, they were notconsidered a real threat to the general feasibility of theapproach.

7.3. Questionnaires

Questionnaires showed that a majority of the systemsengineers considered the major artifacts of the FARapproach either useful or very useful (see Fig. 15).Questionnaires also showed that subjects consideredthe FAR notations to be relatively easy to understandand use.

Furthermore, questionnaires also showed that sub-jects considered the FAR tool support to have a numberof positive characteristics. Examples of these charac-teristics are strong support for traceability and the pos-sibility to maintain one, well-organized andversion-controlled database with all the systems engi-neering process outputs. From the answers, it was,however, obvious that the graphical user interface ofDOORS was causing a lot of annoyance among thesubjects. Examples of problems pointed out were thelack of shortcut keys, user interfaces bugs and that theuser interface does not follow MS Windows standards.

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



7.4. Interviews

Interviews with systems engineers showed that theyconsidered FAR to have a number of positive charac-teristics. Examples of theses positive aspects pointedout during the interviews were:

• The FAR approach is better at giving the wholepicture. It provides more context information byanswering the question: “Why is this functionimportant?”

• Being end-user oriented, the resulting artifactsprovide better input to the ILS (Integrated Logis-tics Support) team responsible for developinguser instructions and manuals.

• It provides a good and powerful framework foranalyzing functionality using end-user goals.

• This goal-orientation also means that the ap-proach provides better input to the human factorsteam.

• Applying the FAR approach provides bettermeans of understanding the product in contrast toonly understanding the system.

• It has stronger support for finding unclear re-quirements and other issues so that they can beclarified early in the development life cycle.

• Being scenario based, it provides stronger meansfor early architecture evaluations.

• Focus on traceability makes the origin of subsys-tem requirements obvious.

• Good that domain engineers are specifying sub-system requirements to force a deeper under-standing of the requirements.

• Generally easy to work with notations used.

Systems engineering also identified a number ofnegative characteristics and problems applying the FARapproach:

• When developing FAR models, more access tospecialists is required. It can sometimes also be

hard to get these specialists to document theirknowledge.

• The FAR approach is more formalized than theprevious approach, which makes everythingslower.

• The FAR approach is a more advanced way ofmanaging the functional view. This means that ittakes more time to get everyone to understand themethodology.

• Some functions are hard to describe as use cases.Examples of such are functions triggered by tim-ers or sensors.

• It is hard to identify good use cases and scenarios.Mining information from historic projects oftenresults in too detailed scenarios.

• Maintaining a “single voice” and consistent ab-straction levels when several people where in-volved in writing use cases is problematic.

• Some team members have earlier experiences ofuse case modeling which differs from the FARapproach. This leads to problems agreeing on theuse case model structure.

• The FAR approach is harder to perform if tele-commuting, as it seems to work best as team-work.

Systems engineering also identified a number ofrisks using the FAR approach compared to the previousdocument based approach:

• Using more advanced tools and methodologymight cause some very skilled and field experi-enced people, for example in the verificationteam or the production team, to be left outside theloop.

• Teams new to the methodology may develop usecase models that have an unsuitable structure dueto previous experiences from use case modeling.They should therefore have access to a method-

Figure 15. Usefulness of artifacts according to questionnaires.



ology mentor and have scheduled mentoringmeetings to force them to ask questions.

• Using a more formalized approach may causedomain engineers to get too trusting when read-ing specifications. This could cause them not tonotice if domain specialists forget to put some-thing in a specifications.

Even considering these drawbacks, problems andrisks, all systems engineers in the study agreed that theFAR approach is a better method than the previous.They considered the FAR approach to be an efficientway of managing the functional view, and that it is theproper approach for future projects. All systems engi-neers in the study also agreed that most of the problemsexperienced could be related to the fact that the meth-odology had been applied in pilot projects with too fewgood examples and instructions to follow.

Also software engineering expressed a number ofpositive characteristics of the FAR approach duringinterviews:

• FAR models provide a good overview of thefunctional scope of the system and it puts func-tions in their correct context.

• The FAR approach is better at bringing unclearrequirements up on the agenda early in the projectand could thereby make detailed design muchmore efficient. It furthermore provides strongsupport for finding software requirements, aslong as the quality attributes are not forgotten.

• The FAR approach provides better support forreuse of specifications between projects, since theresulting artifacts are structured around end-usergoals rather than the physical architecture. Thisprovides a possibility for the organization to sig-nificantly reduce its development costs in thefuture.

Software engineering mainly pointed at two nega-tive characteristic of the FAR approach compared to theprevious method used. The first of these was that it isharder to verify that everything fits together using sev-eral small artifacts instead of one large artifact. Thesecond was that it is much harder to write a good usecase than to fill out sections in a traditional documentstructure. This fact significantly reduces the availableresources able to do the job. One individual also pointedat a “risk” with the approach. Since these artifacts arebetter means of communication with customers, it mayprovide customers with better opportunities to sneak innew requirements during common reviews. Also allsoftware engineers in the study agreed that the FARapproach is generally better than the earlier method

used and that the FAR approach is the right path tofollow also in future projects.

Also electrical engineering expressed a number ofpositive characteristics of the FAR approach duringinterviews:

• The FAR approach is better at forcing people toreally understand the intent of the requirements.

• Goal and end-user focus provide stronger meansto find “good” system solutions.

• The resulting artifacts are also good input to theILS team writing user instructions.

• FAR models works very well for finding subsys-tem requirements.

• It provides good support for early architectureevaluations from the perspectives of necessaryinterfaces, system safety considerations, etc.

Drawbacks with the FAR approach compared to theprevious method raised by one electrical engineer wasthat the FAR approach requires access to a lot of spe-cialists and that it might require more time to finishspecifications. A problem mentioned by electrical engi-neering was that it can sometimes be hard to understandcomplex scenarios in the notation used, and that asupplementary diagram would be very useful in thosecases. Electrical engineering identified mainly tworisks with applying FAR. The first risk is that if devel-opment of the FAD is not performed by multidiscipli-nary teams, it might result in unrealistic specifications.The second risk, which was identified by one electricalengineer, is that if the FAD is not mature enough at thestart of the detailed hardware design it might not beused. Due to long lead-times on hardware it is some-times hard to postpone the start of the detailed design.Also all electrical engineers in the study agreed that theFAR approach is generally better than the earliermethod used and that FAR is the proper path to followin future projects.

Interviews also elicited information regarding pos-sible shortcoming of the notations used for describinguse case scenarios and use case realizations. The sub-jects identified the following problems:

• It is hard to describe conditions that have to befulfilled only during part of a scenario. The usecase template provides the possibility to specifypre-conditions for a scenario, but no intuitive wayto specify for example that the dead-mans-griphas to be held down during step four to step seven.

• The semantics of the notation is unclear regardingwhether a scenario is just one way of performingthe function or a required sequence of actions: forexample, a drive sequence, [accelerate → use



turning signal → turn → use horn → break],versus a fire sequence, [aim → arm → fire].How to specify if the order of sequence is impor-tant or not?

• It is hard to describe state dependent behavior.• Using scenario fragments may result in a single

alternative scenario, which should contain sev-eral unconnected fragments, describing severaldeltas to the main success scenario. There is nointuitive way to describe this situation in thenotation.

On the question of experienced usefulness of FARmodeling artifacts, all subjects in the study consideredthe System Context Diagram to be an important artifactfor the following reasons:

• The context diagram makes everything easier; itis inefficient to work without it.

• It is important to agree on naming conventionsand scope early; the context diagram is helpful inthis area.

• The context diagram improves the quality of usecases since it specifies all entities that are allowedto appear in use case scenarios.

A majority of the systems engineers, all softwareengineers, and a majority of the electrical engineers inthe study considered the Functional Breakdown Struc-ture to be an important artifact for the following rea-sons:

• It is important to agree on the model structureearly.

• It provides a good overview of the system’s capa-bilities.

• It provides help to find use cases, and also tosay—Stop, we found all use cases.

• It provides context to the use cases in the model.• It is fun to develop.• It helps to keep track of the progress of the

systems engineering effort.

A majority of the systems engineers, half of thesoftware engineers, and a majority of the electricalengineers in the study considered the Use Case ModelSurvey to be an important artifact. Reasons given forthis were that it provides a good overview of the usecases in the model and that it helps make work morecontrolled. The general comment from subjects that didnot consider it to be an important artifact was that it isnot worth the effort to develop, since all information isbasically also present in the use case specifications.

All subjects considered Use Case Specifications tobe important artifacts for the following reasons:

• They force people to really think about how thesystem is intended to be used in the field.

• They are good for reuse and change impact analy-sis, when developing a new system within thesame product line.

• They are an effective way to capture the func-tional view of a system.

However, one problem regarding use case specifica-tions was pointed out during interviews. Use case speci-fications were sometimes considered almost ridiculesby specialists because of their lack of implementationdetails.

All subjects considered Use Case Realizations to beimportant artifacts for the following reasons:

• They are an effective way to perform functionalallocation.

• They lead to higher reusability of the resultingsolutions.

• They are a good tool for architecture evaluation.• They are a good source for clear subsystem re-

quirements. • They provide good input to the verification team

when specifying test cases.• They provide a good basis for detailed hardware

design.

Problems pointed out during interviews regarding de-velopment of use case realizations was that they requireaccess to lots of system knowledge and that they aremore expensive to develop than use case specifications.

All subjects considered the resulting models to be agood means of communication both with nontechnicalstakeholders such as customers, and between differentengineering disciplines. FAR models were consideredto help the different engineering disciplines to commu-nicate on a common abstraction level. However, oneissue pointed out was that some engineers seem to wantmore details in the specifications. Several engineersalso had practical experience discussing FAR specifica-tion with customers. These experiences had been verypositive except for one issue; customers sometimeshave problems understanding the specifications be-cause they contain too much organization specific ter-minology. It was also pointed out that the specificationsshould be supplemented with a user interface prototypeto work really well when communicating with custom-ers.

A majority of the systems engineers, all softwareengineers, and a majority of the electrical engineersconsidered the FAR approach to provide stronger sup-



port for finding common subfunctions and therebyavoiding multiple implementations, than the previousdocument based approach. Systems engineering alsoconsidered the approach to be better than structuredanalysis in this area, because of its end-user goal focus.Software engineering considered the FAR approach toprovide the architect with exactly the tools needed tocatch such sub-functions. Electrical engineering con-sidered the FAR approach to be better in this area sinceit provides a better overview of such functions.

All subjects in the study agreed that FAR providesstronger means for achieving high levels of reuse, thanthe previous approach. Systems engineering pointed outthat using this methodology improves the possibilitiesto sell capabilities that can be implemented by existingsolutions rather than selling new solutions. Softwareengineering stated that this area is probably the strong-est feature of the FAR approach. The information in thespecifications is captured in a form that is easily reus-able in the next project, and it thereby encourages reusealso of the solutions, which resulted from those speci-fications in the first place. Electrical engineering con-sidered the resulting use case specifications to be almostplatform independent information that can easily betransferred to new projects. This fact combined with thestrong support for traceability makes the FAR approachvery good for reuse.

7.5. Conclusions

Triangulating the collected study data leads us to rejectthe study null hypothesis. The FAR approach performsbetter than managing the functional view according tothe company process baseline in the specified industrialcontext. All subjects participating in the study considerthe FAR approach superior to the previously used ap-proach. We believe that many of the problems experi-enced during the study were related to the fact that FARwas applied in pilot projects. This opinion was alsoexpressed by several subjects during interviews.

We also conclude that all artifacts prescribed by theFAR approach provide value and are worth the effortdeveloping. However, the study has shown that thetextual notations used in FAR are not expressive enoughto effectively capture complex state-dependent behav-ior in scenarios and realizations. We therefore recom-mended that the FAR notations be supplemented withfinite-state machines to resolve ambiguities and im-prove accuracy in such cases. However, to maintainhigh readability, it is important that finite-state ma-chines are only seen as a supplement and not a replace-ment for scenarios. Another possibility would be to useUML 2 sequence diagrams with control logic and ref-erence sequences [see OMG, 2007a]. However, we

prefer finite-state machines over sequence diagrams forthe following reasons:

• Control logic constructs significantly reduce theunderstandability of models for system-stake-holders not familiar with UML/SysML.

• The underlying semantics of interaction dia-grams and our textual notations are basically thesame. Adding sequence diagrams to the modelwould therefore introduce redundant informa-tion. Finite-state machines, on the other hand, adda different and additional view of the problemwhich we believe improves both precision andunderstandability.

Another issue noticed was the problem of identify-ing “good” goal-oriented use cases. The present studyindicates that more methodological support is neededin this area. One interesting approach to address thisissue would be to investigate if Cognitive Task Analysis(CTA) [Schraagen, Chipman, and Shalin, 2000] couldprovide such support. CTA, which is a goal-orientedapproach used in human factors engineering, mightprovide a good basis for goal-oriented use case model-ing. Utilizing CTA as a basis for FAR use case modelingwould also have the positive side-effect of integratingthe human factors team into the early systems engineer-ing effort.

8. SUMMARY AND FUTURE WORK

We have described how use case modeling can becomean integral part of the systems engineering processrather than being a tool for requirements analysis. Bydeveloping system level use case realizations, the FARapproach extends use case modeling to form the basisfor functional allocation as well as requirements flow-down.

One important area of future work regarding theFAR approach is improved support for the modeling ofquality attributes, such as availability and system safetyrequirements. An interesting approach to support thiskind of work fitting very well within the FAR frame-work is referred to as “Misuse Case” modeling [Sindreand Opdhal, 2005]. Sindre and Opdahl define a misusecase as the inverse of a use case; a function that thesystem should not allow. This technique has been ap-plied to for example security requirements, and is likelyto be applicable even to other types of quality attributes.From this perspective it would also be interesting toinvestigate and develop guidelines on applying QualityFunction Deployment (QFD) [Hari, Kasser, and Weiss,2007] together with FAR.



The present study only included subjects from sys-tems engineering, software engineering, and electricalengineering. It would therefore be desirable to performa follow-up study capturing the views of other impor-tant groups of stakeholders, such as mechanical engi-neering, the ILS team, and the verification team. Fromthis perspective, it would also be interesting to performformal experiments to compare FAR models to tradi-tional structured analysis artifacts.

REFERENCES

S. Adolph, P. Bramble, A. Cockburn, and A. Pols, Patterns foreffective use cases, Addison-Wesley, Boston, 2003.

I. Alexander and T. Zink, Introduction to systems engineeringwith use cases, Comput Control Eng J 13(6) (December2002), 289–297.

L. Bass, P. Clements, and R. Kazman, Software architecturein practice, Addison-Wesley, Boston, 1998.

J. Bosch, Design & use of software architectures: Adoptingand evolving a product-line approach, Addison-Wesley,Boston, 2000.

J. Daniels, R. Botta, and T. Bahill, The hybrid process thatcombines traditional requirements and use cases, Syst Eng7(4) (2004), 303–319.

Department of Defense (DoD), Systems engineering funda-mentals, Defense Acquisition University Press, FortBelvoir, VA, 2001.

M. Dorfman and R. Thayer, Software requirements engineer-ing, IEEE Computer Society Press, Los Alamitos, CA,1997.

E. Ecklund, L. Delcambre, and M. Freiling, Change cases—use cases that identify future requirements, Proc OOP-SLA’96, San Jose, CA, October 6–10, 1996, pp. 342–358.

M. Eriksson, H. Morast, J. Börstler, and K. Borg, The PLUSStoolkit—extending telelogic DOORS and IBM-RationalRose to support product line use case modeling, Proc 20thIEEE/ACM Int Conf Automated Software Eng, 2005, pp.300–304.

M. Eriksson, K. Borg, and J. Börstler, The FAR approach—functional analysis/allocation and requirements flowdownusing use case realizations, Proc 16th Annu Symp IntCouncil Syst Eng (INCOSE’06), International Council onSystems Engineering, 2006.

M. Eriksson, J. Börstler, and K. Borg, Performing functionalanalysis/allocation and requirements flowdown using usecase realizations—an empirical evaluation, Proc 16thAnnu Int Symp Int Council Syst Eng (INCOSE’06), In-ternational Council on Systems Engineering, 2006.

A. Hari, J. Kasser, and M. Weiss, How lessons learned fromusing QFD led to the evolution of a process for creatingquality requirements for complex systems, Syst Eng 10(1)(2007), 45–63.

M. Hause and F. Thom, Creating flexible architectures forsystems engineering, Proc 14th Annu Int Symp Int Coun-

cil Syst Eng (INCOSE’04), International Council on Sys-tems Engineering, 2004.

H. Hoffman, UML 2.0-based systems engineering using amodel-development approach, CrossTalk 18(11) (No-vember 2005).

International Council on Systems Engineering (INCOSE),Systems engineering handbook version 2a, INCOSE-TP-2003-016-02, 2004.

ISO/IEC, Systems engineering—system life cycle processes,International Standard: ISO/IEC FDIS 15288:2002(E),2002.

I. Jacobsson, M. Griss, and P. Jonsson, Software reuse, Ad-dison-Wesley, Boston, 1997.

B. Kitchenham, L. Pickard, and S. Pfleeger, Case studies formethod and tool evaluation, IEEE Software 12(45) (July1995), 52–62.

P. Kruchten, The Rational Unified Process—an introduction,2nd edition, Addison-Wesley, Boston, 2000.

T. Lethbridge, S. Sim, and J. Singer, Studying software engi-neers: Data collection techniques for software field stud-ies, Empirical Software Eng 10(1) (July 2005), 311–341.

H. Lykins, S. Friedenthal, and A. Meilich, Adapting UML foran Object Oriented Systems Engineering Method(OOSEM), Proc 10th Annu Int Symp International Coun-cil Syst Eng (INCOSE’00), International Council on Sys-tems Engineering, 2000.

E. Mayo, The human problems of an industrial civilization,MacMillan, New York, 1933.

J. McGregor and D. Sykes, Object-oriented software devel-opment: Engineering software for reuse, Van NostrandReinhold, New York, 1992.

National Institute of Standards and Technology (NIST), Inte-gration Definition for Function Modeling (IDEF0), Fed-eral Information Processing Standards 183, 1993.

Object Management Group (OMG), Unified Modeling Lan-guage Version 2.0, http://www.uml.org, 2007a.

Object Management Group (OMG), OMG Systems Model-ing Language—OMG SysML, http://www.omg-sysml.org, 2007b.

Rational Software, The Rational Unified Process for systemsengineering —Whitepaper Ver. 1.1, http://www.ra-tional.com/media/whitepapers/TP165.pdf, 2003.

D. Rickman, A process for combining object oriented andstructured analysis and design, Proc 3rd Annu Syst EngSupportability Conf, National Defense Industrial Associa-tion (NDIA), 2000.

J. Schraagen, S. Chipman, and V. Shalin, Cognitive taskanalysis, Lawrence Earlbaum, London, 2000

C. Seaman, Qualitative methods in empirical studies of soft-ware engineering, IEEE Trans Software Eng 25(4)(July/August 1999), 557–572.

G. Sindre and A. Opdahl, Eliciting security requirements withmisuse cases, Requirements Eng 10(1) (January 2005),33–44.

Telelogic AB, DXL reference manual, DOORS 7.1, Manualcreation date May 3, 2004.



Magnus Eriksson is a systems engineer with BAE Systems Hägglunds AB in Örnsköldsvik, Sweden. Sincehe joined Hägglunds, Magnus has been a key contributor in areas such as requirements engineering, systemarchitecture, 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 Engineeringdegrees. His main research interests are in the areas software product line development and systemsengineering. Magnus is a member of the ACM, IEEE, and INCOSE. Magnus was also the 2006 INCOSEBrian 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 hasexperience in the fields of Usability Design, Requirements Engineering, Software Engineering, QualityManagement, Embedded Systems, Project Management, and Systems Engineering. He has businessexperience, 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 subsidiarysubject, from Saarland University, Saarbrücken, Germany and a PhD in Computer Science from AachenUniversity of Technology, Aachen, Germany. His main research interests are in the areas object-orientedsoftware development, requirements management, process improvement, and educational issues incomputer science.



Use Cases for Systems Engineering—An Approach and Empirical Evaluation

Documents

Transcript of Use Cases for Systems Engineering—An Approach and Empirical Evaluation