Meta-Model and UML Profile for Requirements Management of Software and Embedded Systems

2.1. On UML Profiling for Prototyping a Meta-Model

It must be emphasized that there are several other ways of prototyping a meta-model as a tool. For example, Eclipse Graphical Modeling Framework (GMF) [9] provides a model-driven approach to generating graphical editors in Eclipse from a meta-model. The meta-model can be also implemented directly as a dedicated software program using a software programming language, such as Java. Our requirements management meta-model can be, and has been, implemented as a spreadsheet template in Microsoft Excel application.

The benefit of UML profiling is the fast and easy transformation of MOF meta-model into a deployable UML profile. This is because UML is defined with MOF [6]. Therefore, same UML tool can be used for defining them both. Furthermore, UML is a widely-adopted standard modeling language with extensive tool support. Yet, although UML profiles allow the reuse of tooling infrastructure the meta-model implementation may suffer from the limitations of the UML language itself. Nevertheless, UML profiling enables a cost-effective solution for prototyping a meta-model.

3.1. Recommendations for Requirements Management Process

The IEEE computer society's Guide to the Software Engineering Body of Knowledge gives recommendations on requirements management for software systems [10]. It defines the basic concepts and presents general guidelines for requirements management. It gives a detailed description of the phases of iterative requirements management process. Some of its core concepts are reused in this work. Other references on general requirement management of software systems include for example, [11, 12]. There are several proposals for proprietary requirements management templates and processes, such as [13, 14].

3.2. Meta-Models and UML Profiles for Requirements Management

Researchers have developed various meta-models and taxonomies for requirements management, each focusing on different aspects. Kabanda et al. [15] define a requirements meta-model for software systems that incorporates social features: users, policies, and culture. Firesmith [16] presents a detailed taxonomy for security-related requirements, and Glinz [17] focuses on nonfunctional requirements. Ramesh and Jarke [18] present reference models for requirements traceability based on focus groups and interviews conducted in 26 software development organizations. The synthesized models were validated with several case studies and incorporated in a number of commercial traceability tools.

SysML [19] is a standard UML profile that, among other things, defines model elements and a specialized diagram for documenting requirements. Models created with SysML can be also attached to other UML models that make it generic in nature. Berenbach and Gall [20] present UML stereotype extensions for integrating the modeling of functional and nonfunctional requirements as well as hazards in use case diagrams. Zhu and Gordon [21] propose a UML profile for modeling design decisions and an associated UML profile for modeling nonfunctional requirements. Pardillo et al. [22] present a meta-model and UML profile for measurable requirements that connect goals, requirements, and measures.

3.3. Summary of Related Work

The main contribution of this paper is the definition of a meta-model and UML profile for requirements management to be utilized in practical software and embedded system development which, among other things, incorporates the above-mentioned aspects.

5.1. Requirements and Their Properties

Figure 4 presents the main abstractions related to requirements. Requirement is a property that must be exhibited by a product, some of its part (e.g., subsystem, module), or its development process. Requirement has description, identifier, version, type, state, owner, and stakeholders as its attributes.

Description is a verbal expression of the requirement. The description should be expressed unambiguously and, if possible, quantitatively [10]. This concerns especially to nonfunctional requirements.

Identifier is a unique fingerprint of a requirement. It is used to separate a requirement from other requirements with a unique character string. On the other hand, a requirement may have several Versions. This is to track small changes of requirements after their first definition. Type classifies requirements to belong into certain category based on their nature. The possible categories have been defined in Figure 4 as an enumeration attribute. If the type of the requirement is Restriction, then its nature can be further refined with Restriction type.

State of a requirement is composed of four attributes that characterize its present status in the requirements management process. The first component is Conflict state. It defines whether the requirement has been analysed and if it is in conflict. Validation state defines whether the requirement has been validated. Authorization state determines whether the requirement is authorized for development. This attribute represents the final approval for committing resources to development in the context of a single requirement. The requirement can also be rejected. This means that it will not be considered in the development at all. Verification state defines whether the requirement has been verified after the development phase.

A requirement has also an owner and one or several stakeholders. Owner is an actor (person or company) who is responsible for the life span of the requirement. The owner takes care that the requirement is carried along the project and that the actions taken in the project comply with fulfilling the requirement. Stakeholder is an actor for whom the requirement is somehow meaningful. A stakeholder always gains or loses something based on the result of fulfilling the requirement.

Contracts are elements that bundle requirements together. A new contract typically brings new requirements to the product or development process.

5.2. Requirements Relationships

The network of requirements relationships is typically very complex in system design and the nature of the relationships may be ambiguous. However, it is important that the dependencies between requirements are identified and documented. This helps in later stages of development if requirements need to be changed. Changing a requirement may require that several other related requirements need to be reanalysed. Identification of the relationships helps to narrow down the number of requirements that need to be considered in requirement analysis due to a change in a requirement. We define three basic relationships between requirements which are composite, derive, and conflict. They are presented in Figure 5. All the basic relationships can be further refined with a free-form description to give additional semantics for them.

The composite relationship is used to decompose a complex requirement into several subrequirements. This allows to form requirement hierarchies. For example, composition can be used to divide responsibility of fulfilling a requirement between several design teams. The parent requirement is fulfilled after all its child requirements are fulfilled. The owner of requirement may change between hierarchy levels. This is to allow division of responsibility. The stakeholders are inherited from the upper levels of hierarchy to the lower ones while allowing to add new stakeholders to lower levels. The derive relationship can be used to express derivation dependencies between requirements. Derived requirements need to be reanalysed when the source requirement changes. Good example is a channel throughput requirement that is analysed to derive requirements for, data bus width in bits, data compression ratio, and max bit error rate (BER). The conflict relationship indicates that two or more requirements are in conflict which needs to be resolved before committing resources to development.

There is usually other information related to a requirement in addition to its textual description. We define three types of additional information. There are system models that refine the requirement describing how the requirement should be considered in the system. For example, a UML sequence diagram can be used to describe the protocol that refines the requirement "User must authenticate during login prior to usage of the service". In embedded system domain, the system models can be built using for example the standard profile for Modeling and Analysis of Real-Time Embedded system (MARTE) [24], profile for Schedulability, Performance and Time (SPT) [25], or some proprietary profile such as the TUT-Profile [26].

Verification models also refine requirements. They are blueprints of test benches which are used to verify that the particular requirement is met in the final implementation. Documentation is all other external documentation that is desired to be attached along with the requirement definition. For example, a processor data sheet can be attached to a requirement that restricts the underlying platform to utilize the particular processor core as its foundation. These abstract concepts and relationships allow attaching requirements and system models without binding to any specific modeling language.

5.3. Requirements and System Parameters

System parameter is a concept that models some feature or quantity of a product (e.g., power consumption, area, performance, etc.). A requirement then determines the possible values (or value boundaries) for such quantity.

Parameters help requirements engineers to piece together the relationships between requirements. In requirement elicitation, identifying system parameters and investigating their relationships is an efficient way of defining new relevant requirements.

System parameters are analysed to make early design decisions and validate requirements. As a result of the analysis, requirements are modified if it is observed that current requirements are not feasible to implement as such. In the final system, there will be some realized values for the defined parameters that are verified by measurements or some other observations.

A useful property for a requirement management tool is the capability to define such system parameters, their associations to requirements, and carry out at least simple calculations with them. More demanding analysis must be naturally separated to external analysis tools.

5.4. Allocating Requirements to Design Hierarchy

In a typical software and embedded system development, the requirements are refined and they become closer to actual design components when information in the project is increased. Various design decisions during the project lead into decomposition of the system into smaller and smaller components and modules that have their own specific requirements. This creates an evident need to allocate requirements to certain components in a design hierarchy.

For this purpose, the meta-model defines an abstraction called design part. Design parts can be hierarchical and requirements can be allocated to them. A requirement can have one of the three visibilities from the point of view of a design part: internal, external, and interface. Internal means that requirement is implementation-dependent and comes from the inside of the design part development. This is also called a white box requirement. External requirement comes from the outside. This is a requirement that the environment of the design part requires. This is also called a black box requirement. Interface requirement concerns the interface of the design part. This involves how the design part communicates with its surrounding environment and other design parts. It should be noted that a single requirement can be external for one design part and at the same time internal for another.

5.5. Requirements and Verification

5.6. Change Management and Change Sets

Change set is a temporal concept in requirements management process which contains a set of requirements needed to be changed for some common reason. The purpose of the change sets is to allow controlled change in requirements and allow tracking the changes later on by associating them to some specific goal.

Change set description defines the purpose of the changes to be made for the selected set of requirements. Change set state defines whether the change set is active, completed, or in planning state. In active state, the changes are currently being made for the defined set of requirements. The change sets in completed states should be archived for traceability of changes later on. Sets in planning states are yet to be made and thus still inactive.

There may be several change sets active at the same time, but careful consideration has to be carried out when two or more active change sets contain overlapping requirements. It is preferred that these kinds of overlapping change sets should be prohibited completely to avoid uncontrolled corruption of the requirements tree due to simultaneous change of same requirements for different goals in mind.

5.7. Development Process Related Abstractions

There are three fundamental abstractions that are related to requirements management but which are somewhat always dependent on the development process and project management. Their metrics may differ according to policies used by the organization. In the following, we provide examples of these possible metrics. They are presented in Figure 6.

Risk describes the possibility of the requirement not becoming fulfilled and estimated losses if the requirement fails. The losses can be economical, time, and failure-propagation to other requirements. Failure propagation can be presented by composite and derive relationships of requirements. If one of the child requirements fails, then the parent fails as well. If a derived requirement fails, it directly implies a failure in at least one of its source requirements.

Priority is a property of a requirement that characterizes its importance in the development. The priorities of requirements can be used as basis for setting priorities of project tasks. On the other hand, priorities can make the requirement analysis more complex as different stakeholders demand different priorities. The most simple prioritization is dividing requirements into mandatory and nice-to-have type of requirements. Other possibility is to use an integer value that represents the importance of the requirement in relation to other requirement.

Cost is a value that it takes individually to fulfill a requirement. Good quantities for characterizing cost are additional money and time. It should be noted that some requirements may have divided costs since two requirements may always share the same investments and project tasks. These are always development process-dependent and need to be considered in requirement-by-requirement basis.

5.8. Product Families, Products, Variants, and Configurations

The meta-model also considers the hierarchy of products and their variants in product families. From requirements management perspective, the idea is to identify and reuse the requirements between products in product families as well as between different product variants. The meta-model related to this classification is presented in Figure 7. Product is the basic item which is a result of the development effort that satisfies customers' needs. Product family is a set of different products sharing certain common features. The definition of product families is highly organization and domain specific. For example, it can depend on similar design and production techniques, common features, or common implementation platform. Product variant is a parallel development path or customization of a product. For instance, a color camera and black-and-white camera can be tailored from the same basic product components and requirements, but ultimately lead to different variants. Product configuration is a combination of a variant and its version.

6.1. Profile Definition

Figure 8 illustrates how the profile is constructed with stereotype extensions. Only three stereotypes are shown in the figure for simplicity. The stereotypes and their attributes correspond to abstractions of the meta-model presented in the previous section. Other stereotypes are similarly derived.

In the figure, it is shown how Requirement stereotype extends UML meta-class Classifier. Other model elements, except relationships, are also extensions of a classifier. This means that the stereotype can be applied to any UML classifier element (class, use case, actor, etc.). The resulting model element can be adopted in diagrams where the concerned classifier is allowed. This increases the flexibility of adopting the profile.

The requirement stereotype contains string type attributes for description, version, ID, authorization date, and cost. Thus, they can be typed by the modeler in free-form textual notation. Authorizators and owners are also stereotype attributes. They become selectable from the list of all defined actors (companies and persons). The enumeration attributes are attached to the stereotype the same way as in the meta-model. In the figure, only analysation state is shown for simplicity, other state-related attributes are defined in a similar manner. For a designer, these attributes are defined from a pull-down menu where the value can be selected from a set of allowed values. This forces the modeler to use only legal values and thus reduces errors in model construction if compared to free-form textual input. The icon shown in top right corner of the stereotype box is the unique symbol used for requirements in diagrams. Similarly, other stereotypes have their own defined symbols.

Figure 8 also shows stereotype extensions for Derive and Stakeholder relationships. Both extend the meta-class Dependency. The stakeholders are exceptionally defined with special relationship that is used to bind actors to requirements instead of being directly defined as an attribute of a requirement (as in the case of owners). This allows better emphasis in diagrams on how stakeholders request requirements. This is reasonable, because stakeholders are inherited to lower level requirements in the hierarchy, whereas owners and authorizators can change arbitrarily between requirement and its subrequirements. The stakeholder relationship has also an attribute description, that is used to explain the intentions of the stakeholder for the particular requirement. This is another reason for using a special relationship. Other relationship stereotypes are defined so that unidirectional relationships extend UML dependency (stakeholder, derive, refine), whereas bidirectional relationships extend UML association (composite and conflict).

6.2. Tool Customization

Figure 9 illustrates the customization of the stereotypes shown in Figure 8. A similar kind of customization is performed for the rest of the stereotypes. The customization is performed by defining tagged values of the stereotype Customization. This stereotype is tool specific and it is interpreted by the MagicDraw DSL engine. The customization target attribute is used to define the elements the particular customization is applied to. The requirement element is customized so that only certain relationships for it are allowed.

Further, the relationship elements are tailored by defining which types of elements they can connect. This is defined with types of source and types of target attributes. For example, the stakeholder relationship can only connect a company or person to a requirement, whereas derive relationship can be only established between two requirements. The DSL engine takes into account these rules during model building by preventing forming illegal relationships.

Other approach for this type of constraining would be to use a separate constraining language such as OCL. Such approach would be more portable. However, for our prototyping purposes the tool-specific constraining is sufficient.