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.       

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 Determination: An Information Systems Specialist Perspective of Process Quality

An empirical study was performed to identify, elucidate and judge factors that affect the quality of the information requirements determination process. These quality factors were determined using a series of nominal group processes involving information systems specialists from various organisations and projects. The results indicate that there exists a set of factors that IS specialists from different organisations and with different systems experience agree upon as being critical to ensuring the quality of the requirements determination process, and that these factors appear to fall into six categories: IS specialist factors, user factors, project team factors, project factors, application factors and environmental/organisational factors.     

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.     

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.     

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     

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.     

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.