CREWS-SAVRE: Scenarios for Acquiring and Validating Requirements

This paper reports research into semi-automatic generation of scenarios for validating software-intensive system requirements. The research was undertaken as part of the ESPRIT IV 21903 CREWS long-term research project. The paper presents the underlying theoretical models of domain knowledge, computational mechanisms and user-driven dialogues needed for scenario generation. It describes how CREWS draws on theoretical results from the ESPRIT III 6353 NATURE basic research action, that is object system models which are abstractions of the fundamental features of different categories of problem domain. CREWS uses these models to generate normal course scenarios, then draws on theoretical and empirical research from cognitive science, human-computer interaction, collaborative systems and software engineering to generate alternative courses for these scenarios. The paper describes a computational mechanism for deriving use cases from object system models, simple rules to link actions in a use case, taxonomies of classes of exceptions which give rise to alternative courses in scenarios, and a computational mechanism for generation of multiple scenarios from a use case specification.     

从交互情景出发的需求捕获方法及其支撑工具

需求捕获是需求工程中的重要问题.文中结合情景和问题框架方法,提出一个从交互情景出发的需求捕获方法.其特点是:(1)对问题领域以及软件系统与问题领域间的交互进行分类,以捕获深层需求信息;(2)将情景定义为产生有意义问题领域变化的交互序列,引人交互情景约束,以捕获隐式需求信息.文中构建了支持这个方法的需求描述元模型,提出以...     

Automating test generation for discrete event oriented embedded systems

A method for the automatic generation of test scenarios from the behavioral requirements of a system is presented in this paper. The generated suite of test scenarios validates the system design or implementation against the requirements. The approach proposed here uses a requirements model and a set of four algorithms. The requirements model is an executable model of the proposed system defined in a deterministic state-based modeling formalism. Each action in the requirements model that changes the state of the model is identified with a unique requirement identifier. The scenario generation algorithms perform controlled simulations of the requirements model in order to generate a suite of test scenarios applicable for black box testing. Measurements of several metrics on the scenario generation algorithms have been collected using prototype tools.     

情形实例驱动的软件需求模型自动生成

通过对使用情形的分析来进行需求获取和需求分析可以使软件需求分析的工作较为系统和有序。由于每一个情形实例都只从特定的使用者的角度，根据所需达到的特定使用目的，针对特定的使用条件，来描述一个复杂系统中的一个局部，与对整个复杂系统的需求进行分析和描述相比，在特定情形实例下对软件需求进行分析与描述较简单。然而，如何保证情形实例描述之间的一致性，如何从情形实例的描述获得整个软件系统的需求定义则是以情形实例分     

人机协作的用户故事场景提取与迭代演进

敏捷软件开发中常用用户故事表达需求：用户故事讲述了具体的用户角色希望软件完成的功能.系统新版本的需求常常来自多个用户故事的整合.随着版本的迭代,不断会有新的用户故事出现.用户故事的迭代式管理和整合是敏捷开发成功的关键.为帮助开发者掌握项目的用户故事需求,提出人机协作的用户故事理解、整合和管理方法,支持需求的迭代更新.具体而言,提出用户故事元模型和带场景细粒度描述的用户故事表示,从故事描述、功能特征属性以及场景3个维度表达用户故事.便于开发者理解用户故事所表达的功能需求.提出基于元模型的用户故事理解,以及用户故事表达元素的自动提取方法.提出人机协同式用户故事整合方法,使用功能场景图辅助开发者确定用户故事间的关联关系.提出基于功能场景图的用户故事迭代更新方法.案例研究展示了方法的可行性.     

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 method and tools for large scale scenarios

Formal scenarios have many uses in requirements engineering, validation, performance modeling, and test generation. Many tools and methodologies can handle scenarios when the number of steps (interleaved inputs and outputs of the target system) is reasonably small. However, scenario based techniques do not scale well with the number of steps, number of actors, and complexity of behaviors and system interactions to be specified in the scenario. First, it is impractically tedious and error-prone to specify thousands of input steps and corresponding expected outputs. Second, even if one can write down such large scale scenarios, confidence in their correctness is naturally low. Third, complex systems requiring large scale scenarios tend to require many such scenarios to adequately cover the behavior space. This paper describes the motivations for and problems of large scale scenarios, as well as the LSS method, which uses automated and semi-automated techniques in describing, maintaining, communicating, and using large scale scenarios in requirements engineering. The method is illustrated in two widely divergent application domains: military live training instrumentation and electronic mail servers. A case study demonstrates the practical and beneficial use of LSS in architectural modeling of a complex, real-world system design. A two page extended abstract of this paper appeared in Proc. 21st ACM/IEEE Intl. Conf. on Software Engineering (ASE 2006).     

Clear justification of modeling decisions for goal-oriented requirements engineering

Representation and reasoning about goals of an information system unavoidably involve the transformation of unclear stakeholder requirements into an instance of a goal model. If the requirements engineer does not justify why one clear form of requirements is chosen over others, the subsequent modeling decisions cannot be justified either. If arguments for clarification and modeling decisions are instead explicit, justifiably appropriate instances of goal models can be constructed and additional analyses applied to discover richer sets of requirements. The paper proposes the “Goal Argumentation Method (GAM)” to fulfil three roles: (i) GAM guides argumentation and justification of modeling choices during the construction or critique of goal model instances; (ii) it enables the detection of deficient argumentation within goal model instances; and (iii) it provides practical techniques for the engineer to ensure that requirements appearing both in arguments and in model instance elements are clear.

Applications of linguistic techniques for use case analysis

Use cases are effective techniques to express the functional requirements of a system in a very simple and easy-to-learn way. Use cases are mainly composed of natural language (NL) sentences, and the use of NL to describe the behaviour of a system is always a critical point, due to the inherent ambiguities originating from the different possible interpretations of NL sentences. We discuss in this paper the application of analysis techniques based on a linguistic approach to detect, within requirements documents, defects related to such an inherent ambiguity. Starting from the proposed analysis techniques, we will define some metrics that will be used to perform a quality evaluation of requirements documents. Some available automatic tools supporting the linguistic analysis of NL requirements have been used to evaluate an industrial use cases document according to the defined metrics. A discussion on the application of linguistic analysis techniques to support the semantic analysis of use cases is also reported.     

软件需求中不一致性处理方案的评估方法

提出了一种评估软件需求中不一致性处理方案的方法。给定应用场景,对于每个处理方案,主要关注采用该方案修正后的需求规格说明所能推导出的待开发系统的期望响应,并且这些期望响应的相对重要程度被视为评估该方案适合程度的一个重要参数。在这个意义上,定义效用向量函数来度量每一处理方案的适合程度。进一步采用效用向量函数来比较任意两个处理方案。通过这种比较,定义不一致需求处理方案集上的一种序关系(“更适合”)。文章提出的评估方法将为自动选择不一致性处理方案提供基础。     

Requirements Scenarios Formalization Technique: N Versions Towards One Good Version

Using a notion of simulation introduced by de Roever et al. [9], we define a corresponding notion of bisimulation which we will use as a test to detect formality discrepancy between two formal versions of the same informal scenario. We will also use it, combined with the relation part of, as a test to detect discrepancy between two formal scenarios describing two different informal scenarios. We will describe a way of implementing these formality discrepancy tests in the work place. We call it N-version technique for scenario formalization. This technique allows us to (1) detect formality discrepancy between formal scenario versions corresponding to the same scenario, to (2) validate, for the given scenario, the formalization obtained by a specifier against another obtained by another specifier before bothering the stake-holder with problems of the specifier's creation (formalization errors), and to (3) detect formality discrepancy between the formal scenarios of different informal scenarios if their respective spaces share at least one component.     

Defining a Requirements Process Improvement Model

Both software organisations and the academic community are aware that the requirements phase of software development is in need of further support. We address this problem by creating a specialised Requirements Capability Maturity Model (R-CMM¹). The model focuses on the requirements engineering process as defined within the established Software Engineering Institute’s (SEI’s) software process improvement framework. Our empirical work with software practitioners is a primary motivation for creating this requirements engineering process improvement model. Although all organisations in our study were involved in software process improvement (SPI), they all showed a lack of control over many requirement engineering activities.This paper describes how the requirements engineering (RE) process is decomposed and prioritised in accordance with maturity goals set by the SEI’s Software Capability Maturity Model (SW CMM). Our R-CMM builds on the SEI’s framework by identifying and defining recommended RE sub-processes that meet maturity goals. This new focus will help practitioners to define their RE process with a view to setting realistic goals for improvement.Sarah Beecham is a research fellow in the Department of Maths and Computing in The Open University in the UK. She is currently working on the EPSRC funded CRESTES project () looking into modelling resource estimation for long-lived software. She has recently completed her PhD for a program of work entitled “A Requirements-based Software Process Maturity Model”. Current research interests are in estimation for software evolution and maintenance and in the general areas of software process improvement. Her particular research interests are in empirical methods in software engineering and requirements engineering.Tracy Hall leads the Systems & Software Research Group in the Department of Computer Science at the University of Hertfordshire. She specialises in the empirical investigation of technical and non-technical issues within software engineering. During the past ten years Tracy has successfully collaborated with many companies on a variety of research projects. She is very active in the Empirical Software Engineering community and is regularly invited to talk about empirical methods both in the UK and abroad. Tracy is an accomplished researcher having published over twenty high quality journal papers.Austen Rainer Austen Rainer is a senior lecturer at the University of Hertfordshire. He studied for his PhD at Bournemouth University, in conjunction with IBM Hursley Park. His current research interests include open source software development, longitudinal case study research, and the credibility of empirical evidence for researchers and software practitioners.     

A Representational Framework for Scenarios of System Use

Scenarios are becoming widely used in three areas of system development: software engineering, human–computer interaction (HCI), and organisational process design. There are many reasons to use scenarios during system design. The one usually advanced in support of the practice is to aid the processes of validating the developers’ understanding of the customers’ or users’ work practices, organisational goals and structures, and system requirements. All three areas identified above deal with these processes, and not surprisingly this has given rise to a profusion of scenario-based practices and representations. Yet there has been little analysis of why scenarios should be useful, let alone whether they are. Only by having such a framework for understanding what scenarios are, and what they are for, can we begin to evaluate different scenario approaches in specific development contexts. This paper is a contribution toward such a framework. We lay out a space of representational possibilities for scenarios and enumerate a set of values or criteria that are important for different uses of scenarios. We then summarise several salient representations drawn from the software engineering, HCI, and organisational process design communities to clarify how these representational choices contribute to or detract from the goals of the respective practices. Finally, we discuss how scenario representations from one area of design may be useful in others, and we discuss the relationship between these representations and other significant early-design and requirements engineering practices.     

Intelligent Identification and Resolution of Software Requirement Conflicts: Assessment and Evaluation

Considerable research has demonstrated how effective requirements engineering is critical for the success of software projects. Requirements engineering has been established and recognized as one of the most important aspects of software engineering as of late. It is noteworthy to mention that requirement consistency is a critical factor in project success, and conflicts in requirements lead to waste of cost, time, and effort. A considerable number of research studies have shown the risks and problems caused by working with requirements that are in conflict with other requirements. These risks include running overtime or over budget, which may lead to project failure. At the very least, it would result in the extra expended effort. Various studies have also stated that failure in managing requirement conflicts is one of the main reasons for unsuccessful software projects due to high cost and insufficient time. Many prior research studies have proposed manual techniques to detect conflicts, whereas other research recommends automated approaches based on human analysis. Moreover, there are different resolutions for conflicting requirements. Our previous work proposed a scheme for dealing with this problem using a novel intelligent method to detect conflicts and resolve them. A rule-based system was proposed to identify conflicts in requirements, and a genetic algorithm (GA) was used to resolve conflicts. The objective of this work is to assess and evaluate the implementation of the method of minimizing the number of conflicts in the requirements. The methodology implemented comprises two different stages. The first stage, detecting conflicts using a rule-based system, demonstrated a correct result with 100% accuracy. The evaluation of using the GA to resolve and reduce conflicts in the second stage also displayed a good result and achieved the desired goal as well as the main objective of the research.     

Constructing the Lyee method with a method engineering approach

This paper proposes an Evolution driven ME approach aiming to support the evolution of an existing method (the As–Is method) in order to obtain a new method (the To–Be method) better adapted to a given engineering situation and/or satisfying new methodogical requirements. The proposed approach is used in order to evolve the existing Lyee method into a Lyee user driven method.¹     

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.     

When bugs sing

In The Songs of Insects, Pierce (1949) described the striped ground cricket, Nemobius fasciatus-fasciatus, which chirps at a rate proportional to ambient air temperature. Twenty chirps-per-second tell us it is 31.4 °C; 16 chirps and it is 27 °C. This is a natural example of an auditory display, a mechanism for communicating data with sound. By applying auditory display techniques to computer programming we have attempted to give the bugs that live in software programs their own songs. We have developed the CAITLIN musical program auralisation system Vickers and Alty, 2002b) to allow structured musical mappings to be made of the constructs in Pascal programs. Initial experimental evaluation [Interacting with Computers (2002a,b)] showed that subjects could interpret the musical motifs used to represent the various Pascal language constructs.

In this paper we describe how the CAITLIN system was used to study the effects of musical program auralisation on debugging tasks performed by novice Pascal programmers. The results of the experiment indicate that a formal musical framework can act as a medium for communicating information about program behaviour, and that the information communicated could be used to assist with the task of locating bugs in faulty programs.