Showing papers on "Software requirements specification published in 2004"

Elaborating security requirements by construction of intentional anti-models

Abstract: Caring for security at requirements engineering time is a message that has finally received some attention recently. However, it is not yet very clear how to achieve this systematically through the various stages of the requirements engineering process. The paper presents a constructive approach to the modeling, specification and analysis of application-specific security requirements. The method is based on a goal-oriented framework for generating and resolving obstacles to goal satisfaction. The extended framework addresses malicious obstacles (called anti-goals) set up by attackers to threaten security goals. Threat trees are built systematically through anti-goal refinement until leaf nodes are derived that are either software vulnerabilities observable by the attacker or anti-requirements implementable by this attacker. New security requirements are then obtained as countermeasures by application of threat resolution operators to the specification of the anti-requirements and vulnerabilities revealed by the analysis. The paper also introduces formal epistemic specification constructs and patterns that may be used to support a formal derivation and analysis process. The method is illustrated on a Web-based banking system for which subtle attacks have been reported recently.

A survey of self-management in dynamic software architecture specifications

Abstract: As dynamic software architecture use becomes more widespread, a variety of formal specification languages have been developed to gain a better understanding of the foundations of this type of software evolutionary change. In this paper we survey 14 formal specification approaches based on graphs, process algebras, logic, and other formalisms. Our survey will evaluate the ability of each approach to specify self-managing systems as well as the ability to address issues regarding expressiveness and scalability. Based on the results of our survey we will provide recommendations on future directions for improving the specification of dynamic software architectures, specifically self-managed architectures.

Goal-Oriented Requirements Enginering: A Roundtrip from Research to Practice

Abstract: The software industry is more than ever facing the challenge of delivering WYGIWYW software (What You Get Is What You Want). A well-structured document specifying adequate, complete, consistent, precise, and measurable requirements is a critical prerequisite for such software. Goals have been recognized to be among the driving forces for requirements elicitation, elaboration, organization, analysis, negotiation, documentation, and evolution. Growing experience with goal-oriented requirements engineering suggests synergistic links between research in this area and good practice. We discuss one journey along this road from influencing ideas and research results to tool developments to good practice in industrial projects. On the way, we discuss some lessons learnt, obstacles to technonogy transfer, and challenges for better requirements engineering research and practice.

Analysis of requirements volatility during software development life cycle

Abstract: Investigating the factors that drive requirements change is an important prerequisite for understanding the nature of requirements volatility. This increased understanding will improve the process of requirements change management. We mainly focus on change analysis to identify and characterize the causes of requirements volatility. We apply a causal analysis method on change request data to develop a taxonomy of change. This taxonomy allows us to identify and trace the problems, reasons and sources of changes. Adopting an industrial case study approach, our findings reveal that the main causes of requirements volatility were changes in customer needs (or market demands), developers' increased understanding of the products, and changes in the organization policy. During the development process, we also examined the extent of requirements volatility and discovered that the rate of volatility was high at the time of requirements specification completion and while functional specification reviews were conducted.

From Object Orientation to Goal Orientation: A Paradigm Shift for Requirements Engineering

Abstract: Requirements engineering (RE) is concerned with the elicitation of the objectives to be achieved by the system envisioned, the operationalization of such objectives into specifications of services and constraints, the assignment of responsibilities for the resulting requirements to agents such as humans, devices and software, and the evolution of such requirements over time and across system families. Getting high-quality requirements is difficult and critical. Recent surveys have confirmed the growing recognition of RE as an area of primary concern in software engineering research and practice. The paper reviews the important limitations of OO modeling and formal specification technology when applied to this early phase of the software lifecycle. It argues that goals are an essential abstraction for eliciting, elaborating, modeling, specifying, analyzing, verifying, negotiating and documenting robust and conflict-free requirements. A safety injection system for a nuclear power plant is used as a running example to illustrate the key role of goals while engineering requirements for high assurance systems.

Ambiguity in Requirements Specification

Abstract: This chapter identifies the problem of ambiguity in natural language requirements specifications. After observing that ambiguity in natural language specifications is inescapable when producing computer-based system specifications, a dictionary, linguistic, and software engineering definitions of ambiguity are given. The chapter describes a full range of techniques and tools for avoiding and detecting ambiguity.

Identifying requirements conflicts and cooperation: how quality attributes and automated traceability can help

Abstract: Requirements about software attributes have numerous complex and nontrivial interdependencies. Requirements conflict with each other when they make contradicting statements about common software attributes, and they cooperate when they mutually enforce such attributes. Because software developers rarely apply formal requirements specification techniques in practice, and because reliable techniques for natural language understanding aren't available, it's generally infeasible to automatically identify conflicts and cooperation among requirements. In software development and maintenance, identifying conflicts and cooperation among requirements is challenging. Fortunately, quality attributes can help. In addition, automated traceability techniques can eliminate falsely identified conflicts and cooperation efficiently.

ERP requirements engineering practice: lessons learned

Abstract: Standard off-the-shelf requirements engineering processes have become a key to conceptualizing any integrated, corporate-wide solution based on packaged enterprise resource planning software. A generic RE model offers defined processes, suggests process stakeholders, specifies steps to accomplish tasks, indicates task dependencies, and provides standard tool support for ERP RE. Essentially, any off-the-shelf RE process is about composition and reconciliation: you start with a general set of business process and data requirements, then explore standard ERP functionality to see how closely it matches your organization's process and data needs.

Using card sorting technique to classify requirements change

Abstract: Requirements volatility is considered to be a major source of risk to the management of large and complex software projects. The ability to characterise the nature and origins of requirements change during software development is important and can lead organisations towards more effective management of changing requirements. This work focuses on a study to establish how practitioners classify requirements change requests. We used the card sorting method to identify categories of change requests that software developers use in practice. Card sorting is a knowledge elicitation method that is commonly used for capturing information about different ways of representing domain knowledge. This study has allowed us to get valuable insights into the way practitioners classify change requests and to understand their perspectives on classification. This classification is a valuable source of information in prioritizing change requests and assessing their impact. Our findings from the card sorting exercise further reveal that the criteria used for categorization are related to the role the practitioner plays in the software development team and the nature and extent of their responsibilities.

Deriving security requirements from crosscutting threat descriptions

Abstract: It is generally accepted that early determination of the stakeholder requirements assists in the development of systems that better meet the needs of those stakeholders. General security requirements frustrate this goal because it is difficult to determine how they affect the functional requirements of the system.This paper illustrates how representing threats as crosscutting concerns aids in determining the effect of security requirements on the functional requirements. Assets (objects that have value in a system) are first enumerated, and then threats on these assets are listed. The points where assets and functional requirements join are examined to expose vulnerabilities to the threats. Security requirements, represented as constraints, are added to the functional requirements to reduce the scope of the vulnerabilities. These requirements are used during the analysis and specification process, thereby incorporating security concerns into the functional requirements of the system.

Reviewing software diagrams: a cognitive study

Abstract: Reviews and inspections of software artifacts throughout the development life cycle are effective techniques for identifying defects and improving software quality. While review methods for text-based artifacts (e.g., code) are well understood, very little guidance is available for performing reviews of software diagrams, which are rapidly becoming the dominant form of software specification and design. Drawing upon human cognitive theory, we study how 12 experienced software developers perform individual reviews on a software design containing two types of diagrams: entity-relationship diagrams and data flow diagrams. Verbal protocol methods are employed to describe and analyze defect search patterns among the software artifacts, both text and diagrams, within the design. Results indicate that search patterns that rapidly switch between the two design diagrams are the most effective. These findings support the cognitive theory thesis that how an individual processes information impacts processing success. We conclude with specific recommendations for improving the practice of reviewing software diagrams.

Eliciting gaps in requirements change

Abstract: We consider requirements change due to system evolution which results from contextual forces such as the decision to standardise practices across subsidiaries of a company. Our experience with the financial branch of the French Renault group is that eliciting change requirements poses its own specific problems. We propose to model change as a set of gaps between the requirements specification of the current and the future system. Our approach is to define a generic typology of gaps to facilitate a precise definition of change requirements. It adopts a goal oriented requirements specification and shows how to customise the generic gap typology to this specific requirements representation formalism. The paper presents the approach to elicit gaps and illustrates it with the Renault case study.

Aspect-Oriented Software Development with Use Cases (Addison-Wesley Object Technology Series)

Abstract: “A refreshingly new approach toward improving use-case modeling by fortifying it with aspect orientation.” -Ramnivas Laddad, author of AspectJ in Action “Since the 1980s, use cases have been a way to bring users into software design, but translating use cases into software has been an art, at best, because user goods often don't respect code boundaries. Now that aspect-oriented programming (AOP) can express crosscutting concerns directly in code, the man who developed use cases has proposed step-by-step methods for recognizing crosscutting concerns in use cases and writing the code in separate modules. If these methods are at all fruitful in your design and development practice, they will make a big difference in software quality for developers and users alike. -Wes Isberg, AspectJ team member “This book not only provides ideas and examples of what aspect-oriented software development is but how it can be utilized in a real development project.” -MichaelWard, ThoughtWorks, Inc. “No system has ever been designed from scratch perfectly; every system is composed of features layered in top of features that accumulate over time. Conventional design techniques do not handle this well, and over time the integrity of most systems degrades as a result. For the first time, here is a set of techniques that facilitates composition of behavior that not only allows systems to be defined in terms of layered functionality but composition is at the very heart of the approach. This book is an important advance in modern methodology and is certain to influence the direction of software engineering in the next decade, just as Object-Oriented Software Engineering influenced the last.” -Kurt Bittner, IBM Corporation “Use cases are an excellent means to capture system requirements and drive a user-centric view of system development and testing. This book offers a comprehensive guide on explicit use-case-driven development from early requirements modeling to design and implementation. It provides a simple yet rich set of guidelines to realize use-case models using aspect-oriented design and programming. It is a valuable resource to researchers and practitioners alike.” -Dr. Awais Rashid, Lancaster University, U.K., and author of Aspect-Oriented Database Systems “AOSD is important technology that will help developers produce better systems. Unfortunately, it has not been obvious how to integrate AOSD across a project's lifecycle. This book shatters that barrier, providing concrete examples on how to use AOSD from requirements analysis through testing.” -Charles B. Haley, research fellow, The Open University, U.K.Aspect-oriented programming (AOP) is a revolutionary new way to think about software engineering. AOP was introduced to address crosscutting concerns such as security, logging, persistence, debugging, tracing, distribution, performance monitoring, and exception handling in a more effective manner. Unlike conventional development techniques, which scatter the implementation of each concern into multiple classes, aspect-oriented programming localizes them.Aspect-oriented software development (AOSD) uses this approach to create a better modularity for functional and nonfunctional requirements, platform specifics, and more, allowing you to build more understandable systems that are easier to configure and extend to meet the evolving needs of stakeholders.In this highly anticipated new book, Ivar Jacobson and Pan-Wei Ng demonstrate how to apply use cases-a mature and systematic approach to focusing on stakeholder concerns-and aspect-orientation in building robust and extensible systems. Throughout the book, the authors employ a single, real-world example of a hotel management information system to make the described theories and practices concrete and understandable.The authors show how to identify, design, implement, test, and refactor use-case modules, as well as extend them. They also demonstrate how to design use-case modules with the Unified Modeling Language (UML)-emphasizing enhancements made in UML 2.0-and how to achieve use-case modularity using aspect technologies, notably AspectJ.Key topics include Making the case for use cases and aspects Capturing and modeling concerns with use cases Keeping concerns separate with use-case modules Modeling use-cases slices and aspects using the newest extensions to the UML notation Applying use cases and aspects in projectsWhatever your level of experience with aspect-oriented programming, Aspect-Oriented Software Development with Use Cases will teach you how to develop better software by embracing the paradigm shift to AOSD.

PLUTO: A test methodology for product families

Abstract: The testing stage for a product belonging to a family is a crucial and expensive part of development. Yet the derivation of test cases for product families has so far received little attention. We focus here on test planning, that is the most critical part of testing. We outline a simple methodology we are developing for this purpose, called PLUTO, relying on the early requirements specification expressed as Use Cases. We also overview the related literature.

Information requirements engineering for data warehouse systems

Abstract: Information requirements analysis for data warehouse systems differs significantly from requirements analysis for conventional information systems. Based on interviews with project managers and information systems managers, requirements for a methodological support of information requirements analysis for data warehouse systems are derived. Existing approaches are reviewed with regard to these requirements. Using the method engineering approach, a comprehensive methodology that supports the entire process of determining information requirements of data warehouse users, matching information requirements with actual information supply, evaluating and homogenizing resulting information requirements, establishing priorities for unsatisfied information requirements, and formally specifying the results as a basis for subsequent phases of the data warehouse development (sub)project has been proposed. The most important sources for methodology components were four in-depth case studies of information requirements analysis practices observed in data warehousing development projects of large organizations. In this paper, these case studies are presented and the resulting consolidated methodology is summarized. While an application of the proposed methodology in its entirety is still outstanding, its components have been successfully applied in actual data warehouse development projects.

Wizard-of-Oz prototyping for co-operative interaction design of graphical user interfaces

Abstract: It is often difficult for users to specify requirements on interactivity in multimedia products. These properties are often designed by designers or software engineers and the users run the risk of playing a passive role having low influence on important decisions made. This paper presents an attempt to improve the interactive design process by using graphical Wizard-of-Oz prototyping. The study shows that graphical Wizard-of-Oz prototyping allow co-operative design and test of computer interaction early in the design process ahead of traditional programming. It also demonstrates that this type of prototyping can promote collaboration and constructive dialogue between users and designers, thus strengthening the user as a stakeholder in the development process.

Simulation-Based Performance Modeling of UML Software Architectures

Abstract: Quantitative analysis of software systems is being recognized as an important issue in the software development process. Performance analysis can help to address quantitative system analysis from the early stages of the software development life cycle, e.g, to compare design alternatives or to identify system bottlenecks. Early identification of performance problems is desirable as the cost of design change increases with the later phases of the software development cycle. This thesis addresses the problem of performance analysis of software systems described at a high level of detail. We adopt a model-based approach: starting from a software model, we derive a performance model which is then evaluated. This kind of approach has the advantage of being applicable since the early software development phases; in contrast, a measurement-based approach consisting on identifying problems by direct measurements on a running system can not. We consider software descriptions as a set of annotated Unified Modeling Language (UML) diagrams. UML is a widely used notation for describing and specifying software artifacts, and recently it is being also considered for performance evaluation purposes. We define the performance model as a process-oriented simulation model. Simulation is a powerful modeling technique which can represent general and unconstrained system models, so that the software model can be more accurately represented. An algorithm for translating UML software specifications into simulation models is described. The proposed technique defines a set of annotation of UML specifications to add quantitative, performance-oriented informations. The profile is based on the UML profile for Schedulability, Performance and Time specification. The system is described in term of Use Case, Activity and Deployment diagrams. Use Case diagrams correspond to workloads applied to the system. Activity diagrams provide a high-level description of the computation steps performed by the system, and Deployment diagrams describe the physical resources on which the computations take place. A process-oriented simulation model can then be automatically derived from the annotated specification. Execution of the simulation program provides performance results that can be directly interpreted at the UML software specification level. The described algorithm has been implemented in a prototype tool called UML-Ψ (UML Performance SImulator), which is demonstrated on a case study to show the validity of the approach. The UML-Ψ tool is written in C++ and is based on a general-purpose process-oriented simulation library. It parses annotated UML models, automatically builds the corresponding simulation model and executes it. Performance results are inserted into the original UML model as tagged values, in order to give feedback to the user.

ISO quality standards for measuring architectures

Abstract: The main concern of this paper is measuring the quality of the architectural design. The goal of this work is to use the architectural design process proposed in the unified process framework, adapting and detailing it to include the quality requirements specification at architectural level. There is general agreement on the fact that in modern applications the selection of the architecture must be addressed early in the development process, to mitigate risks. Moreover, the integration of enterprise applications is a component-based development requiring quality values associated to the services offered by the components. The services depend mostly on the architecture. In consequence, methods arise for guiding the selection or for constructing software architectures. Our approach allows associating the quality requirements (nonfunctional properties) for the architecture expressed using the ISO 9126-1 standard quality model, with the use cases, to facilitate the selection of the “key” use cases. Measures for the architecture's quality characteristics are specified in details, precising attributes, units, numerical systems and scale types. A case study of a real-time application for monitoring stock exchanges illustrates our approach. We hope that our results will be particularly useful for practitioners, such as software architects, analysts and designers.

Multiparadigm modeling in embedded systems design

Abstract: Embedded electronic systems for monitoring and control of technical processes (electronic control unit-ECU) are systems comprised of heterogeneous components (hardware, software, sensors, actuators, power electronics), thus making high demands on their development. Describing different aspects and views of the whole system, subsystem, or component requires according modeling paradigms for requirements specification, design, hardware implementation, software code generation, verification, integration, and testing. The first part of the paper surveys characteristic ECU features and describes a design strategy and the related technology, bringing out the necessity of multiparadigm modeling. Examples from automotive ECU applications are used throughout the paper. With respect to the problem that currently available tools provide insufficient support, integration strategies for multiparadigm modeling based on multiple tools are surveyed in the second part, concluding with examples from our own research activities.

Support for evolving software architectures in the ArchWare ADL

Abstract: Software that cannot evolve is condemned to atrophy: it cannot accommodate the constant revision and re-negotiation of its business goals nor intercept the potential of new technology. To accommodate change in software systems, we have defined an active software architecture to be: dynamic in that the structure and cardinality of the components and interactions are changeable during execution; updatable in that components can be replaced; decomposable in that an executing system may be (partially) stopped and split up into its components and interactions; and reflective in that the specification of components and interactions may be evolved during execution. Here we describe the facilities of the ArchWare architecture description language (ADL) for specifying active architectures. The contribution of the work is the unique combination of concepts including: a /spl pi/-calculus based communication and expression language for specifying executable architectures; hyper-code as an underlying representation of system execution that can be used for introspection; a decomposition operator to incrementally break up executing systems; and structural reflection for creating new components and binding them into running systems.

The effect of trust assumptions on the elaboration of security requirements

Abstract: Assumptions are frequently made during requirements analysis of a system-to-be about the trustworthiness of its various components (including human components). These trust assumptions can affect the scope of the analysis, derivation of security requirements, and in some cases, how functionality is realized. This work presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the secure electronic transaction (SET) specification.

Speeding up requirements management in a product software company: linking customer wishes to product requirements through linguistic engineering

Abstract: Developing large complex software products aimed for a broad market involves a great flow of wishes and requirements. The former are elicited from customers while the latter are brought forth by the developing organization. These are preferably kept separated to preserve the different perspectives. The interrelationships should however be identified and maintained to enable well-founded decisions. Unfortunately, the current manual linkage is cumbersome, time-consuming, and error-prone. This work presents a pragmatic linguistic engineering approach to how statistical natural language processing may be used to support the manual linkage between customer wishes and product requirements by suggesting potential links. An evaluation with real requirements from industry is presented. It shows that in a realistic setting, automatic support could make linkage faster for at least 50% of the links. An estimation based on our evaluation also shows that considerable time savings are possible. The results, together with the identified enhancement, are promising for improving software quality and saving time in industrial requirements engineering.

Finding reusable UML sequence diagrams automatically

Abstract: In general, software reuse is defined as "the process of creating software systems from existing software". Software reuse does more than improve productivity in software development; it also increases the quality of the resulting software systems because it uses validated artifacts. However, requirements reuse lacks tool support. Techniques for retrieving, adapting, and consolidating reusable requirements have received relatively little attention in comparison with all the work on software reuse. The work in this area has not made sufficient progress to date to determine whether such approaches may be practical and may scale up. Our REUSER project seeks to address this tool gap by seamlessly assisting analysts as they reuse UML (Unified Modeling Language) artifacts. In particular, it automates artifact retrieval.

Executable use cases: requirements for a pervasive health care system

Abstract: Many software experts argue that when we design a new system, we should create an explicit description of the environment in which the proposed system is to be used The argument becomes crucial for pervasive computing, which aims to tightly integrate systems into their environments and into the work processes they're to support However, prototypes typically provide an explicit representation only of the system itself Executable use cases, on the other hand, can also describe the environment EUCs are designed to: narrow the gap between informal ideas about requirements and the formalization that eventually and inevitably emerges during system implementation; and spur communication between users and system developers Iterative prototyping is a feasible starting point to pursue these goals But EUCs encompass both iterative prototyping and explicit environment descriptions in terms of workflow modeling This article describes a case study in which developers used EUCs to prototype an electronic patient record system for hospitals in Aarhus, Denmark

Determining software deployment parameters

Abstract: Methods and apparatus, including computer program products, for matching software requirements against target system landscape descriptions and for applying rating metrics to intermediate results during the matchmaking process. Data are received as inputs describing the requirements and dependencies of a particular software application and the resources available in the target system that may be able to meet these requirements. These data are searched for combinations of system resources that will satisfy the requirements of the application as well as optimization metrics and other requirements supplied by the user. Once a match is found, it is given a rating and ranked against any other matches.

Task-Driven Requirements in Object-Oriented Development

Abstract: There is no accepted method today that integrates requirements engineering and object-oriented development for user interface and information-intensive systems In this paper we present the major issues such a method has to deal with and illustrate them with examples from our method TORE (Task and Object-oriented Requirements Engineering)

RETNA: from requirements to testing in a natural way

Abstract: Most problems in building and refining a system can be traced back to errors in requirements. Poorly organized requirements, most often in natural language are among the major causes of failures of software projects. In this paper, we present a requirements analysis tool called RETNA and the technology behind it. RETNA accepts natural language requirements, classifies them, interacts with the user to refine them, automatically translates natural language requirements to a logical format so that they can be validated and finally generates test cases from the requirements.

Quality-evaluation models and measurements

Abstract: Quality can determine a software product's success or failure in today's competitive market. Among the many characteristics of quality, some aspects deal directly with the functional correctness or the conformance to specifications, while others deal with usability, portability, and so on. Correctness - that is, how well software conforms to requirements and specifications - is typically the most important aspect of quality, particularly when crucial operations depend on the software. Even for market segments in which new features and usability take priority, such as software for personal use in the mass market, correctness is still a fundamental part of the users' expectations. We compare and classify quality-evaluation models, particularly those evaluating the correctness aspect of quality, and examine their data requirements to provide practical guidance for selecting appropriate models and measurements.