A Method for Extracting and Stating Software Requirements that a User Interface Prototype Contains

User interface and requirements prototyping is a requirements elicitation technique. A user interface and requirements prototype is built during the requirements engineering phase of a software system development. Along with the user interface prototype are produced various documents such as the system requirement specification. When a prototype and other documents exist, they may not describe the same functionality, particularly because there may be behaviour of the prototype, artefacts of prototyping, that may not be intended. The problem is that in later development stages, when there is a prototype and other documents, it is often difficult to reconcile the difference between the prototype and the other documents. This paper presents an approach for avoiding this difficulty. It demonstrates the approach by showing its application to parts of a real software development.     

Specifying and Analysing System-Level Inter-Component Interfaces

In control systems, the interfaces between software and its embedding environment are a major source of costly errors. For example, Lutz reported that 20–35% of the safety-related errors discovered during integration and system testing of two spacecraft were related to the interfaces between the software and the embedding hardware. Also, the software’s operating environment is likely to change over time, further complicating the issues related to system-level inter-component communication. In this paper we discuss a formal approach to the specification and analysis of inter-component communication using a revised version of RSML (Requirements State Machine Language). The formalism allows rigorous specification of the physical aspects of the inter-component communication and forces encapsulation of communication-related properties in well-defined and easy-to-read interface specifications. This enables us both to analyse a system design to detect incompatibilities between connected components and to use the interface specifications as safety kernels to enforce safety constraints.     

Linguistic Problems with Requirements and Knowledge Elicitation

Human and conversational aspects of requirements and knowledge identification are employed to show that requirements ‘engineering’ is not the same as civil engineering or scientific problem solving. Not only can requirements not be made fully explicit at the start of a project, they cannot be made fully explicit at all. A need is identified to enhance computer-based information systems (CBIS) development methods to accommodate: plurality of incommensurable perspectives, languages and agendas; dynamic representations of system features that can be experienced rather than abstracted and forced into an abstract paper-based representation; recognition that CBIS development is in general a continuous process where users changing their minds is a natural and necessary indication or organisational vitality.  It is suggested that prototyping and rapid application development go some way to addressing these requirements but that they require further development in the light of the theoretical light thrown on the nature of the problem.     

Effective Communication in Requirements Elicitation: A Comparison of Methodologies

The elicitation or communication of user requirements comprises an early and critical but highly error-prone stage in system development. Socially oriented methodologies provide more support for user involvement in design than the rigidity of more traditional methods, facilitating the degree of user–designer communication and the ‘capture’ of requirements. A more emergent and collaborative view of requirements elicitation and communication is required to encompass the user, contextual and organisational factors. From this accompanying literature in communication issues in requirements elicitation, a four-dimensional framework is outlined and used to appraise comparatively four different methodologies seeking to promote a closer working relationship between users and designers. The facilitation of communication between users and designers is subject to discussion of the ways in which communicative activities can be ‘optimised’ for successful requirements gathering, by making recommendations based on the four dimensions to provide fruitful considerations for system designers.     

Preventing Requirement Defects: An Experiment in Process Improvement

Inadequate requirements cause many problems in software products. This paper reports on an experiment to reduce the number of requirement defects. We analysed the present defects in a real-life product and estimated the likely effect of 44 prevention techniques. We had hoped a novel combination of techniques would come up, but the best approach was quite well known, although new to the company: study the user tasks better, make early prototypes of the user interface, and test them for usability. This approach was tried out in a new development project in the same company. Due to the new approach, there was no doubt about requirements during programming, and as a result it became the first project in the company that was completed on time and without stress. Usability was drastically improved, and as a result the product sold twice as many units as similar products, and at twice the unit price.     

User diversity and design representation: Towards increased effectiveness in Design for All

This paper addresses user modelling for “Design for All” in a model-based approach to Human-Computer Interaction, paying particular attention to placing user models within organisational role- and task-related contexts. After reviewing a variety of user modelling approaches, and deriving requirements for user modelling related to Design for All, the paper proposes a role-driven individualised approach. Such an approach is based on a model-based representation schema and a unifying notation that keeps the user’s models and the contextual information transparent and consistent. Individualisation is achieved by coupling symbolic model specifications with neural networking on synchronisation links between symbolic representation elements. As a result, user modelling for Design for All is achieved not by stereotypical user properties and functional roles, but by accommodating the actual users’ behaviour. Published online: 18 May 2001     

A Tool to Support Collaborative Software Requirements Management

The system requirements specification (SRS) is a highly dynamic document that grows and evolves throughout a software development project, and it is critical that it be carefully engineered and managed. Because the SRS fulfils many roles and is of interest to a diversity of stakeholders, its management should be a collaborative process supported by an automated tool. Commercial requirements management tools are at present insufficiently versatile to support collaboration between a multidisciplinary and potentially distributed team of stakeholders. The requirements for such a collaborative tool are herein presented, alongside the design of a prototype and the findings of its application in a case study.     

Time Aspects in Requirements Engineering: Or ‘Every Cloud Has A Silver Lining’

Nowadays, time is critical in most system engineering projects. The ability to deliver systems in short time determines the success of the system supplier. For customers, the quicker the system delivery time, the better are their chances to get some business advantages in their ever-changing business environments. As a consequence, an increasing number of projects are subjected to tight deadlines in all project phases, including requirements elicitation. A project with plenty of time for developing a requirements specification is hard to find. In this paper, experiences from one such project are reflected. Based on these experiences, time aspects in requirements engineering are discussed; i.e., what could be done better in requirements engineering if there were more time and what can easily be missed in requirements engineering under a tight deadline.     

Consistent specification of interface suites in UML

The paper motivates and describes a model oriented approach for consistent specification of interface suites in UML. An interface suite is a coherent collection of interfaces defining interactions that transcend component boundaries. The specification of interface suites contains diagrammatic views and documentation, but it is extended with templates for structured specifications deriving from the ISpec approach. To guarantee that the specification views, documentation and templates are consistent, a specification model has been constructed. The model contains both structural and behavioural information, represented in the form of sequences of carefully designed tuples. The model provides the underlying structure for the tool supporting the design process. The tool directs the designer to specify all elements of the model in a consistent way. The specification is collected both by customized specification templates and by diagrams. The documentation and the diagram elements – both derived from the template information – are automatically generated. This prevents errors and provides specification consistency. Initial submission: 15 February 2002 / Revised submission: 20 September 2002 Published online: 2 December 2002 RID="*" ID="*"Supported by PROGRESS grant EES.5141 and ITEA DESS grant IT990211.     

Rationale-Based Use Case Specification

The requirements specification – as outcome of the requirements engineering process – falls short of capturing other useful information generated during this process, such as the justification for selected requirements, trade-offs negotiated by stakeholders and alternative requirements that were discarded. In the context of evolving systems and distributed development, this information is essential. Rationale methods focus on capturing and structuring this missing information. In this paper, we propose an integrated process with dedicated guidance for capturing requirements and their rationale, discuss its tool support and describe the experiences we made during several case studies with students. Although the idea of integrating rationale methods with requirements engineering is not new, few research projects so far have focused on smooth integration, dedicated tool support and detailed guidance for such methods.     

Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications

In many applications, especially from the business domain, the requirements specification mainly deals with use cases and class models. Unfortunately, these models are based on different modelling techniques and aim at different levels of abstraction, such that serious consistency and completeness problems are induced. To overcome these deficiencies, we refine activity graphs to meet the needs for a suitable modelling element for use case behaviour. The refinement in particular supports the proper coupling of use cases via activity graphs and the class model. The granularity and semantics of our approach allow for a seamless, traceable transition of use cases to the class model and for the verification of the class model against the use case model. The validation of the use case model and parts of the class model is supported as well. Experience from several applications has shown that the investment in specification, validation and verification not only pays off during system and acceptance testing but also significantly improves the quality of the final product.       

Scenario Analysis in an Automated Tool for Requirements Engineering

 This paper presents an automated tool for scenario-driven requirements engineering where scenario analysis plays the central role. It is shown that a scenario can be described by three views of data flow, entity relationship and state transition models by slight extensions of classic data flow, entity relationship and state transition diagrams. The notions of consistency and completeness of a set of scenarios are formally defined in graph theory terminology and automatically checked by the tool. The tool supports automatic validation of requirements definitions by analysing the consistency between a set of scenarios and requirements models. It also supports automatic synthesis of requirements models from a set of scenarios. Its utility and usefulness are demonstrated by a non-trivial example in the paper. Case studies of the tools are also presented.     

Mechanized result verification: an industrial application

We present part of an industrial project where mechanized theorem proving is used for the validation of a translator which generates safety critical software. In this project, the mechanized proof is decomposed in two parts: one is done “online”, at each run of the translator, by a custom prover which checks automatically that the result of each translation meets some verification conditions; the other is done “offline”, once for all, interactively with a general purpose prover; the offline proof shows that the verification conditions checked by the online prover are sufficient to guarantee the correctness of each translation. The provably correct verification conditions can thus be seen as specifications for the online prover. This approach is called mechanized result verification. This paper describes the project requirements and explains the motivations to formal validation by mechanized result verification, provides an overview of the formalization of the specifications for the online prover and discusses in detail some issues we have addressed in the mechanized offline proof.     

Formalization and validation of the General Inter-ORB Protocol (GIOP) using PROMELA and SPIN

The General Inter-Orb Protocol (GIOP) is a key component of the Common Object Request Broker Architecture (CORBA) specification. We present the formal modeling and validation of the GIOP protocol using the Promela language, Linear Time Temporal Logic (LTL) and the Spin model checker. We validate the Promela model using ten high-level requirements which we elicit from the informal CORBA specification. These requirements are then formalized in LTL and the Spin model checker is used to determine their validity. During the validation process we discovered a few problems in GIOP: a potential transport-layer interface deadlock and problems with the server migration protocol. We also describe how property specification patterns helped us in formalizing the high-level requirements that we have elicited.     

User interface specification with sequence diagrams: an application to the AIRBUS A380 Datalink system

The development of user interfaces for safety critical systems is driven by requirements specifications. Because user interface specifications are typically embedded within complex systems requirements specifications, they can be intractable to manage. Proprietary requirements specification tools do not support the user interface designer in modelling and specifying the user interface. In this paper, a new way of working with embedded user interface specifications is proposed, exploiting sequence diagrams with a hypertext structure for representing and retrieving use cases. This new tool concept is assessed through an application to the requirements specification for the Airbus A380 air traffic control Datalink system; engineers involved in the development of the Airbus cockpit used a prototype of the tool concept to resolve a set of user interface design anomalies in the requirements specification. The results of the study are positive and indicate the user interface to requirements specification tools which user interface designers themselves need.     

Animating Formal Specifications with Inheritance in a DL-Based Framework

Dynamic logic (DL) provides a suitable formal framework to model actions and reasoning about them. <$>\cal OASIS<$> is a language for the specification of object-oriented conceptual models. In our model, specialisation is a relation between classes that defines an inheritance mechanism through static and dynamic partitions. A variant of DL (including the deontic operators for permission, prohibition and obligation) is the formalism used in <$>\cal OASIS<$> to deal with changes of state, triggers, preconditions, protocols and operations. The animation of conceptual models in order to validate the specification is an interesting topic. We have worked on translating <$>\cal OASIS<$> specifications automatically to concurrent environments in order to obtain a prototype useful to validate specifications by animation. The aim of this paper is to show that it is feasible to translate static and dynamic partitions automatically into dynamic logic formulae. Thus, using the same developed schema of animation it is possible to execute <$>\cal OASIS<$> specifications including inheritance.     

A Methodology for Constructing User-Oriented Requirements Specifications for Large-Scale Systems Using Electronic Hypermedia

requirements specifications are developed for large-scale systems, the final specification is usually an abstraction of the original requirements data into a text-based form that is often foreign to end-users. A method was developed for representing requirements through use of electronic multimedia. The resulting specification is capable of representing requirements and requirements data in a manner that is more representative of the real-world problem space than traditional specifications. This paper presents a method for incorporating multimedia exhibits, notably the results of rapid prototyping activities and animated simulation, into a requirements specification for large-scale C2I systems. To examine the effectiveness of the method, a multimedia requirements specification was developed based on an existing text specification for a real-world system. An experiment was also performed that showed the product of the methodology to be effective in increasing the understandability of the specification over that obtained from the text specification alone.     

Making Workflow Change Acceptable

Virtual professional communities are supported by network information systems composed from standard Internet tools. To satisfy the interests of all community members, a user-driven approach to requirements engineering is proposed that produces not only meaningful but also acceptable specifications. This approach is especially suited for workflow systems that support partially structured, evolving work processes. To ensure the acceptability, social norms must guide the specification process. The RENISYS specification method is introduced, which facilitates this process using composition norms as formal representations of social norms. Conceptual graph theory is used to represent four categories of knowledge definitions: type definitions, state definitions, action norms and composition norms. It is shown how the composition norms guide the legitimate user-driven specification process by analysing a case on the development of an electronic law journal.     

Deriving Goals from a Use-Case Based Requirements Specification

Use cases and scenarios have emerged as prominent analysis tools during requirements engineering activities due to both their richness and informality. In some instances, for example when a project’s budget or schedule time is reduced at short notice, practitioners have been known to adopt a collection of use cases as a suitable substitute for a requirements specification. Given the challenges inherent in managing large collections of scenarios, this shortcut is cause for concern and deserves focused attention. We describe our experiences during a goal-driven requirements analysis effort for an electronic commerce application. In particular, we identify the specific risks incurred, focusing more on the challenges imposed due to traceability, inconsistent use of terminology, incompleteness and consistency, rather than on traditional software project management risks. We conclude by discussing the impact of the lessons learned for requirements engineering in the context of building quality systems during goal and scenario analysis.     

Practical Experience with Viewpoint-Oriented Requirements Specification

The notion of viewpoints as a means of eliciting and formulating requirements is now well known. However, there is little practical evidence that viewpoint-based requirements methods scale up to address real problems. This paper presents a detailed case study based on a medium-sized system, and illustrates how a viewpoint-based requirements method can be used to structure and specify system requirements. The case study is intended to serve two purposes: first, to demonstrate the scalability of viewpoint-based requirements methods; and second, to act as a shared example for other researchers in the field to test their techniques and methods. The case study is based on an electronic document delivery and interchange system (EDDIS). The requirements are presented as they appeared in the original user requirements document. The paper concludes by outlining the lessons learnt in applying VORD to EDDIS, and proposes a set of 10 comparators that other researchers can use to compare their approaches and techniques.