Requirements Abstraction Model

Abstract:

Software requirements arrive in different shapes and forms to development organizations. This is particularly the case in market-driven requirements engineering, where the requirements are on products rather than directed towards projects. This result in challenges related to making different requirements comparable. In particular, this situation was identified in a collaborative effort between academia and industry. A model, with four abstraction levels, was developed as a response to the industrial need. The model allows for placement of requirements on different levels, and it supports abstraction or break down of requirements to make them comparable to each other. The model was successfully validated in several steps at a company. The results from the industrial validation point to the usefulness of the model. The model will allow companies to ensure comparability between requirements, and hence it generates important input to activities such as prioritization and packaging of requirements before launching a development project.

Introduction:

Market driven incremental product development and delivery (release) is becoming increasingly commonplace in software industry [1, 2]. Incremental product development is planned and executed with the goal of delivering an optimal subset of requirements in a certain release (version of a product that is distributed to customers) [3]. The idea is to select what a release should contain (requirements), when it should be released (time), and at what cost (pertaining to the resources needed designing and implementing a requirement) this should be achieved.

The decision about which customers get what features and quality at what point in time has to be taken, i.e. making these activities a major determinant of the success of a product [4]. All activities described above, i.e. establishing what should be included in a release, when it should be released and at what cost, are vitally dependent on the product requirements and that they are elicited/caught, analyzed, and specified before any planning and development activity can commence.

The situation is far more complex than the one presented by the classical bespoke [3] development situation where elicitation could be targeted and concentrated mainly to the customer organization and stakeholders identified there. The development activity was initiated by e.g. an order, which generally resulted in a project (maybe preceded by a pre-study) and then requirements engineering was initiated through this project.

Requirement’s Role in the Development Process:

As illustrated in Figure 1, the situation in a market driven development situation is different since the requirements flow is not limited to a development instance (e.g. a project), but rather continuous in nature, and the requirements themselves should act as the catalyst for initiating development. In market driven development requirements are generally generated by multiple sources, both internal (e.g. engineers to management) and external (e.g. customers and partners). It can be everything from direct requests for added functionality from existing and/or potential customers to updates proposed by engineers working on the product.

In addition, indirect requirements need to be caught. This can be everything from idea-like requirements caught by the marketing department during a competitor analysis or a market survey, to information gathered during product support and conveyed internally. As the sources of the requirements vary and the requirements themselves are both direct and indirect in nature it is not surprising that they come in different shapes and forms, at multiple levels of abstraction, and described on varying levels of refinement.

In Figure 1 this is depicted as requirements initiated development, where all these types of requirements are input to a requirements engineering process which has the capability of performing the needed refinement, analysis and negotiation, producing good-enough requirements to initiate and drive development activities (e.g. projects) in an continuous manner, i.e. development is initiated when the requirements warrant it.

The market driven product development situation described above was identified during a cooperative software process improvement (SPI) venture in industry, performed at Danaher Motion Särö AB (DHR). There was a need for adapting requirements engineering at DHR to a continuous process, moving from traditional project initiated requirements engineering to requirements initiated development. This involved not only creating a new way of working (e.g. how to specify requirements, what roles and responsibilities should be present etc), but also a new way of thinking (e.g. that requirements are the basis for product development).

The Product Managers (the ones charged with implementing the new way of working) were faced with the challenge of how to take care of the continuous incoming stream of requirements ranging from abstract to technically detailed. Based on this problem the Requirements Abstraction Model was developed. This paper presents the Requirements Abstraction Model (RAM), how it was created in close cooperation with industry, and validated through feedback from professionals as well as how it was tested in a live project.

Although, the model was developed based on needs identified at DHR, the objective was for the model to be generally usable, i.e. the aim of RAM was to give professionals working with product planning/development (e.g. Product Managers) a requirements engineering model that help them in their work. To this end RAM is modeled towards a product perspective, supporting a continuous requirement engineering effort, aimed at taking requirements of multiple types (abstraction level) as input, and offer a structure for the work-up of these requirements, i.e. breaking down abstract requirements into detailed ones, and vice-versa (see Section 4.3).

The benefits of using RAM as a support in product centered continuous requirements engineering can be summarized in four bullets.

• (I) All requirements are compared to the product strategies, offering an assurance that requirements do not violate the overall goals set by management. This offers the possibility to dismiss requirements early in the process, freeing up resources to work on/refine relevant requirements that are in line with the product strategies.
• (II) All requirements are broken down to an abstraction level where they are good-enough for initiating a development effort (project). This assures that the projects (whose aim it is to realize the requirements) get good-enough requirements to base their development efforts on (e.g. testable and unambiguous).
• (III) Work-up of requirements means that they are formulated on the same level of abstraction, and hence they can be compared and set against one another. The ability to compare requirements is a prerequisite to effective release planning and prioritization.
• (IV) All requirements can be followed through several levels of abstraction giving a richer understanding of each requirement, and thus better decision support can be obtained for all professionals, from management to developers.

The paper is outlined as follows. Section 2 offers an overview of related work. In Section 3 the background and motivation is presented, along with how it relates to both DHR and the general industry case. Section 4 offers an introduction and exemplification of the Requirements Abstraction Model (RAM), and Section 5 presents how RAM was evaluated through static and dynamic validation. Section 6 presents the Conclusions.

Conclusions:

The Requirements Abstraction Model was developed in response to direct needs identified in industry, and the lack of an appropriate model to address these needs. The goal was to offer Product Managers a model supporting the ability to handle and work with requirements on multiple levels of abstraction in a continuous product centered requirements engineering effort. This meant going from e.g. one repository where all requirements were kept, regardless of abstraction level, to a structure mirroring the reality of the requirements coming in. RAM enforces work-up rules that abstracts and breaks down requirements as needed, offering requirements on several levels of abstraction reflecting the needs of a development organization.

Product Level requirements can be compared to product strategies, in an attempt to dismiss out of scope requirements at an early stage. Function and Component Level requirements (needed for project initiation) effectively assure that developers are not burdened with requirements too abstract for development. In addition, working with the model gave a homogeneous refinement and analysis of requirements, and the effect that several issues, normally left to projects, were caught early on. This mitigating the risk of some problems creeping into development, and thus caught only after the development effort (e.g. project) was planned and initiated.

As requirements engineering is an integrated part of development the effective use of RAM is dependent on certain infrastructure being in place, this pertains mainly to explicitly formulated product strategies, which existence cannot be taken for granted.

As parts of the benefit is dependent on this fact it could be considered a drawback, however it should also be noted that the abstraction of requirements can trigger explicit questions, challenging management to refine product goals and strategies to reflect the needs of the development organization. All parties working with development (management in particular) can compare requirements, as they are homogenous regarding abstraction level, and are not forced to decide between an abstract requirement and a detailed one as e.g. planning and prioritization activities are performed.

As a part of its development, RAM was validated in industry through both static validations, giving feedback from professionals working with requirements engineering and product development, and through dynamic validation, giving a real live test-run of the model. The validations were performed to assure that the model complied with the needs of industry. During the validations it was ascertained that requirements did come in on different levels of abstraction, and that specification, placement, and work-up were feasible in a real live requirements engineering situation. The usability of the model was premiered in its development, and was partly assured during the static validation, and tested during the dynamic validation.

As RAM is not prescriptive in nature, but rather adaptable and example-driven, tailoring towards a product (or organization) may be required prior to use in order to develop support materials like guides and relevant examples. The main stakeholder pertaining to the model is the Requirements Manager (e.g. a Product Manager), and as the model should be tailored to support the work performed, the work performed must adhere to work-up rules, but also the consistency regarding abstraction levels is critical and how requirements are handled in relation to these rules. The main point is not having a certain requirement of a certain abstraction on a particular level, but rather having all requirements of a certain abstraction on the same level. This (i.e. adequate usage of the model) is obtained through supporting users with guides, relevant examples, and explicitly formulated product strategies, but also through training in model usage prior and during model implementation in an organization. Issues such as the number of abstraction levels needed is up to the organization in question and their particular case, and is a part of the tailoring.

Requirements specified using RAM were based on attributes validated against industry professionals, and were considered adequate in amount and detail pertaining to fulfilling the functions needed. The usability was premiered in the models development, but not at the expense of substantially lowering the quality of the requirements produced. This was assured through the validity reviews performed.

As stated earlier, RAM presented in this paper was designed with Product Managers in mind, supporting them in their requirements engineering effort producing requirements good-enough for planning activities, giving detailed abstraction as well as a big picture view. However, it was also developed with engineers (developers) in mind, controlling the abstraction level and refinement of requirements handed over to projects. The motivation for RAM was to address needs identified at DHR, these same needs that were later also confirmed by a second (independent) development organization, and their explicit interest in tailoring RAM to their products.

The non-prescriptive, adaptable nature of the model is based on the assumption that a perfect model and way of working cannot be specified, not even for one organization with homogenous products, since the products and needs of the organization may change over time. RAM can be tailored to satisfy the needs of different organizations and products. In the same way, it can be modified over time to reflect the current situation of a development organization, supporting the collection of requirements over time and product life cycle.