The user requirements elicitation and specification process: Deployment experience of CSELT DOMINO 2.0 methodology
Antonella Bartocci, Marina Melchioni CSELT, Via Reiss Romoli 274 10148 Torino, Italy antonella.bartocci@cselt.it
About CSELT ..
CSELT, founded in 1964, is the Telecom Italia Group's Company for study, research, experimentation and qualification in the field of telecommunications and information technology. The Center has the technical know-how for the principal activities of the Telecom Italia Group and applies them in the research for new services, advanced applications and integrated solutions, working mainly according to the view of an Operating Company. CSELT contributes to the study of advanced systemistic scenarios, plays a link role between academic and applied research, thanks to its strong presence in the international context, becoming reality through the participation in common research programs and standardization activities. CSELT's lab constitute a reference point for both feasibility and integration studies, development and experimentation of advanced solutions, evaluation and qualification of products and processes, demonstration of innovative services. Furthermore, great attention is paid on in-field systems experimentation, especially in those areas where innovation can be applied in a short-medium time scale.
.. and the Telecommunication Industries
Telecommunication industries are evolving rapidly and changes are often unpredictable: liberalisation and competition put stronger constraints on the time-to-market requirements for faster service delivery. At the same time, these new services are requested to be customisable on one side, and to realise easy and secure access to shared information, on the other side, increasing the use of network resources. All such "environmental" changes require software systems to become always more flexible and integrated with one another. Consequently, complexity of telecommunication applications is always growing: the requested functionalities are increasing in number and they must often be provided by etherogeneous systems. To build an application, especially if it is distributed, it really becomes necessary to be supported by ‘a good set of rules’ useful to formalize the process of user requirements capture (elicitation and engineering) and for the corresponding development. This is in order to gain control over developing ‘the right system’, according to the customer needs (it’s important to get all requirements and to get them right as early as possible in the software life cycle): in other words, the availability of a methodology useful in gaining control over the complexity of a certain application problem becomes necessary, allowing to analyse it according to different levels of detail, according to different points of view, according to the customer feedback, so that the entire software project management becomes more systematic.
CSELT was originally a center for the medium-long term research while lately the market trend has become such that it has become more focused and tightly drived by its customer specific needs, on tightest time schedules. Typically today our projects are such that we often act as software suppliers towards our customer without actually being completely a software house ourselves, nor do we have such a mandate. In fact, very often we realize our customer software applications either by outsourcing some part (or even all) of the software development or by buying some kind of specific software development consultancy from some external software house. This is the basic reason why historically we have never needed a corporate approach for managing a software project and why we’ve been gradually changing direction over the last years.
The new trend, previously described in the Introduction for telecommunication industries, is quite challenging for CSELT and it has determined for us quite a radical change since our major software projects now have become more focused and finalized to delivery on a short-to-medium time scale, also changing our ‘traditional’ way of managing relations with our customers. We are often being commissioned to deliver software applications dealing through its entire software life cycle process, that is, starting from understanding user requirements and going through to software delivery, maintenance and evolution, and (in some cases) also through providing some operational user support.
Our customer’s organizational and competitive environment typically change very rapidly and they may impact on some (or all) of the needs previously defined for a certain software system. Also, our customer seldom is able to define specific requirements precisely since he is obviously mainly aware of the major, very high level needs that need to be solved urgently by the software system. While this in the past was not much of a problem, since there was ‘plenty’ of time to understand explicitly all user requirements, to study and experiment different alternatives and different technical solutions, nowadays this is no longer affordable.
Another somewhat critical issue that we are facing lately is that often we acquire software development consultancy from external software houses, and it happens that some consultants leave before the project has come to its end, meaning that we have to manage such turn-overs, and the difficulties of reducing the cost of coping with them may be enhanced by defining some ‘good organizational practices’ that all software projects should follow.
As a matter of fact, all these ‘environmental’ changes are quite challenging for CSELT and to pursue specific quality objectives our company adopted the ISO9001 model, obtaining this certification two years ago. Furthermore, to better understand and focus on processes and activities to improve, and for the reasons just mentioned, concerning the area of software project management, a specific project team has been set up whose tasks can be mapped on the KPAs (Key Process Areas) of CMM level 2 [1]; among these internal processes there is also user requirements management (other issues considered by this team are concerned with: configuration management, testing, software project management, external software suppliers rating and management).
CSELT DOMINO 2.0: what is it and how it was developed
CSELT DOMINO 2.0 is a methodology originally developed to cover, in CSELT’s software projects, the user requirements specification and the software requirements specification phases ([4], [5]).
CSELT’s need was to define a corporate process to provide a common way for people in a project team to perform the same actions in the same order, for making the same kind of choices, for producing the same documents in certain times, and so on. Also, the need was for a process that is a systematic way for operating in a repeatable manner (i.e., stable) and a common definition of the documents to be produced (contents + structure). The need was also to increase control over the software to be developed starting from the specification phase and to use "a tool" for representing information in a rather rigorous way, reducing ambiguity, redundancy and incomplete coverage of user requirements.
Furthermore CSELT’s objectives were to develop a methodology supporting requirements elicitation and engineering in order to produce verifiable specifications, with least ambiguities, increasing completeness and augmenting characteristics such as consistency, modifiability and traceability. Among the objectives there was also the need to support requirements analysis for service oriented systems, in order to define an application as a set of components, to clearly define the application interfaces and to define a first draft of the application architecture. This kind of approach should have augmented software and specifications reuse.
With this set of requirements, the approach adopted was to go for an object-oriented based methodology, looking at the de facto standard techniques of that time (mostly Jacobson [6], Rumbaugh [7] and Booch [8]) and to merge and customize these approaches according to CSELT specific needs. As a matter of fact, these OO methodologies were not found completely adequate for our purposes, since for our software projects we had the specific requisite to provide support starting from the very initial activities of the analysis phase, while those OO methodologies provided good modelling techniques mostly for performing detailed analysis. For historical reasons, as mentioned above, not every department in CSELT is familiar with the main acitivities of a software life cycle, so people are generally not used to specific tasks such as capturing and documenting user requirements, making explicit all implicit requirements, then tracing them through the testing phase, and so on. Moreover, people are generally not aware about all the possible different types of user requirements they should capture, so our urgent need was for a methodology providing guidelines for assuring an exhaustive coverage of user requirements starting from considering the application from the external users point of view. In [6] the Use Case technique was found useful but not enough powerful to provide such support so we introduced a model also inspired by domain analysis for performing the first steps of the user requirements capture activity, which is CSELT DOMINO 2.0 main focus (starting from the user requirements specification developed applying our methodology it is possible to perform detailed analysis and design using a specific object-oriented methodology, or even a different kind of methodology).
Additional general characteristics of DOMINO 2.0 are the fact that it supports an iterative and incremental life cycle and that its architectural framework refers to OSCA [9] and TINA [10] approaches, meaning that it provides guidelines supporting design separation of user interface specific aspects from application logic aspects and from data management aspects (in OSCA these were called user interface-layer, process-layer and data-layer): making design decisions keeping them separated provides advantages for the later activities in the software life-cycle (e.g., maintanance).
Briefly, DOMINO 2.0 is structured as follows (see Figure 1): it is organized in two main phases, User Requirements Specification and Software Requirements Specification. Each phase is then organized in a set of tasks, and for each task we have defined its activities, its inputs and outputs. For each activity DOMINO 2.0 provides a set of guidelines and modelling techniques to perform the task and to produce its associated output information. For the entire process DOMINO 2.0 provides a pre-defined set of templates, customizable, to structure information in the User Requirements Specification and to uniquely identify requirements.
Since CSELT experience is such that software is mostly outsourced (especially for medium-big sized products) we have so far been able to apply mainly the first phase of DOMINO 2.0 so this paper is focused on it.
Fig. BARTOCCI.1: CSELT DOMINO 2.0 for User and Software Requirements Specification tasks.
In DOMINO 2.0 the user requirements specification phase is structured in two tasks:
The goals of this task are mainly to provide a definition of what the application should and should not do, of the relationships/interactions taking place between the application and the entities identified in its external environment (or ‘context’), of its main services and a sketch of the application (and service) components.
The modelling techniques used in this task were partly inspired by domain analysis and, in DOMINO 2.0, they are called: context model (one diagram for the entire application: it defines the application boundaries, the external entities and the interactions taking place among them. This new modelling technique was developed and introduced in DOMINO since the Use Case model resulted to be less rich of semantic information useful at this point to depict the application characteristic in one diagram and from the external users point of view, functional structure model (one diagram for the entire application: it defines the application basic processing components, through a functional decomposition structure; the leaves of the graph in DOMINO 2.0 are called ‘process macro-elements’), and macro-elements model (one diagram for each application service: it combines the external and the internal functional views, i.e., the two preceding models, providing the initial architectural definition for the application. This model defines which process macro-elements are used to realize the service considered and it also defines which kind of interface macro-elements are needed. In DOMINO 2.0 there are three types of interface macro-elemnts, one for each possible type of external entity: human user, database and network element). DOMINO 2.0 also strongly supports use of scenarios to identify and characterize relationships between the application and the external entities in its environment and the application services.
This task produces as main output the application scope definition, an overview of its identified services and the identification of the application increments and releases.
The goals of this task are mainly to capture and formalize: the application behavior for each application service, the application non functional requirements and the services and macro-elements functional and non-functional requirements.
This task usually drives back to the previous one in a refinement process, so the modelling techniques are the same. The requirements formalization activities performed in this task are supported by introducing a template with specific fields (customizable to some extent) and numbering rules providing unique identification of each single user requirement. This formalization scheme was introduced to support features such as requirements classification of importance, verifiability, modifiability and traceability. This task produces as output the functional and non-functional user requirements definition (at the application level, services level, process and interface macro-elements level), and the user requirements specification document ready for sign-off (i.e., customer validation).
The approach adopted to train future users of this methodology was to provide courses to colleagues on a request basis. The course provided has now come to its eight edition and refining it has been an "on-going" work. At the moment it is structured in three days and it provides an initial general overview of the importance of quality management in a software project, covering its main aspects, then relating these issues to the user requirements specification process and then going in the details of the DOMINO 2.0 methodology.
In parallel with this training activity a number of colleagues have been specifically trained to provide support directly to software projects with a mentoring activity (this support has also been provided on a request basis). The mentoring activities involved have been modelled in a process (see Figure 2) in order to clearly define and separate the mentoring activity (white color) with the project specific activity (grey color). The "tools" made available for supporting the corresponding activity are shown on the right side of the process. The ‘Checklist’ has been developed to support the mentor in verifying, at certain points in the mentoring process, the correct ‘formal’ interpretation and application of the methodology concepts and constructs (covering all its aspects, from the models to the chapters to be included in the final specification document); all other consistency doubts/checks need to be worked out together with someone from the project team. The ‘Tool’ refers to a customization that was applied to some market tools (RequisitePro and SoDA) to support requirements management and the automatic generation of the user requirements specification template according to DOMINO 2.0.
Since DOMINO 2.0 is based on an iterative process, the mentoring process also results to be iterative. The mentoring process activities shown in Figure 2 are:
Fig. BARTOCCI.2: the mentoring process for CSELT DOMINO 2.0 deployment.
.. about CSELT DOMINO 2.0 and its deployment approach ..
DOMINO 2.0 application overall is giving a positive feedback. The major advantages appreciated by users are that it offers a structured and guided approach to gradually approach the complexity of the specific problem, and the context model results to be a powerful and sufficiently userfriendly technique to discuss the application boundaries and services not only within the project team but with the customer also. Team working and cooperation were also found to be improved by the adoption of this methodology thanks to a better organization and documentation of requirements and by using "a common language", also allowing for easier walkthroughs and reviews with the customer for sharing the application vision. Finally, another useful characteristic of DOMINO 2.0 was found to be that it supports producing a specification document with different levels of details so that it is quite easy to extract from it a specification document containing the ‘right’ level of detail necessary to be validated by the customer while giving the entire specification document to the development and testing groups. Another advantage found by our users was that this kind of component-based specification approach augments specification reuse (new releases may be specified easily with least redundancy simply by referring to previous versions of the user requirements specification). Regarding the User Requirements Elicitation task, it was generally felt that the activities in this task are a good "tool" for enforcing exchanges of ideas between the different roles involved in the project. Regarding the User Requirements Engineering task, it was found useful especially for formalizing user requirements when software development was outsourced and for deriving some test cases. The major disadvantage DOMINO users talk about relates to the overhead of documenting user requirements (which typically may change very often and very rapidly on-going) and in such situations DOMINO 2.0 ends up in requiring too many formalisms and overhead in updating coherently the requirements specification.
As far as the course is concerned, it was initially structured in order to provide colleagues with a case study extracted from an application of DOMINO 2.0 to a real software project. The target in doing so was to comment directly with the class how DOMINO 2.0 specifications were going to look like, how the models are to be applied and so on. This approach though resulted to be less effective than expected since it was hard to make people understand that customizations are possible and also where and when they can take place. The major refinement to the course objectives was then in this direction: it was decided not to show any specific example but rather to work directly in class on a case study, performing in small groups the task’s activities. This resulted to be much more effective, providing room and suggestion for broader discussion and questions on particular concepts.
About the mentoring process it was found positive in itself, though there were some drawbacks/refinements necessary. First of all, when people new to the methodology are supported, it becomes harder to trace the line between supporting understanding of the methodology and actually performing the analysis of the specific application, this sometimes resulted in going beyond the planned schedule for the time assigned to the mentor. The major cost of supporting a project in using DOMINO 2.0 was generally felt to be in checking and walking through the analysis models and specification being produced: the mentor is generally not skilled in the specific project domain and yet she/he needs to have some knowledge of it to understand if the modelling techniques are being applied correctly. Also, when the methodology is being used for the first time, the initial models are sometimes completely built together with the mentor. So we looked for some sort of trade-off solution, and what we’re thinking is to train the mentoring people in order to cover the different department areas, trying to shorten the gap between the methodology and the domain knowledge in the person supporting deployment. Another relevant finding was that specific time needs to be planned and scheduled ahead by the project manager to take into consideration all the above issues. Furthermore, once a person has become familiar with DOMINO 2.0, by having applied it to at least one project, then subsequent experiences need very little support. For this reason two kinds of supports are being issued lately: a "first level support" (mentoring projects that will apply the methodology for the first time) and "second level support" (mentoring projects already skilled on the methodology but still requiring some ‘spot’ kind of support on very specific issues).
As far as the Checklist is concerned, while it was originally thought to be a tool supporting the mentor in performing the consistency and formal checks of a correct DOMINO 2.0 application, they actually became tools supporting the analysts in producing the specification, especially the models (as if it were a sort of "quick reference guide"), so it is actually being used in both these ways. One difficulty with it is that it becomes hard to apply when the methodology is being customized too much.
DOMINO 2.0 is resulting adequate for medium/large software projects (referring to complexity, cost, number of releases per year, time schedule, control, ..), while resulting in too much overhead for medium/small software projects. For these latter kinds of projects we developed (late last year) a more general set of Methodology Guidelines supporting the user requirements specification process, containing general principals, a small and simple set of suggested modelling techniques, and a specification document template.
.. and about the cultural change that CSELT is performing
Over the past year there have been may occasions to realize that the cultural change that CSELT needs to perform is really complex and for this reason it is being slow. In CSELT this year about 50% of the total number of projects are software projects; the DOMINO 2.0 courses so far have been attended by about 25% of the people allocated on a software project and so far we have supported with mentoring 4 projects with a ‘first-level support’ and 3 with a ‘second-level support’; also other 7 projects asked support in using the more general Methodology Guidelines mentioned above. These are considered quite good numbers to start with, but the reality has been that only in those departments where the top-management was convinced and sponsored a more systematic approach to software engineering, we were really able to have some concrete impact, otherwise we found most people reluctant to perform this change. Another good result and impact for us has been that our System Quality department has modified some of its procedures adopting several results that have been produced by the project specifically set up to support software project management. Among them is the must that every software project from now on will have to document user requirements by producing a specification for them, either by applying DOMINO 2.0 or the more general Methodology Guidelines, and that they will have to provide Test Plans correspondingly. On the other hand, due to historical reasons, CSELT was never institutionally used to thinking and working ‘by processes’ but this new trend is now gradually being adopted by our System Quality department, and the area of software project management will be among the first to be involved by it. For the above reasons in CSELT we don’t have yet a specific metric to measure our improvements (we only keep track of the number of non conformities we get by each of the ISO9001 certification inspections), though another very ‘empirical measure’ we are having, relating to software project management, is that many progress reports of the projects being supported with CSELT methodologies and corresponding mentoring mention that they have produced the user requirements specification using such methodology, or such mentoring (.. people is starting to talk about them).
[2] A. Bartocci, C. Gajetti, P. M. Maccario DOMINO (Distributed Object oriented Methodology for an Incremental apprOach) versione 2 - La fase di Specifica dei requisiti utente, Documento Tecnico CSELT dicembre 1998.
[3] A. Bartocci, C. Gajetti, P. M. Maccario Template del documento di specifica dei requisiti utente (versione 2) sviluppato secondo la metodologia DOMINO 2.0, Documento Tecnico CSELT dicembre 1998.
[4] A. Bartocci, P. M. Maccario Proposta di approccio metodologico per l’analisi di applicazioni software orientate ad oggetti - La Metodologia DOMINO, Documento Tecnico CSELT dicembre 1996.
[5] Bartocci A., Grasso E., Maccario P.M., Martini G. Proposta di approccio metodologico ed architettura di riferimento per i sistemi di supervisione e controllo, Documento Tecnico CSELT, 1996.
[6] I. Jacobson Object Oriented Software Engineering - A use case driven approach, Addison Wesley 1992.
[7] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen Object-Oriented Modelling and Design, Prentice Hall 1991.
[8] Booch, G. Object Solutions Managing the Object-Oriented Project, Addison-Wesley 1996, ISBN 0-8053-0594-7.
[9] Bellcore; The Bellcore OSCA™ Architetture, Bellcore Technical Advisory, 1992.
[10] TINA-C deliverable Computational Modelling Concepts, 1996.