Maintaining Requirements Specification

Standard office tools (MS word and excel), modelling tools (Rational Rose and RML editor), graphical packages (MS paint), and communication tools (ICQ, MSN messengers, and e-mail systems) were used. IEEE std. 830-1998 (1998) recommendation was adapted to the requirements specification. RML editor (Sølvberg, 1999) facilitated in creation of the conceptual model of the problem. Rational Rose was used to describe behavioural model and to prepare the use case diagrams for the individual requirements. The participants chose the communication tools according to their experience. In order to support the communication ICQ and MSN messengers were used. The e-mail correspondence helped in distributing the requirements specification for the participant consideration.

The observation of the preparation and maintenance of the requirements specification was performed. The observation shows the list of shortcomings, needed for an automated support of the RE process. The shortcomings of RE using standard

CASE STUDIES

Lack of automatic generation of standard requirements specification (feature

FEF3.3). The requirements specification should correspond to standards (e.g.: IEEE std 830-1998), which should be maintained by an RE-tool. The requirements specification should separate between different RE phases, like requirements analysis and documentation. It should support different software development methodologies and life cycles, which usually depend on organisational policy. Some of the RE-tool candidates (e.g., Cradle-4) is supposed to cover this feature quite well, because it provides means to define organisational standards for documentation.

Requirements analysis and requirements specification is not separated (feature

FEF3.2). Requirements analysis is the activity of learning the aspects of the problem domain to determine how to solve a specific set of users needs. Requirements analysis should be followed with different reports, agreement, negotiation, and documentation. Requirements specification is the activity of documenting a requirements specification. The FEF3.2 is one of the most important features, as the quantitative analysis has demonstrated.

Lack of requirements grouping (feature FEF2.2). The project involves different

groups of requirements, for example, requirements for time constraints, functionality, usability, reliability, information storage, source code. The FEF2.2 is quite well supported by the RE-tools candidates (e.g., DOORS 5.2, RequisitePro, VitalLink, XTie-RT 3.1, and RDT Version 3.0) but the tools have many shortcomings concerning different modelling perspectives and participant viewpoints. Requirements grouping activities were carried out manually in our case. This is observed as the shortcoming taking in account a potential development size of the project.

Lack to represent requirements model in different techniques, including informal, semiformal, and formal representations (features FEF1.1, FEF1.2, and

FEF1.3). The requirements model includes one logical requirements model, but the variety of project participants demands different representation techniques and requirements groups during all the RE process activities. Different representations are used during elicitation, analysis, validation and other RE activities. In the project two techniques were used for informal requirements representation – natural language and use case templates (Kulak and Guiney, 1998). Natural language requirements specification was the most suitable for the initial phases of RE process. The use case templates provided a way for specification of the structured information (in natural language), which contributed to requirements communication and requirements understandability.

Two techniques were used for semiformal requirements representation: state transition diagrams and reference modelling language diagrams (Sølvberg, 2000). State transition diagram represented the dynamic behaviour of the system. The requirements model, prepared with reference modelling language (Figure 7.2), aims to produce

semantically sound models of the real world of the real phenomena, thus separating the real world modelling and traditional data-modelling.

In order to show intentional relationships of the problem elements, the requirements representations were extended with a formal requirements description (Figure 7.3). The set theory notations were used. They allowed the description of the requirements model using rules and predicates.

Cooperative work among multiple users is not supported (feature FEF2.3). The

RE-tools should provide means for the collaborative work support. The RE-tool should include multidisciplinary teamwork, which could be geographically distributed. The tool should include not only the means for users working in an organisation, but also for a multidisciplinary teamwork, which could be geographically distributed. RE is the best performed by a cross-functional requirements team that provides an adequate experience base to capture all the requirements and to iterate them in a timely fashion. The FEF2.3 is supported quite weakly, in general case only by providing a web-based user interface. During the project, the requirements specification was distributed to different stakeholders by e-mail. That resulted in shortcomings for maintaining replication and specification versions.

Lack to provide means for communication and maintenance of rationale

(feature FEF2.1). It is important to be able to recreate the rationale behind some requirements specification items, as analysed by Loucopoulos and Karakostas (1995). The communication means provide awareness to the participants and allow the collaborative work through all the RE process.

It was quite a challenging task of the project. First, due to the different communication tools (e-mail, MSN and ICQ messenger programs) it is difficult to support and argue appropriately different issues of requirements. Second, the rationale needs to be related to each element of requirements specification. Finally, the maintenance of rationale was kept as the track of e-mails sent about the different RE and system development questions among project participants.

None of the RE-tools candidates provide adequate support for argumentation. However, some of them (e.g., CaliberRM Web v.4.0, RequisitePro) support means for a baseline, and maintain requirements version control (e.g., CaliberRM Web v.4.0).

Lack of maintaining traceability relationship among different requirement elements (feature FEF1.4). It is important to keep traceable relationships among all the

related information during the RE process. Traceability is needed to relate requirements, their rationale, source, requirements representation and requirements specification versions. One of the ways to ensure traceable relationships is to maintain

CASE STUDIES

traceable information was kept manually, and this again makes it difficult to perform when the requirements specification expands.

Lack of repository for storing data of a requirements specification (the feature

FEF3.1). A RE-tool should support storage of requirements in a requirements repository instead of a paper document. The requirements repository stores requirements-related information such as: individual requirements, requirements metadata, different requirements representations, and requirements models. It should include different information formats like diagrams, tables, formal representations of requirements. The requirements repository benefit is to set traceable relations between various elements of the requirements specification. The repository would provide version control and reuse of already agreed common domain requirements. This feature was very poorly supported by the RE-tools candidates.

Lack of maintaining different data formats according to modelling techniques and tools used (feature FEF1.5). A tool should allow export and import of

requirements models, prepared with other modelling tools. This would benefit the means to specify requirements using different paradigms and various modelling techniques. It would be beneficial to adopt requirements data interoperability between different tools.

Difficult to maintain flexible requirements management. Nguyen and Swatman

(2003) show that RE process should not be characterised by a smooth and incremental evolution, but by occasional “crisis” points where the requirements models are reconceptualised and simplified. A RE-tool needs to promote design creativity and support reconceptualisation of the requirement model for restructuring the requirements specification.

The maintenance of requirements specification shows the important RE aspects, which are missing while using editing, drawing and modelling tools. The observation was performed along the features and activities of the evaluation framework and the results of the observation shows the limitations of to perform these activities without the adequate automated support. The execution phase demonstrates validation issues for the evaluation framework. It is easy to notice that the features and activities on the evaluation framework cover the shortcomings, arising during preparation and maintenance of requirements specification using standard editing, modelling and drawing tools.