This section presents our meta-model for requirements management. The meta-model is depicted by the class diagrams presented in Figures 4–7. In the following, each element of the meta-model is discussed separately.
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.
The system parameters have the following attributes in the meta-model.
-
(i)
Freeform description of the parameter.
-
(ii)
Unit of measurement (e.g., watt, meter, kilogram, etc.) in case the parameter is quantifiable.
-
(iii)
Equations describing parameter's relations to other system parameters.
-
(iv)
Estimated value is a value assigned for analysis. It can be based on engineer's best guess, previous knowledge, datasheets, or measurements from prototype.
-
(v)
Realized value is the actual value of the parameter in the implementation. This value is compared to requirements in the verification phase.
-
(vi)
Visibility, that is, whether the property is a user parameter or system parameter. User parameter is a feature that is visible to product user (external property) and system parameter is an internal property shown only for the developer. Typically user properties (and requirements) are used to derive system properties (and requirements).
-
(vii)
Relation defines association to other system parameter. It is a directed relationship that indicates how increasing the value of a parameter affects the other parameter. It can either increase or decrease it. The intensity can be additive, linear, polynomial, or exponential.
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
Verification is closely related to requirements management. Tests are the main vehicle for verifying requirements. We prefer that tests are tracked together with requirements, but they should be separated to different logical trees. These trees are then linked together with relationships. There may be several tests for one requirement and one test can be a part of verifying several requirements. Tests have the following attributes.
-
(i)
Description: a free-form description of the test.
-
(ii)
Owner: actor responsible of the test in the test tree. This role is not necessarily responsible of conducting the actual test event but definition and change of it during product development (similar to requirement owner).
-
(iii)
Test objectives: clearly stated objectives for the test. Which requirements and which aspects of them the test is verifying.
-
(iv)
Test methods: description of the methods that are used in testing. This includes describing the test process phases, used measurement techniques and tools.
-
(v)
Technical details: defines notes and possible restrictions of the used testing methods.
One test can have several test events. These are instances of test and they must be planned and recorded during the product development. The attributes of a test event are as follows.
-
(i)
Description: short description of the test event.
-
(ii)
Tester: actor responsible for conducting the test.
-
(iii)
Deadline date: date when the test must be (or should have been) taken place.
-
(iv)
Testing date: actual testing date or planned testing date.
-
(v)
Test report: external documentation that reports the testing event process and results of the test event.
-
(vi)
Test result: according to test event, the test can be passed, failed or pending.
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.
