[IEEE International Conference on Global Software Engineering (ICGSE 2007) - Munich, Germany (2007.08.27-2007.08.30)] International Conference on Global Software Engineering (ICGSE

A unified requirements model; integrating features, use cases, requirements,requirements analysis and hazard analysis

Brian BerenbachSiemens Corporate Research, Inc.

755 College Road EastPrinceton, New Jersey 08540

[email protected]

Timo WolfTechnische Universitat Munchen

Department of InformaticsChair for Applied Software Engineering

Boltzmannstrae 3D-85748 Garching, Germany

[email protected]

Abstract

In global development projects, different modeling tech-niques are used to create and manage the requirements, an-alyze the problem domain, identify potential hazards anddevelop the system design. For each modeling technique,separate tools (e.g. UML case tool, requirements database,Word) are used. Each tool comes with its own meta-model,which hinders the interchange of models across tools andmakes automated traceability and quality analysis acrossall models unmanageable.

We propose the integration of different modeling tech-niques by adding new relationships. The integrated require-ments model supports complete traceability across featuremodeling, use case modeling, requirements and hazardanalysis, detailed requirements and system design. We pro-pose design rules and metrics for a formal and automatedquality assurance, project monitoring and control. Themodel is implemented in a central repository, accessiblefrom distributed sites. Synchronous online collaboration,asynchronous offline access and model-based configurationmanagement is supported for the entire unified requirementsmodel.

1. Introduction

On complex projects, the requirements are usually doneby different teams or people. Hazard analysis, threat mod-eling, functional and non-functional requirements are typ-ically elicited by professionals with different skills. Thecompartmentalization of requirements gathering can be ex-acerbated on global projects in several ways. In the caseof product lines, requirements gathering may be brokenup among regions. With very large projects, require-

ments gathering may be distributed among different busi-ness units.

Traditional requirement management techniques maynot work well when the elicitation is distributed:

• Analysts may have difficulty or skip reviewing require-ments gathered by other teams

• It can be very difficult to visualize the trace relation-ships between requirements.

• Cross-team relationships may be overlooked or not de-fined because of organizational issues or time pressure.

For example, some medical products must be analyzedfor potential hazards in order to be sold in certain coun-tries. Once a product feature is associated with a hazard,requirements may be created in order to mitigate the poten-tial hazard. However, the requirements, feature, and hazardanalysis may be created by different groups; worst case theymay not even know each other. Furthermore, the work prod-ucts are dispersed among different media with the problemof fragile (or no) traces. Even if the traces exist, there is nosingle view that shows the relationships.

By extending traditional modeling techniques, andadding new artifacts and relationships to models, it is possi-ble to overcome some of the problems inherent with tradi-tional requirements gathering techniques.

Moreover, by keeping as many of the artifacts as possi-ble in a single database (e.g. the hazard analysis, feature,and mitigating requirements), the traces between them areno longer fragile, but are, in fact, implicit in the modelingtechnique: changing a relationship in a view will change theunderlying model, and any other views that show some orall of the artifacts will immediately reflect the change.

This paper proposes a unified requirements model inte-grating features, use cases, requirements analysis, detailed

International Conference on Global Software Engineering(ICGSE 2007)0-7695-2920-8/07 $25.00 © 2007

Figure 1. Modeling stakeholder requirements by integrating feature models and use cases.

requirements and hazard analysis. The model is based onthe worked presented in [3]. For evaluation, we imple-mented the model in Sysiphus [16], which provides a singlecentral repository, containing all project model artifacts andwhich is accessible from distributed sites. By using Sysi-phus, informal collaboration about the unified requirementsmodel is automatically enabled as shown in [5].

2. Stakeholder Requirements

We explicitly start the description of the unified require-ments model with project stakeholders. A stakeholder isa person or organization who has a certain interest in theproject. A stakeholder creates stakeholder requests, whichare the initial elements for creating requirements of theproject. For requirements traceability it is essential toknow the original stakeholders of a requirement [6, 9, 7].This knowledge is needed when negotiating about differ-ent and possibly contradicting requirements, as the originalstakeholders have differing needs and influence within theproject. Moreover, it is important to verify that each re-quirement is based on a stakeholders request. Otherwise,it may be an orphan or “gold plated” requirement, whoseimplementation costs and resources have no financial justi-fication.

We explicitly add a stakeholder class into our require-ments model. The class may be associated with many stake-

holder requests. As many stakeholders and clients do notaccess the requirements tool of the project, the requests arecreated and associated with the related stakeholder by a re-sponsible requirements engineer or analyst. A stakeholderrequest has a unique name or id, a description, explainingrequired needs and a status attribute that defines if the re-quest is accepted or not.

If a stakeholder request is accepted, it will be associatedwith one or more features describing the stakeholders needsincluding variability (see figure 1). According to the defini-tion of Kang et al. (1990) [10] a feature is a property of asystem that directly affects the end user:

“Feature: A prominent or distinctive user-visible aspect,quality, or characteristic of a software system or systems”

A Feature is detailed in any number of subfeatures thatare mandatory, optional, or alternative. Mandatory subfea-tures describe detailed aspects that the parent feature mustsupport, while optional subfeatures may be selected whencreating a concrete system from a feature model. Alterna-tive subfeatures have a multiplicity similar to the UML mul-tiplicity, which defines how many of the subfeatures must ormay be selected [13]. A feature may be reused as subfea-ture by many other features; thus, a feature may have manyparents. In addition to the hierarchical relationship, a con-straint relation defines if a feature requires or conflicts withany other features.


The feature requested by a stakeholder is called a con-cept feature and is represented within a feature diagram thatforms a tree. The concept feature is the root node of thefeature diagram and all subfeatures are represented as childnodes. The hierarchical relationships mandatory, optional,and alternative are represented by different edges betweenthe nodes of the tree. A simple line denotes the mandatoryrelationship, while the optional relationship is representedwith a line, ending with a cycle. An arc spanning two ormore edges of the feature nodes depicts a set of alternativefeatures. The arc is annotated with the multiplicity of thealternative. [14]

Feature models are able to describe the aspects, qualitiesor characteristics of a system and specially include variabil-ity modeling for system families. They focus on hierarchi-cal decomposed system characteristics, but do not neces-sary include the end-users of the system. The structure ofthe feature model does not describe how a feature is used bythe end-user, but rather provides a clear, unambiguous rep-resentation of the final product line with all possible varia-tions and combinations.

In order to describe end-user interaction with a system,we can use use case modeling. Use case modeling is awell-accepted technique to describe the interaction betweenend-users and the system as a textual flow of events. Usecases represent functional requirements from an end-userperspective, as they describe what users can do and howusers interact with the system. Any parties outside the sys-tem that interact with the system are modeled as actors.They may be human users or other external systems. Byhaving a certain goal and requiring assistance of the system,an actor initiates a use case, which in turn may involve manyother participating actors from which the system needs as-sistance to satisfy its goal. [8, 12]

To combine the advantages from feature modeling anduse case modeling in a single set of views in a singledatabase, we propose creating a new association relatingfeatures with use cases. Use cases associated with featuresdescribe the features from an interactive end-user perspec-tive, where the end-user is represented as an actor. The in-teraction is represented as a textual flow of events. The fea-ture is either associated with the use case in general, or witha concrete event of its event flow. Thus, a higher-level usecase can describe the interaction with the system, includingmany different features.

To identify the user of a feature, each feature should bedescribed by at least one use case. Features without usecases or use cases without features should be subject of re-quirements reviews that identifies whether the related fea-tures or use cases are really needed or if they should berevised. Figure 1 shows the described stakeholder require-ments model as a UML class diagram.

3. Requirements Analysis

To explore and understand the problem domain, we pro-pose to create an object-oriented requirements analysis asdescribed in [4]. The analysis is based on the use casemodel and includes the creation of a structural and a dy-namic model by using UML models and diagrams. To cap-ture the relations and to maintain traceability between thestakeholder requirements and the analysis, we propose tocreate new associations. By using Abbotts rules [1] for nat-ural language analysis, participating objects should be iden-tified on use cases and captured as class models. We createa new participating objects association between a use caseand the analysis class. For clarification and for adding moredetails, a use case can be defined1 with state, activity or se-quence diagrams.

Figure 2. Typical associations between theuse case model and the object-oriented re-quirements analysis.

Sequence diagrams are used for instantiating use cases,providing a detailed interaction model by sending messagesbetween the participating objects. The objects of a se-quence diagram are instances of the analysis class model.The initiating actor of a use case should also initiate therelated sequence diagrams and interact with boundary ob-jects. Each event of the use case event flow is mapped to amessage from the initiating actor to the boundary object orback. The requirements analyst can than add new objectsand messages to describe the internal control flow that de-scribes how the goals of the use case are resolved by thesystem. During this activity missing control and entity ob-jects are identified. Whenever new messages between theactor and the boundary objects are created or deleted, the

1We use the term “defined” with respect to a use case to mean “ex-plained in detail”. A use case diagram has only structural information, andone or more views showing dynamic behaviour are needed to complete thedefinition of the use case.


use case event flow gets automatically updated. Respec-tively, all changes of the use case event flow are automati-cally updated in the instantiating sequence diagrams. Thismechanism is described in detail in [15].

Activity and state diagrams are used accordingly the se-quence diagrams to expose a use case. Each event of theevent flow is either represented as an activity or state. Ac-tivity and state diagrams are best suitable when focusing onalternative event flows. Analysis classes are used as inputand output objects on activities.

Object-oriented analysis is not new, but it is impor-tant to capture the relations between the analysis and thestakeholder requirements model as associations that supporttraceability and maintenance across these models. Somechanges may result in additional cascaded automatic modelchanges, while other changes may lead to the generation ofcomments that indicate the change of related elements andidentify items that have to be reviewed. Figure 2 shows theproposed associations between the use cases and the analy-sis model as a UML class diagram.

4. Detailed Requirements

During the analysis of high level requirements we createfine-grain requirements that are either functional or non-functional. Each requirement has a unique name-id pairand a description. The granularity must be sufficientlyfine that the requirement can be tested against a componentimplementing the requirement. A functional requirementdescribes a required system function and may be associ-ated with many refining functional requirements. A non-functional requirement describes a property or quality andcan constrain many functional requirements to indicate thequality of the functionality. The constrains association isin particular important for testing. Testing a functional re-quirement “The user must be able to login” is completelydifferent if it is constrained by the non-functional require-ment “The system must support 50000 users in parallel”.

A functional requirement must be based on at least onefeature or use case, while a non-functional requirement isbased on features or gets identified as a constraint on one ormore use cases (e.g. a constraint that forms in a browsermust completely appear within 4 seconds after being re-quested might apply to any use case where a user needsto see a form). Figure 3 shows the detailed requirementsmodel and its associations to the feature and use case model.

5. Hazard Analysis

During hazard analysis we identify potential hazards forthe users of the system under development. A hazard has aunique name or id, a description and a severity. As a hazard

Figure 3. Shows the associations betweenthe stakeholder requirements as related fea-tures and use cases and shows detailedrequirements as hierarchical functional andnon-functional requirements.

may harm the users of a system, and the users of the sys-tem are already represented as actors in the use case model,we relate the hazard class with a target association to manyactors and, conversely, an actor may be the target of manyhazards. When identifying a hazard without finding any re-lated target actor, then either the use case model is incom-plete and needs to be refined, or the engineer has found ahazard that is orthogonal to the system, which indicates thatthe hazard is out of scope. In addition to the hazards target,any other entities from the problem domain (e.g. insurancecompany) may be involved with the hazard. Thus, the haz-ard may be related to many classes with an involved entityassociation.

A hazard may have many causes, which also have aunique name or id, a description, a likelihood attribute andan evaluation status. The evaluation status of a cause de-pends on its likelihood and on the hazard severity. It eitherindicates that mitigation of the hazard or cause is required,or the current state of the related hazard is acceptable. Thetarget actors of a hazard are injured when a cause of a haz-ard gets triggered. As the actors interaction is described bythe use case model, we relate the cause to the use case witha trigger association. In addition, a cause may be associatedwith many hazardous elements. Hazardous elements areany model elements that describe the system under devel-opment and which are involved in triggering the cause. Weuse the abstract super class System-Model-Element to rep-resent all possible model elements. For example, classes,components, controllers, or hardware nodes, which are real-izing or involved with the triggering use case, are hazardouselements to the cause.

If a hazard, including its causes, has an unacceptable risk


Figure 4. Shows the hazard analysis model including its associated classes from requirements, de-tailed requirements, and requirement analysis.

or severity, a mitigation of the hazard or/and the causes areneeded. Creating related requirements mitigates hazardsand causes. The requirements change the environment orthe circumstances of a hazard, so that either the severity ofthe hazard, or the likelihood of the cause is reduced. Weuse the association class Mitigation to relate the require-ments with the Hazard and Cause class. The mitigationhas a unique name or id, a description, a mitigation tech-nique and an evaluation status attribute. The evaluation sta-tus defines if the mitigation is accepted or not. Reviewswith many different stakeholders may be required before amitigation is accepted and result in changing the severity ofa hazard, or changing the likelihood of a cause. Figure 4shows the hazard analysis model as a UML class diagram.

6. Implementation

We implemented the proposed unified requirementsmodel in Sysiphus [16]. Sysiphus is a tool suite for devel-oping and collaborating on software engineering models indistributed environments. The key idea is the combination

and tight integration of system models, collaboration mod-els, and the organizational model of a software developmentproject within one single repository, accessible from dis-tributed sites. Sysiphus supports synchronous online accessto all types of models, enabling synchronous collaborationof teams from different site. For instance, distributed designreviews of class models are supported, in which all changesare propagated to all sites in real time. The implementa-tion of a model-based software configuration managementsystem supports offline workspaces and versioning for allmodels. For instance, requirements engineers can createand change requirements at client site, while being offline.Changes are merged back into the repository when gettingonline again.

All models are based on a common Sysiphus meta-model that provides generic and extensible mechanisms forpersistent storage, referencing, linking, filtering and accesscontrol. As all models extend the same meta model andare represented within one shared repository, traces betweendifferent types of models are no longer fragile, but are, infact, implicit in the modeling technique: changing a rela-


Figure 5. Shows the integration of the unified requirements model into the Sysiphus.

tionship in a view will change the underlying model, andany other views that show some or all of the artifacts willimmediately reflect the change.

System models are all software engineering artifacts thatdescribe the system under development. Thus, the imple-mentation of the proposed unified requirements model wasan extension of the existing Sysiphus system models. Themodel elements are organized and viewed in the context ofdocuments or as a result of filters. A document is definedin terms of sections and subsections, each containing text,diagrams, or a filter. The filter is used to attach matchingmodel elements to the sections. A filter is defined as a classof element (e.g., Use Case) and an optional number of prop-erty name and values (e.g., “priority = high” or “planned forrelease = 2”). Documents and filters are themselves modelelements that are stored in the shared repository and can becustomized for each project (see figure 5).

For example, a project may contain three documents: astakeholder requirements document, a requirements anal-ysis document, and a management document. The stake-holder requirements document contains all product features,use cases and actors, including diagrams. The requirementsanalysis document contains also all use cases and the com-plete analysis in terms of classes, sequence diagrams, etc.Changing a use case in the stakeholder requirements docu-ment will also change the use case of the analysis document,as they refer to the same object, filtered into the documents.Diagrams are also automatically updated, as they are justanother view of the model. Change impact can be analyzedby following the proposed traceability links into analysismodel. The management document may contain a sectionthat includes all high-priority use cases. When a new usecase is created, it appears in the requirements and analysisdocument. When the priority is changed from low to high,

the use case dynamically appears in the management docu-ment.

At the beginning of a project, an initial set of documents,consisting of the empty sections and their filters, enables atemplate-based development. They can be changed duringa project and may serve as new templates for subsequentprojects. To enable collaboration with external stakehold-ers, Sysiphus can export documents and filter results intofiles of different formats, such as PDF or RTF.

The collaboration model includes comments for infor-mal communication, an issue model for capturing rationalethat is based on QOC [11], and action items for managingwork items. The organizational model represents the projectin terms of teams and participants. All collaboration arti-facts are annotated directly on the system models, providingthe context of the collaboration. Traces across system mod-els, collaboration artifacts and their related organizationalunits are captured and maintained. Sysiphus enables infor-mal collaboration in distributed settings as shown in [5].

7. Conclusions

We propose the unified model as a new visual languagespecific to the domain of requirements engineering. Webelieve this approach can overcome some of the problemsinherent in using different teams and a variety of storagemedia to hold the requirements engineering work products.Specifically, we believe that this approach:

• Enables the viewing of complex relationships by mul-tiple teams

• Eliminates fragile traces that are intrinsic to the useof different media for storing work products (see fig-ure 6).


• Enables requirements review by allowing diversestakeholders to see all the necessary traces and arti-facts on easily understood views and

• Mitigates the problem of synchronization of artifacts(e.g. such as use cases and requirements) that arerecorded and managed using different tools.

Figure 6. Configuration management withtrace links.

8. Related Work

We have already done three pilots at Siemens that in-corporated non-functional and functional requirements intothe UML as profiles [2]. Both pilots were successful andshowed that we are on the right track. There is currently agreat deal of interest in integrating hazard and threat model-ing as UML profiles, however that does not go far enough.

During the requirements engineering effort on largeprojects we have experienced significant problems with theuse of different media for the storage of related materi-als, and have run into problems with synchronization andfragility when generating traces using third party tools thatstore the traces external to both the source and destination,essentially adding another storage media to the mix (fig-ure 6).

A new approach is needed (see our conclusions).

9. Future Work

Siemens has many projects where requirements engi-neering is done globally, sometimes across business units,sometimes across regions, and sometimes across both. Haz-ard analysis has been a key process for transportation andmedical systems. Threat modeling is important across a va-riety of domains, including medical, financial, etc. We are

hoping in the near future to do a pilot that incorporates fea-ture modeling, traditional requirements analysis, hazard andpossibly threat modeling, with the objective of finding tech-niques that are more productive than those currently in useand which scale with both product and organization size.

References

[1] R. Abbott. Program design by informal english description.Comm. of the ACM, 26(11):82–94, 1983.

[2] B. Berenbach and G. Borotto. Metrics for model drivenrequirements development. In ICSE ’06: Proceeding ofthe 28th international conference on Software engineering,pages 445–451, New York, NY, USA, 2006. ACM Press.

[3] B. Berenbach and M. Gall. Toward a unified model for re-quirements engineering. In Proceedings of the First Inter-national Conference on Global Software Engineering, pages237–238, 2006.

[4] B. Bruegge and A. H. Dutoit. Object-Oriented Software En-gineering Using UML, Patterns, and Java. Prentice Hall,Englewood Cliffs, NJ, second edition, Sep 2003.

[5] B. Bruegge, A. H. Dutoit, and T. Wolf. Sysiphus: Enablinginformal collaboration in global software development. InProceedings of the First International Conference on GlobalSoftware Engineering, October 2006.

[6] J. Dick. Design traceability. IEEE Software, 22(6):14–16,November/December 2005.

[7] O. Gotel and A. Finkelstein. An analysis of the require-ments traceability problem. In International Conference onRequirements Engineering, pages 94–101, Colorado, April1994. IEEE.

[8] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard.Object-Oriented Software Engineering – A Use Case DrivenApproach. Addison-Wesley, 1994.

[9] M. Jarke. Requirements tracing. Comm. ACM, 41(12):32–36, December 1998.

[10] K. C. Kang, S. G. Cohen, J. A.Hess, W. E. Novak, and A. S.Peterson. Feature-oriented domain analysis (foda) feasibil-ity study. Technical Report SEI-90-TR-21, CMU, 1990.

[11] A. MacLean, R. M. Young, V. M. Bellotti, and T. P. Moran.Questions, options, and criteria: Elements of design spaceanalysis. HCI, 6(3-4):201–250, 1991.

[12] Object Management Group, Inc. Unified Modeling Lan-guage Specification Version 2.0, May 2004.

[13] M. Riebisch, K. Bollert, D. Streitferdt, and I. Philippow. Ex-tending feature diagrams with uml multiplicities. In Pro-ceedings of the Sixth Conference on Integrated Design andProcess Technology (IDPT 2002), Pasadena, CA, June 2002.

[14] V. Vranic. Reconciling feature modeling: A feature model-ing metamodel. In Net.ObjectDays, pages 122–137, 2004.

[15] T. Wolf and A. H. Dutoit. A rationale-based analysis tool. InW. Dosch and N. Debnath, editors, Proceedings of the ISCA13th International Conference on Intelligent and AdaptiveSystems and Software Engineering (IASSE’04), pages 209–214. ISCA, July 2004.

[16] T. Wolf and A. H. Dutoit. Sysiphus athttp://sysiphus.in.tum.de, May 2005.
