Hadar Ziv

Using scenarios to support traceability

Software traceability is a recognized challenge in software development that can be ameliorated with requirements management tools. Traceability information can be used in a number of different software engineering activities such as software change impact analysis and testing One main challenge in the automation of software testing is mapping modeling concepts to code concepts. The level of granularity and the semantics supported by available requirements management tools do not, however, fully support such mapping, or more sophisticated requirement change impact analysis. Scenarios have been used as an alternative (and sometimes complementary) way to express requirements and system behavior throughout the phases of software development. Scenarios are used with different representation and semantics across software phases, and these can be related. This paper argues for exploring scenarios as one means for tracing requirements to code, and using this information to leverage automation of activities that benefit from traceability such as change impact analysis and software testing.

An architectural pattern for non-functional dependability requirements

Abstract We address the research question of transforming dependability requirements into corresponding software architecture constructs, by proposing first that dependability needs can be classified into three types of requirements and second, an architectural pattern that allows requirements engineers and architects to map the three types of dependability requirements into three corresponding types of architectural components. The proposed pattern is general enough to work with existing requirements techniques and existing software architectural styles, including enterprise and product-line architectures.

Programming a Software Requirements-Specification Process

Software-process programming is a comparatively new approach to the speci cation of software processes. It has attracted widespread interest but has not yet received general acceptance. For process programming to be accepted the issues involved must be better understood and its feasibility must be demonstrated. To these ends we have undertaken the development of REBUS, a prototype process program for the speci cation of software requirements. Through the development of REBUS we hoped to acquire knowledge about basic issues in process programming. In the REBUS program we hoped to o er an example of a plausible process program. In this introduction we review the advantages of process programming and argue that prototyping is an appropriate way to advance the state of the art; in the remainder of the paper we report on REBUS. A software-process program is the encoding of a software process in a formal, process-programming language [Ost87]. Software-process programming is the activity of developing software-process programs from requirements, through design, to code, followed by testing, analysis, use, and maintenance. Process programming is thus modeled after conventional programming. Processprogramming languages (i.e. process coding languages) are analogous to conventional programming languages, and process programs are analogous to conventional application programs. The di erence is that processprogramming languages and process programs apply to the domain of software processes and products. Software processes present new and challenging aspects not found in most conventional applications, for example, the need to accommodate both manual and automated activities and the need to manage highly complex, diverse, and interrelated persistent objects. The goal of process programming is to bring increased rigor and consistency to the representation and application of software development methodologies. Software development methodologies are intended to improve software development by specifying the products to be created, describing the activities to be performed, and guiding the execution of these activities and the use of the products. Examples include the Waterfall model [Roy70], Spiral model [Boe88], Jackson System Development [Jac83, Cam86], Booch Object-Oriented Design [Boo83, Boo86], Structured Analysis and Modeling [RJ77, GS86, BBD77, EFRV86], and Structured Design [Mye78, Ber78]. Several problems prevent current software methodologies from being fully and generally successful. The speci cations of software processes and products are too often semi-formal or informal (if speci ed at all), the processes rely on manual interpretation and control, and the products may be managed and accessed haphazardly. A process may not be clearly understood, and to the extent that it is understood it may be di cult to modify e ectively. Consequently, software processes are often executed uncertainly and inconsistently, and software products are more likely to be incomplete, invalid, or incorrect. The potential advantages of process programming derive from the formality of process-programming languages and process programs. Process-programming languages are de ned by formal syntax and precise semantics; process programs are thus amenable to analysis and veri cation and should facilitate communication and education. Process programs are also potentially machine-executable. This would enable them to be executed in a consistent way, and allow them to be e ectively tested, debugged, and reused. Finally, it may be possible to apply conventional tools and techniques to

Towards traceability of model-based testing artifacts

Practitioners regard software testing as the central means for ensuring that a system behaves as expected. Due to the recent widespread adoption of model-driven development (MDD), code is no longer the single source for selecting test cases. Testing against original expectations can be done with model-based testing that adopts high-level models as the basis for test generation. In addition to test generation, challenges to model-based testing include creation and maintenance of traceability information among test-related artifacts. Traceability is required to support activities such as result evaluation, regression testing and coverage analysis. MDD and model transformation solutions address the traceability problem by creating relationships among transformed artifacts throughout the transformation process. This paper proposes an approach that leverages model transformation traceability techniques to create fine-grained relationships among model-based testing artifacts. Relationships are created during the test generation process. Their fine granularity enables the support for result evaluation, coverage analysis and regression testing.

A model-based regression test selection technique

Throughout their life cycle, software artifacts are modified, and selective regression testing is used to identify the negative impact of modifications. Code-based regression test selection retests test cases sub-set that traverse code modifications. It uses recovered relationships between code parts and test cases that traverse them to locate test cases for retest when code is modified. Broad adoption of model-centric development has created opportunities for software testing. It enabled driving testing processes at higher abstraction levels and demonstrating code to model compliance by means of Model-Based Testing (MBT). Models also evolve, so an important activity of MBT is selective regression testing. It selects test cases for retest based on model modification, so it relies on relationships between model elements and test cases that traverse those elements to locate test cases for retest. We contribute an approach and prototype that during test case generation creates fine-grained traceability relationships between model elements and test cases, which are used to support model-based regression test selection.

MbSRT2: Model-Based Selective Regression Testing with Traceability

Widespread adoption of model-centric development has created opportunities for software testing, with Model-Based Testing (MBT). MBT supports the generation of test cases from models and the demonstration of model and source-code compliance. Models evolve, much like source code. Thus, an important activity of MBT is selective regression testing, which selects test cases for retest based on model modifications, rather than source-code modifications. This activity explores relationships between model elements and test cases that traverse those elements to locate retest able test cases. We contribute an approach and prototype to model-based selective regression testing, whereby fine-grain traceability relationships among entities in models and test cases are persisted into a traceability infrastructure throughout the test generation process: the relationships represent reasons for test case creation and are used to select test cases for re-run. The approach builds upon existing regression test selection techniques and adopts scenarios as behavioral modeling perspective. We analyze precision, efficiency and safety of the approach through case studies and through theoretical and intuitive reasoning.

SRRS: a recommendation system for security requirements

Despite the availability of approaches to specifying security requirements, we have identified a lack of comparative studies of those approaches and, subsequently, lack of guidance and useful tools to determine the most appropriate approach for a specific project. In this paper we propose SRRS (Security Requirements Recommendation System), which takes user input about the most desirable characteristics for their project and recommends the most appropriate approach. We provide an example of applying our system, and show how the SRRS process works in general.

An Automated Approach for Goal-driven, Specification-based Testing

This paper presents a specification-based approach that addresses several known challenges including false positives and domain knowledge errors. Our approach begins with a goal graph and plans. Source code is annotated with goals and events and precompiled to emit those at run time. Plans are automatically translated into a rule-based recognizer. An oracle is produced from the pre- and postconditions associated with the plans goals. When the program is executed, goals and events are emitted and automatically tested against plans and oracles. The concept is demonstrated on a small example and a larger publicly available case study

CCARCH: Architecting Common Criteria Security Requirements

As technology continues to evolve, so do different entities that threaten the security of this technology. We believe that in order to build dependable software security should be treated just as any other important aspect of a system; to do this we must emphasize it at the beginning of our development cycle and be able to carry these security requirements down the cycle. We focus on a technique known as the Common Criteria, which allows for the development of security requirements. We extend the capabilities of Common Criteria beyond the requirements phase, to allow us to take security requirements into further stages of the cycle. In this paper we describe CCARCH, a technique accompanied by a set of tools, that takes Common Criteria expressed security requirements to the architectural level. Our approach aids in making the usage of Common Criteria more beneficial and applicable.

Towards supporting the architecture design process through evaluation of design alternatives

This paper addresses issues involved when an architect explore alternative designs including non-functional requirements; in our approach, non-functional requirements are expressed as state-charts. Non-functional requirements greatly impact the resulting design of a system because they naturally conflict with each other, crosscut the system at multiple points, and may be satisfied in a number of different ways. This makes correctly designing them early in the software lifecycle critical, since correcting them later can be extremely costly. Our approach supports an architect generating and evaluating many different design alternatives. This explorative process is not well supported by current techniques, which focus on documenting the result of this process, but not on assisting the designer during this process. We present an architecture-based approach that supports exploration of non-functional requirements expressed as statecharts. Our approach captures design alternatives of non-functional requirements separately, composes different system designs from these alternatives using a novel weaving technique, and analyzes the resulting design for specific qualities using simulation.