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.       

Tracing Requirements Errors to Problems in the Requirements Engineering Process

A case study of requirements engineering practice is reported. The application, a decision support system for the Greek Ministry of Health, was investigated by studying the process of requirements analysis through to design and implementation. A usability analysis was then conducted on the designed system with the users. Several usability problems were discovered, and interviews uncovered further problems with the system that could be attributed to failure in requirements engineering (RE). Even though requirements were explicitly stated and the system was an evolution from an existing legacy system, functionality was defective and usability was poor. The client’s prime concern for redeveloping the system was to improve usability; unfortunately communications problems in the RE process meant that the developers did not appreciate this. The implications for RE methods and understanding the RE process are discussed.     

Patterns Approach to Product Information Systems Engineering

This paper deals with the application of the pattern approach to product information systems (PIS) engineering. Two kind of patterns are distinguished: business patterns used for specification and providing solutions for application field problems, and software patterns used for implementation and providing solutions for technical problems (software). Particular attention is given to identifying and specifying different business patterns. The main focus is on the activity of design for reuse, i.e. discovery of business patterns and their integration in a pattern catalogue. The first step consisted of a field analysis providing a common terminology and a semantic of the principal concepts managed in PIS and proposing various models to fix these concepts. It forms a basis for exploring the problems frequently occurring during PIS specification. A pattern catalogue is then proposed to solve the identified problems.     

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.     

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.     

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.     

Large-Scale Requirements Analysis Revisited: The need for Understanding the Political Ecology of Requirements Engineering

This paper addresses the political nature of requirements for large systems, and argues that requirements engineering theory and practice must become more engaged with these issues. It argues that large-scale system requirements is constructed through a political decision process, whereby requirements emerge as a set of mappings between consecutive solution spaces justified by a problem space of concern to a set of principals. These solution spaces are complex socio-technical ensembles that often exhibit non-linear behaviour in expansion due to domain complexity and political ambiguity. Stabilisation of solutions into agreed-on specifications occurs only through the exercise of organisational power. Effective requirements engineering in such cases is most effectively seen as a form of heterogeneous engineering in which technical, social, economic and institutional factors are brought together in a current solution space that provides the baseline for construction of proposed new solution spaces.     

A Qualitative Scenario Approach to Managing Evolving Requirements

In this paper, we argue that information systems requirements are inherently dynamic, and that a methodology that caters for such dynamicity must enable the evaluation of requirements, as they evolve, against dynamic contexts. Moreover, information systems contexts are soft, ambiguous, and are thus mainly characterised by qualitative data. We present an analytical technique, based on the grounded theory method for developing qualitative scenarios against which statements of requirements can be evaluated.     

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.     

Patterns of Mobile Interaction

The design of systems for mobile scenarios covers a wide range of issues, ranging from mobile networking to user interface design for mobile devices. Mobile applications often run distributed on several connected devices, used by many users simultaneously. Considering all issues related to mobile scenarios, a designer might be overwhelmed. As a solution, we propose a specific kind of design patterns which we call mobility patterns, derived from successful mobile applications. They allow a designer to re-use design elements as building blocks in their own designs. After describing the idea of mobility patterns, we give a brief overview of patterns we have identified so far. Two patterns are described in more detail with the help of our research platforms QuickStep and Pocket DreamTeam.     

Requirements Management: A Cinderella Story

Why do the business requirements and the final software product often have little in common? Why are stakeholders, developers and managers reluctant to embrace a full requirements process? Why does everybody say, ‘We don’t have time for requirements’? Why is the potentially most beneficial part of the development process ignored or short-changed?  Following are some observations about why the real requirements for the product often go undiscovered. We will address this by focusing on the different concerns of the people involved in requirements.     

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.     

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     

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.     

Round-Trip Prototyping Based on Integrated Functional and User Interface Requirements Specifications

Requirements engineering in the new millennium is facing an increasing diversity of computerised devices comprising an increasing diversity of interaction styles for an increasing diversity of user groups. Thus the incorporation of user interface requirements into software requirements specifications becomes more and more mandatory. Validating these requirements specifications with hand-made, throw-away prototypes is not only expensive, but also bears the danger that validation results are not accurately fed back into the requirements specification. In this paper, we propose an enhancement of the requirements specification method SCORES for an explicit capturing of user interface requirements. The advantages of the approach are threefold. First, the user interface requirements specification is UML-compliant and integrated into the functional requirements specification. Second, prototypes for validation purposes can semi-automatically be generated. Third, the model-based generation of prototypes allows for ‘round-trip prototyping’ such that manual changes of the prototype during the validation process are automatically fed back into the requirements specification.     

Scenario Development and Practical Decision Making under Uncertainty: Application to Requirements Engineering

In this paper, we address the question of how flesh and blood decision makers manage the combinatorial explosion in scenario development for decision making under uncertainty. The first assumption is that the decision makers try to undertake ‘robust’ actions. For the decision maker a robust action is an action that has sufficiently good results whatever the events are. We examine the psychological as well as the theoretical problems raised by the notion of robustness. Finally, we address the false feeling of decision makers who talk of ‘risk control’. We argue that ‘risk control’ results from the thinking that one can postpone action after nature moves. This ‘action postponement’ amounts to changing look-ahead reasoning into diagnosis. We illustrate these ideas in the framework of software development and examine some possible implications for requirements analysis.     

Requirements Engineering-Based Conceptual Modelling

The software production process involves a set of phases where a clear relationship and smooth transitions between them should be introduced. In this paper, a requirements engineering-based conceptual modelling approach is introduced as a way to improve the quality of the software production process. The aim of this approach is to provide a set of techniques and methods to capture software requirements and to provide a way to move from requirements to a conceptual schema in a traceable way. The approach combines a framework for requirements engineering (TRADE) and a graphical object-oriented method for conceptual modelling and code generation (OO-Method). The intended improvement of the software production process is accomplished by providing a precise methodological guidance to go from the user requirements (represented through the use of the appropriate TRADE techniques) to the conceptual schema that properly represents them (according to the conceptual constructs provided by the OO-Method). Additionally, as the OO-Method provides full model-based code generation features, this combination minimises the time dedicated to obtaining the final software product.     

Authorisation Requirements on a Budget

Engineering information system deployment is squeezed by a shrinking commitment to requirements definition and an expanding need to determine the security requirements of such systems. This paper examines the causes and effects of this squeeze. Commitment is shrinking because of past requirements experiences, misunderstood trends in system development and requirements fatigue, while needs are expanding because of recent emphasis on Internet access to data, online transactions and workflow, which greatly increase the severity of the authorisation problem. Some approaches to quantifying and addressing this problem are introduced. Correspondence and offprint requests to: D. Raymond, 305 Bushview Crescent, Waterloo, Ontario, Canada N2V 2A6. Email: darrell.raymond@sympatico.ca     

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.     

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.