On Abstraction in Scenarios

Scenarios are ways of representing knowledge. They may take many forms, from films of real events through acted scenes to documented procedures. These forms differ in many ways, including how vivid or abstract they are, how accessible they are as specifications, and how effective they are in helping to elicit requirements. Scenarios, especially as Use Cases, are in use or proposed for many aspects of systems engineering. Understanding of the different forms scenarios may take, and then of the costs and benefits of applying these forms in practice, may be valuable.     

A Framework for Integrating Non-Functional Requirements into Conceptual Models

The development of complex information systems calls for conceptual models that describe aspects beyond entities and activities. In particular, recent research has pointed out that conceptual models need to model goals, in order to capture the intentions which underlie complex situations within an organisational context. This paper focuses on one class of goals, namely non-functional requirements (NFR), which need to be captured and analysed from the very early phases of the software development process. The paper presents a framework for integrating NFRs into the ER and OO models. This framework has been validated by two case studies, one of which is very large. The results of the case studies suggest that goal modelling during early phases can lead to a more productive and complete modelling activity.       

Everyday Life as a Stage in Creating and Performing Scenarios for Wireless Devices

Scenarios in HCI are widely used and discussed as written or visual narratives. In this paper, we discuss fruitful conditions for the creation and performance of scenarios particularly for the concept design of mixed realities or wireless devices. Designers are attempting new ways of engaging people in design and experiencing ideas in early design phases. Examples range from exploring scenarios using mock-ups or Wizard-of-Oz techniques, to testing scenarios with prototypes. In our design projects, scenarios were created and performed with participants following them in their daily activities. Discussing these sessions, which we called SPES (Situated and Participative Enactment of Scenarios), we highlight as promising conditions to create scenarios: the everyday life as a stage and the opportunity for participants to exercise reflection-in-action.     

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.     

Using Design Explanation within the Formal Object-Oriented Method

This paper reports the results of an action research project which studied the benefits of documenting the evolution, and the rationale for the evolution, of a requirements specification. The benefits which design explanation offers designers (as documented in the literature) suggested an investigation with a view to understanding the potential contribution of the IBIS (Issue-Based Information System) approach. The paper reports an investigation into the use of ad hoc design explanation, in which design decisions were documented as they were made using the IBIS notation. This study finds both strengths and weaknesses in the approach. It reveals ways in which IBIS might be used more effectively and leads us to suggest a further study into the complementary use of ad hoc and post hoc design explanation approaches.     

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.     

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.     

Requirements Reuse for Improving Information Systems Security: A Practitioner’s Approach

Information systems security issues have usually been considered only after the system has been developed completely, and rarely during its design, coding, testing or deployment. However, the advisability of considering security from the very beginning of the system development has recently begun to be appreciated, and in particular in the system requirements specification phase. We present a practical method to elicit and specify the system and software requirements, including a repository containing reusable requirements, a spiral process model, and a set of requirements documents templates. In this paper, this method is focused on the security of information systems and, thus, the reusable requirements repository contains all the requirements taken from MAGERIT, the Spanish public administration risk analysis and management method, which conforms to ISO 15408, Common Criteria Framework. Any information system including these security requirements must therefore pass a risk analysis and management study performed with MAGERIT. The requirements specification templates are hierarchically structured and are based on IEEE standards. Finally, we show a case study in a system of our regional administration aimed at managing state subsidies.     

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.       

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.     

Goal-Oriented Requirements Engineering: A Unifying Framework

The study of contemporary requirements engineering (RE) methodologies indicates that modelling of organisational goals constitutes a central activity of the RE process. In particular, goals provide the rationale and drive the elaboration of the requirements that operationalise them. They also provide the criteria against which the completeness and correctness of the requirements specification is validated. In other words, requirements implement goals in the same way that programs implement design specifications. Despite the significance of goals in RE, research in the field is fragmented. No research has so far taken place in order to define the overall role that goals play in RE. This paper puts forward a unifying view of goal analysis in the context of RE. This allows the identification of similarities and differences between the different conceptions of goal used by different approaches and promotes the understanding of the overall role of goal analysis in RE. Based on this understanding the various approaches can be put together, thus leading to a stronger goal-driven RE framework that takes advantage of the contributions from the many streams of goal-oriented research.     

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.     

Engineering Requirements Through Use Cases in Complex Business Environment

The increasingly global nature of financial markets and institutions means that the collection and management of information on which decisions might be based are increasingly complex. There is a growing requirement for the integration of information flows at individual and departmental levels, and across processes and organisational boundaries. Effective information management is an important contributory factor in the efficiency of such institutions, though there are many associated problems that do not have obvious or simple answers. This paper discusses the problem of information gathering in complex business environments and considers how use cases can help to alleviate the problem using an example of a multinational organisation. Such organisations often require information systems that can support regional differences. However, management requires consistent and uniform representation of information. The example shows that use cases can be a helpful mechanism for capturing user requirements that accommodate both regional properties as well as their organisational commonalties.     

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.     

Requirements Engineering and Technology Transfer: Obstacles, Incentives and Improvement Agenda

For many years, research results in requirements engineering (RE) have been developed without much interaction with, or impact on, industrial practice. Why is it so difficult to introduce RE research results into mainstream RE practice? This paper attempts to provide answers to this question by describing obstacles that researchers and practitioners have encountered when they attempted technology transfer. In addition, major incentives for using RE methods are discussed, along with ideas for improving current RE practice. The paper summarises, clarifies and extends the results of two panel discussions, one at the Twelfth Conference on Advanced information Systems Engineering (CAiSE’00) and the other at the Fourth IEEE Conference on Requirements Engineering (ICRE’00).     

An Approach to Security Requirements Engineering for a High Assurance System*

Requirements specifications for high-assurance secure systems are rare in the open literature. This paper examines the development of a requirements document for a multilevel secure system that must meet stringent assurance and evaluation requirements. The system is designed to be secure, yet combines popular commercial components with specialised high-assurance ones. Functional and non-functional requirements pertinent to security are discussed. A multidimensional threat model is presented. The threat model accounts for the developmental and operational phases of system evolution and for each phase accounts for both physical and non-physical threats. We describe our team-based method for developing a requirements document and relate that process to techniques in requirements engineering. The system requirements document presented provides a calibration point for future security requirements engineering techniques intended to meet both functional and assurance goals. RID="*" ID="*"The views expressed in this paper are those of the authors and should not be construed to reflect those of their employers or the Department of Defense. This work was supported in part by the MSHN project of the DARPA/ITO Quorum programme and by the MYSEA project of the DARPA/ATO CHATS programme. Correspondence and offprint requests to: T. Levin, Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943-5118, USA. Tel.: +1 831 656 2339; Fax: +1 831 656 2814; Email: levin@nps.navy.mil     

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.     

Describing Team Work with Activity Theory

The proposal that activity theory might serve as a model or theory for computer-supported cooperative working remains an open question. Here we demonstrate the usefulness of activity theory in elucidating a series of small group software design meetings. The structure and dynamics of the meetings are presented, as are the work processes of transformation and mediation. Finally, we show how a contradictions analysis can support the derivation of requirements on a system to support the design meetings.