Eliciting dependability requirements: a control cases based approach

At present,great demands are posed on software dependability.But how to elicit the dependability requirements is still a challenging task.This paper proposes a novel approach to address this issue.The essential idea is to model a dependable software system as a feedforward-feedback control system,and presents the use cases+control cases model to express the requirements of the dependable software systems.In this model,while the use cases are adopted to model the functional requirements,two kinds of control cases(namely the feedforward control cases and the feedback control cases)are designed to model the dependability requirements.The use cases+control cases model provides a unified framework to integrate the modeling of the functional requirements and the dependability requirements at a high abstract level.To guide the elicitation of the dependability requirements,a HAZOP based process is also designed.A case study is conducted to illustrate the feasibility of the proposed approach.     

A specification pattern for use cases

In this paper, general formats and guidelines are proposed, in an attempt to ameliorate the impact of frequently observed difficulties during the specification of use cases generated using “natural language” for the documentation of system functionality. The various writing styles derived from the multiple grammatical alternatives found in the Spanish language and the terminological diversity that characterises this language tend to reduce the clarity of text in a use-case specification. Thus, the purpose of its use in the different stages of development in a software system or component is seriously affected. However, even if this study has been made specifically for the Spanish language, it could be easily generalised to any language whose sentences are of the form subject/predicate. In order to control these problems, the use of a specification pattern supported by a series of guidelines on style and terminology is proposed for drafting use cases. Additionally, various degrees of refinement are suggested to guide specifiers towards obtaining a use case written according to this pattern.     

MOQARE: misuse-oriented quality requirements engineering

This work presents MOQARE (misuse-oriented quality requirements engineering), a method to explore quality requirements. The aim of MOQARE is to support intuitive and systematic identification of quality requirements. It was developed by integrating and adapting concepts from other methods (like Misuse Cases). It provides a general conceptual model of quality requirements, and a checklist-based process for deriving them in a top-down fashion. This derivation starts from business goals and vague quality requirements and delivers detailed requirements. MOQARE applies to requirements on the system to be developed requirements, but also derives requirements on the development process, including administration and maintenance. It considers normal and extreme use. The relationships among these requirements are modeled in a Misuse Tree. MOQARE has shown its merits in several case studies, one of which is presented here.     

Comparing attack trees and misuse cases in an industrial setting

The last decade has seen an increasing focus on addressing security already during the earliest stages of system development, such as requirements determination. Attack trees and misuse cases are established techniques for representing security threats along with their potential mitigations. Previous work has compared attack trees and misuse cases in two experiments with students. The present paper instead presents an experiment where industrial practitioners perform the experimental tasks in their workplace. The industrial experiment confirms a central finding from the student experiments: that attack trees tend to help identifying more threats than misuse cases. It also presents a new result: that misuse cases tend to encourage identification of threats associated with earlier development stages than attack trees. The two techniques should therefore be considered complementary and should be used together in practical requirements work.     

Improving the detection of requirements discordances among stakeholders

This paper introduces a technique to identify requirements discordances among stakeholders. This technique is validated in experiments. An extended version of the goal-oriented requirements elicitation method, named attributed goal-oriented analysis (AGORA), and its supporting tool are used. Two types of requirements discordances among stakeholders are defined: the first arises from the different interpretations by the stakeholders and the second is the result of different evaluations of preferences. Discordances are detected by the preference matrices in AGORA. Each preference matrix represents both preferences of each stakeholder and the estimated preferences of other stakeholders. A supporting tool for the AGORA method was developed. This tool is a groupware that seamlessly combines face-to-face meetings for goal elicitation and distributed individual sessions for scoring preference values. The experimental results showed that the proposed classification of discordances was sound and that the occurrences of the requirements discordances could be detected by preference matrices.     

Animation of requirements specifications

Requirements analysis has been recognized as one of the most critical and difficult tasks in software engineering. The need for tool support is essential. This paper reports some work done to provide such support for interpretation and validation of requirements specifications by animation. The Animator provides facilities for the selection and execution of a transaction to reflect the specified behaviour of a particular scenario specified in the requirements specification. Actions are described in terms of input-output mappings and or functions with pattern matching. Simple rules can be specified to control the triggering of actions. In addition, facilities are provided to replay and interact with transactions. User interaction during animation includes the ability to change data values or role play selected actions as desired. A full graphical interface is supported. The approach has been tested by the provision of an Animator for the requirements analysis method CORE and an associated ‘Analyst Workstation’. Animation has been tested on a number of small examples and a major case study. This paper describes the Animator, justifies the approach taken and discusses experience and future work.     

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.     

基于用例模型的面向对象需求分析

面向对象方法正在逐渐取代传统的方法,日益成为当今软件工程领域的主流方法。在系统需求设计方法中用例模型已成为获取系统需求的主要技术,通过用例模型的建立和对用例的分析软件开发者可以准确地了解用户需求和系统功能。它是用户和软件开发者一起剖析系统需求的关键一步,可以推动需求分析后各阶段的开发工作。     

需求分析与获取的方法学与技术

本文给出需求工程的一般框架，在对需求分类的基础上主要讨论非功能性（即非行为性）需求，提出对软件需求规范和分析技术的要求，并强调对现有相关工作评价的其中两个方面。     

User viewpoint modelling: understanding and representing user viewpoints during requirements definition

There has been increasing awareness of the impact of the early stages of systems development on the quality of information systems. A critical early activity is requirements definition, when the requirements for an information system are determined. Traditional requirements capture techniques do not support the collaborative nature of requirements definition or the emergent nature of requirements themselves. This paper focuses on viewpoint development as a means of resolving some of the difficulties of requirements definition. It proposes a user viewpoint model for capturing and representing the viewpoints of users during requirements acquisition. The model can facilitate communication and interaction between analysts and users and help build a shared understanding of requirements. It can be used to structure the requirements acquisition process. The model provides for evaluation of requirements acquisition techniques to guide the selection of appropriate techniques for developing user viewpoint models. The paper reports a multiple-case study of requirements definition efforts that examined user viewpoint development in practice and used the cases to validate empirically the concepts of the user viewpoint model. The implications of the case study findings for requirements definition practice are discussed, and some areas for future research are identified.     

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.     

Legally “reasonable” security requirements: A 10-year FTC retrospective

Growth in electronic commerce has enabled businesses to reduce costs and expand markets by deploying information technology through new and existing business practices. However, government laws and regulations require businesses to employ reasonable security measures to thwart risks associated with this technology. Because many security vulnerabilities are only discovered after attacker exploitation, regulators update their interpretation of reasonable security to stay current with emerging threats. With a focus on determining what businesses must do to comply with these changing interpretations of the law, we conducted an empirical, multi-case study to discover and measure the meaning and evolution of “reasonable” security by examining 19 regulatory enforcement actions by the U.S. Federal Trade Commission (FTC) over a 10 year period. The results reveal trends in FTC enforcement actions that are institutionalizing security knowledge as evidenced by 39 security requirements that mitigate 110 legal security vulnerabilities.     

Promoting software quality through a human,social and organisational requirements elicitation process

Human, social and organisational (HSO) factors play a decisive role in software development in terms of determining functional and non-functional characteristics of software products. The significance of these factors is underlined by the need to produce applications that fit nicely in a working setting, supporting the working procedures followed and promoting users' content and productivity. In this context, a new requirements elicitation process is proposed, a part of which utilises a short-scale ethnography analysis. The process introduces specific steps for recording HSO factors based on certain software quality characteristics that are treated as principal components for conducting requirements identification. The output of the process is the HSO document, which can be used in conjunction with the classic requirements document to identify structural and functional aspects of the system.     

Formal analysis of the Shlaer-Mellor method: Towards a toolkit of formal and informal requirements specification techniques

In this paper, we define a number of tools that we think belong to the core of any toolkit for requirements engineers. The tools are conceptual and hence, they need precise definitions that lay down as exactly as possible what their meaning and possible use is. We argue that this definition can best be achieved by a formal specification of the tool. This means that for each semi-formal requirements engineering tool we should provide a formal specification that precisely specifies its meaning. We argue that this mutually enhances the formal and semi-formal technique: it makes formal techniques more usable and, as we will argue, at the same time simplifies the diagram-based notations.At the same time, we believe that the tools of the requirements engineer should, where possible, resemble the familiar semi-formal specification techniques used in practice today. In order to achieve this, we should search existing requirements specification techniques to look for a common kernel of familiar semi-formal techniques and try to provide a formalisation for these.In this paper we illustrate this approach by a formal analysis of the Shlaer-Mellor method for object-oriented requirements specification. The formal specification language used in this analysis is LCM, a language based on dynamic logic, but similar results would have been achieved by means of another language. We analyse the techniques used in the information model, state model, process model and communication model of the Shlaer-Mellor method, identify ambiguities and redundancies, indicate how these can be eliminated and propose a formalisation of the result. We conclude with a listing of the tools extracted from the Shlaer-Mellor method that we can add to a toolkit that in addition contains LCM as formal specification technique.     

Reconciling software requirements and architectures with intermediate models

Little guidance and few methods are available for the refinement of software requirements into an architecture satisfying those requirements. Part of the challenge stems from the fact that requirements and architectures use different terms and concepts to capture the model elements relevant to each. In this paper we will present CBSP, a lightweight approach intended to provide a systematic way of reconciling requirements and architectures using intermediate models. CBSP leverages a simple set of architectural concepts (components, connectors, overall systems, and their properties) to recast and refine the requirements into an intermediate model facilitating their mapping to architectures. Furthermore, the intermediate CBSP model eases capturing and maintaining arbitrarily complex relationships between requirements and architectural model elements, as well as among CBSP model elements. We have applied CBSP within the context of different requirements and architecture definition techniques. We leverage that experience in this paper to demonstrate the CBSP method and tool support using a large-scale example.     

Obsolete software requirements

ContextCoping with rapid requirements change is crucial for staying competitive in the software business. Frequently changing customer needs and fierce competition are typical drivers of rapid requirements evolution resulting in requirements obsolescence even before project completion.ObjectiveAlthough the obsolete requirements phenomenon and the implications of not addressing them are known, there is a lack of empirical research dedicated to understanding the nature of obsolete software requirements and their role in requirements management.MethodIn this paper, we report results from an empirical investigation with 219 respondents aimed at investigating the phenomenon of obsolete software requirements.ResultsOur results contain, but are not limited to, defining the phenomenon of obsolete software requirements, investigating how they are handled in industry today and their potential impact.ConclusionWe conclude that obsolete software requirements constitute a significant challenge for companies developing software intensive products, in particular in large projects, and that companies rarely have processes for handling obsolete software requirements. Further, our results call for future research in creating automated methods for obsolete software requirements identification and management, methods that could enable efficient obsolete software requirements management in large projects.