|
|
|
|
The SACHER approach to requirements management The SACHER team, c/o CEFRIEL - Politecnico di Milano
Via Fucini, 2 20133 Milano (Italy) e-mail: lavazza@cefriel.it phone: +39-02-23954258
Abstract The effective management of user requirements is of vital importance for any software development process. This activity spans from software procurement to project management, to the technical development activities. The aim of the SACHER project is to increase the efficiency of requirement management (and particularly requirement change management) in software development and maintenance. In particular, the SACHER project aims at enabling or improving the estimation of both technical and managerial consequences of given requirements (changes), and at defining and supporting an innovative approach to contract definition in software procurement. The fundamental idea of SACHER is that the software process and product can be modelled and quantitatively characterised through proper measurement, in order to provide a sound basis for different kinds of analysis, including cost estimation, change impact and sensitivity analysis. Introduction Most industrial software-intensive systems are affected by unavoidable requirements changes, that —occurring in any phase of the software lifecycle— have strong impacts on technical and organisational issues of software project management. Requirement specification and customer requirements management are the subject of requirements engineering [7]. However, requirement changes acquire particular relevance in software procurement, for both the procurer and the supplier (respectively the software end-users and the software producers). Procurers look for effective management of contractual practices, by quantifying clauses in the contracts and then assessing their accomplishment. Suppliers have in requirement management the key factor for customer management and business success, but they still lack the ability to estimate and control supply costs and this is often the main reason of supply failures. The SACHER (Sensitivity Analysis and CHange management support for Evolving Requirements) ESPRIT Project is based on the idea that requirement change management is a key factor for successful cost-effective software development, and aims at:
The SACHER approach involves conceptual modelling of the software product and process in order to identify and maintain the traceability relations that allow impact analysis. Cost functions are defined for the process activities —according to the process model— and the parameters of these cost functions are evaluated and tuned through measurement. The main project results will consist of the SACHER tool-set, supporting requirement change management through impact analysis, cost evaluation and cost sensitivity analysis, and the SACHER methodology, positioning the SACHER requirement management approach within a software process viewpoint and introducing a modern software procurement practice. The project is still in its initial phase, having completed the user needs analysis, and is currently working at the definition of the conceptual framework for the SACHER methodology and tool-set. The rest of the paper is structured as follows: Section 2 describes the SACHER approach in general, Section 3 reports about the SACHER methodology, while in Section 4 an operating scenario is described. The final section draws some conclusions and outlines the future evolution of the project. The SACHER approach The macro-objectives described in the introduction map onto the following concrete objectives of the SACHER project:
The aforementioned achievements will be exploited in the definition of the following techniques to support the software procurement process:
Expected project results are:
The SACHER approach considers the software lifecycle and its products and, focusing on requirements, it concentrates on requirement changes which may occur during the development. Change requirements management is conceived as a sequence of steps, listed hereby:
The SACHER approach to change management is also a way to define a new software procurement process, based on requirements, as explained in the following sections. Product modelling The "reasoning" capabilities of SACHER will be based on the model of the product being considered.
Figure 1: High-level view of the product model. A very simplified view of the product model is reported in Fig. 1. The product model includes both the product requirements and the artifacts (i.e. design documents, code, test plans, testing reports, user manuals, etc.) that are developed in order to build the required software system. It also represents the relationships which link requirements to artifacts, thus providing the traceability information which is needed to perform change impact and other types of analysis concerning the characteristics of changes. There are a few important observations that are worth reporting:
The product model is described by means of the UML [5] notation. Figure 2 reports a simplified example of part of the product model. In particular, Figure 2 is centred around the concept of feature. Feature engineering [6] makes requirements documentation more useful, by modularising requirements into coherent features. This allows to propagate the packaged results of requirement analysis to the other life-cycle activities in a disciplined way. From the SACHER point of view, the variable abstraction level of features brings a relevant benefit. In fact, in order to assess the impact of a change, it is clear that the more precise the description of the existing requirements and of the change, the more precise the assessment. In particular, it is important that artifacts are linked to requirements at the correct granularity level. For instance, in a CAD system, a change could concern the polygon drawing features (which are a proper subset of the global drawing features): the proper decomposition of features in sub-features at various granularity levels will allow to identify the artifacts that depend only on the polygon drawing features (excluding artifacts which are devoted to drawing, but not to polygon drawing). On the other hand, the possibility of viewing features at different levels allows to express comprehensive changes. For instance, the request to change the language of the user interface is attached to the user interface feature, and affects all its parts. The high degree of traceabily allowed by the features is also a prerequisite for impact analysis.
Figure 2: UML model of artifacts. The model of the artifacts reported in Figure 2 is absolutely generic, and needs to be properly refined, if precise analysis has to be performed. For instance, if the product is developed according to object-oriented techniques, the "Module" described in Figure 2 will be modelled as a cluster of classes, which will be interconnected by relationships like usage, specialisation, aggregation. The process model The cost of changes is not determined simply by the kind of change and by the type of artifact changed. On the contrary, it depends mainly on which activities are carried out in order to accomplish the change, and how these activities are performed. Therefore, a process model is also needed. The process model will not need to be too detailed (for instance, we do not need dynamic —or control— information). In practice we need to know how the process is organized into activities. For each activities we shall give:
A data-flow model expressed by means of the IDEF0 notation [1], like the one reported in Figure 3, is a good starting point. In order to perform impact analysis, the description of the activities has to be enhanced with the indication of which subset of the outputs depend on which subset of the input flows, in which conditions.
Figure 3: Sample IDEF0 model of a process fragment. The interesting characteristics of the process model are that:
The following observations apply:
Requirement change impact evaluation When a potential requirement change occurs, the impact evaluation is performed, with respect to both technical artifacts and managerial ones. The impact of requirement changes is evaluated by the system depending on:
For instance, if the system is informed that requirement X will be updated, and X is a requirement of type C, then the system will compute the set of activities that in the current situation will manage an input of type C. In general, the computation will not be fully automated, since the user intervention could be needed to make choices among possible ways of carrying out the change. Cost assessment The cost of a change is a function of the computed impact. When the set of changes is known, and the activities that will accomplish those changes is known as well, it is sufficient to apply the cost function to each activity and sum the partial costs. The cost function will simply assign a cost to an activity on the basis of:
Clearly it could be the case that no data are available for the specific conditions specified (e.g., it is the first time that a relevant change is made on a big piece of complex code using a given tool). In these cases the user could be asked to supply the cost parameters according to his own estimate. Derivation of cost parameters through measurement A methodology is required to estimate cost data in a reliable way. GQM [2] will be used to determine a set of metrics for evaluating the development process and product characteristics, together with factors influencing them. During the SACHER project, relevant metrics on ongoing software development processes will be gathered, and the knowledge database for cost evaluation will be populated. The choice of GQM descends from the familiarity of consortium members with the method, and from the availability of the GQM-Tool supporting the method. The definition of the metrics relies on the process model. In fact, measurement aims at characterising quantitatively every activity. For instance, consider the activity of changing a piece of code, as described in Figure 3. The cost depends on:
The SACHER methodology will contain a customisable version of the GQM plans (i.e., metrics definitions) developed within the projects. Together with the plans, SACHER will also provide the data collected by the pilot projects. However, as mentioned before, the definition and results of metrics are strictly dependent on the underlying process. SACHER users should thus carefully adapt the metrics definitions, and selectively apply the available results, according to their own process. Architecture The SACHER project will extend an existing tool for requirement management. In particular, the original tool will be enhanced by means of:
The measurement tool and the metrics database will be separate. The cost function parameters will be extracted from the database through suitable queries and fed to the SACHER tool. The SACHER methodology The SACHER requirement change management represents also a mean to support a new approach to software procurement, in the initial contractual phases, during potential contract revisions and at supply acceptance, allowing:
The SACHER methodology will provide guidelines on these issues. The SACHER methodology will give guidelines on the SACHER approach and on how to adopt this technology in order to achieve effective requirement management within the software development process and the software procurement process. The need for providing a methodological support to the tool users and for positioning SACHER within a process view descends from these observations:
The SACHER methodology addresses three different levels of detail:
A specific part of the methodology concerns the quick start. In fact, in order to use SACHER at its best, the user should first customise it, as described above. This might be a long process, therefore we provide guidelines for a quick start. These include high-level modelling of the process and product, in order to have only a few coarse-grain parameters to insert in SACHER, possibly consistent with popular methods, like COCOMO [4]. The SACHER scenario The SACHER scenario is represented in Figure 4, where thin lines represent data flow and thick lines represent logical correspondence.
Figure 4: The SACHER system. The scenario described in Figure 4 has to be interpreted as follows:
Note that the above scenario is only a partial example of the usage of SACHER. In fact, this example does not show how the information produced by the system is used in the procurer-supplier negotiation. Moreover, the cost evaluation part is optional: the user could employ SACHER just to estimate the impact of changes from a technical point of view. Different kinds of analysis (not necessary related to efforts and costs) can be defined on top of the SACHER models: for instance, the user could assess the impact of a requirement change on the architecture of the system. Finally, it is interesting to note that SACHER can be applied not just to changes in requirements of existing products, but also to new developments,. In fact, the difference between the two cases is that in the former the artifacts were built when implementing the original requirements, while in the latter they do not exist. This is not a big problem, since SACHER reasons on product and process models, not on the real artifacts. In order to apply SACHER, it is thus only necessary to supply it with the model of the to-be artifacts. This activity can be integrated within the regular development process, since the models developed for use by SACHER can be refined and become the real software artifacts. In any case, it is also possible to keep the SACHER models at a high level of abstraction, thus minimising the effort devoted to defining them. Conclusion and future work The SACHER project is an ambitious attempt to manage software requirements, and especially requirements changes, in an innovative way. The SACHER approach aims at using objective and reliable models to reason on software development corresponding to new requirements or to changes in the requirements of existing or under-construction products. Therefore, this approach implies the integration of product modelling techniques, process modelling techniques, requirement representation and management techniques, and measurement definition, collection and analysis techniques. The SACHER project is now in its initial phase. The project is expected to finish in October 1999. Up to now, some fundamental choices have been made. In particular, the main characteristics and objectives of the product and process models have been identified. The user needs have been explored, and the specifications of the SACHER tool-set are being written. The implementation of the SACHER tool-set will start in May 1998, and will provide a first prototype in October 1998. This prototype will be available to SACHER partners for carrying out pilot projects, which will provide feedback for further developments and refinements of the tool-set. References
|
