Requirements and Tools for Variability Management

Explicit and software-supported Business Process Management has become the core infrastructure of any medium and large organization that has a need to be efficient and effective. The number of processes of a single organization can be very high, furthermore, they might be very similar, be in need of momentary change, or evolve frequently. If the ad-hoc adaptation and customization of processes is currently the dominant way, it clearly is not the best. In fact, providing tools for supporting the explicit management of variation in processes (due to customization or evolution needs) has a profound impact on the overall life-cycle of processes in organizations. Additionally, with the increasing adoption of Service-Oriented Architectures, the infrastructure to support automatic reconfiguration and adaptation of business process is solid. In this paper, after defining variability in business process management, we consider the requirements for explicit variation handling for (service based) business process systems. eGovernment serves as an illustrative example of reuse. In this case study, all local municipalities need to implement the same general legal process while adapting it to the local business practices and IT infrastructure needs. Finally, an evaluation of existing tools for explicit variability management is provided with respect to the requirements identified.

Requirements of time management tools for outpatient physiotherapy practice

The effects of electronic appointment booking systems on the time management activities of health professionals have received little attention to date. We report on time management practices in three outpatient physiotherapy departments with different paper and electronic systems. The study has identified a set of time management activities and associated social behaviours common to physiotherapy departments. The convenience, flexibility and expressive nature of paper diary systems is of significant value to users, whilst the clarity and superior database functionality of electronic systems are valued by staff using this medium. The study highlights several potential barriers to the effective deployment of electronic booking systems in physiotherapy departments, including poor resource and training provision, concerns regarding restrictive diary control measures, the continued reliance on burdensome duplication procedures and the need to coordinate multiple information artefacts, which need to be addressed if such technology is to be successfully designed and deployed. Copyright © 2005 SAGE Publications (London, Thousand Oaks, CA and New Delhi)

WFIRST Coronagraph Technology Requirements: Status Update and Systems Engineering Approach

The coronagraphic instrument (CGI) on the Wide-Field Infrared Survey Telescope (WFIRST) will demonstrate technologies and methods for high-contrast direct imaging and spectroscopy of exoplanet systems in reflected light, including polarimetry of circumstellar disks. The WFIRST management and CGI engineering and science investigation teams have developed requirements for the instrument, motivated by the objectives and technology development needs of potential future flagship exoplanet characterization missions such as the NASA Habitable Exoplanet Imaging Mission (HabEx) and the Large UV/Optical/IR Surveyor (LUVOIR). The requirements have been refined to support recommendations from the WFIRST Independent External Technical/Management/Cost Review (WIETR) that the WFIRST CGI be classified as a technology demonstration instrument instead of a science instrument. This paper provides a description of how the CGI requirements flow from the top of the overall WFIRST mission structure through the Level 2 requirements, where the focus here is on capturing the detailed context and rationales for the CGI Level 2 requirements. The WFIRST requirements flow starts with the top Program Level Requirements Appendix (PLRA), which contains both high-level mission objectives as well as the CGI-specific baseline technical and data requirements (BTR and BDR, respectively)... We also present the process and collaborative tools used in the L2 requirements development and management, including the collection and organization of science inputs, an open-source approach to managing the requirements database, and automating documentation. The tools created for the CGI L2 requirements have the potential to improve the design and planning of other projects, streamlining requirement management and maintenance. [Abstract Abbreviated]Comment: 16 pages, 4 figure

Requirements Management Tools: A Quantitative Assessment

This report is primarily aimed at people with some background in Requirements Engineering or practitioners wishing to assess tools available for managing requirements. We provide a starting point for this assessment, by presenting a brief survey of existing Requirements Management tools. As a part of the survey, we characterize a set of requirements management tools by outlining their features, capabilities and goals. The characterization offers a foundation to select and possibly customize a requirements engineering tool for a software project. This report consists of three parts. In Part I we define the terms requirements and requirements engineering and briefly point out the main components of the requirements engineering process. In Part II, we survey the characteristics and capabilities of 6 popular requirements management tools, available in the market. We enumerate the salient features of each of theses tools. In Part III, we briefly describe a Synergistic Environment for Requirement Generation. This environment captures additional tools augmenting the requirements generation process. A description of these tools is provided. In the concluding section, we present a discussion defining the ideal set of characteristics that should be embodied in a requirements management tool. This report is adapted from a compendium of assignments that were prepared by the students in a Requirements Engineering class offered in the Department of Computer Science at Virginia Tech

Group and individual time management tools: what you get is not what you need

Some studies of diaries and scheduling systems have considered how individuals use diaries with a view to proposing requirements for computerised time management tools. Others have focused on the criteria for success of group scheduling systems. Few have paid attention to how people use a battery of tools as an ensemble. This interview study reports how users exploit paper, personal digital assistants (PDAs) and a group scheduling system for their time management. As with earlier studies, we find many shortcomings of different technologies, but studying the ensemble rather than individual tools points towards a different conclusion: rather than aiming towards producing electronic time management tools that replace existing paper-based tools, we should be aiming to understand the relative strengths and weaknesses of each technology and look towards more seamless integration between tools. In particular, the requirements for scheduling and those for more responsive, fluid time management conflict in ways that demand different kinds of support

Managing strategy through business process

The work presented in this paper, following an in depth review of literature, developed a set of requirements for a Dynamic Strategy Management Process. Having evaluated the existing strategy management frameworks, models, methodologies, tools and techniques, the research concluded that although all approaches reviewed collectively met all the requirements, individually none of the approaches fulfilled all of these requirements. To fulfil these dynamic strategy management process requirements, PROPHESY (Process Oriented Performance Headed Strategy) was developed. The paper describes in some detail, the evaluation of the PROPHESY process and demonstrates its application through a case study. The paper concludes that strategy should focus on creating value that is independent for each business unit. This means developing horizontal strategies that have objectives of co-ordinating business processes and developing objectives that encourage the sharing of resources and skills

Tool construction for the British Airways SEE with the O<inf>2</inf> ODBMS

Software engineering environments (SEE) support the construction and maintenance of large-scale software systems. They integrate tools for the production and maintenance of documents such as requirements definitions, architecture definitions or user manuals. Very few SEE tools meet all the developers' requirements. Some requirements that are important in practice have not been appropriately addressed. These are inter-document consistency handling, version and configuration management and cooperative work. We claim that the reason for current tools not meeting these requirements is the fact that the required database support for maintaining documents is only now becoming available. The British Airways SEE meets these new requirements. Its tools were constructed using the O2 object database management system, which has been extended to become a database management system for software engineering. We discuss the experiences we made during tool construction for this SEE

Semantics of trace relations in requirements models for consistency checking and inferencing

Requirements traceability is the ability to relate requirements back to stakeholders and forward to corresponding design artifacts, code, and test cases. Although considerable research has been devoted to relating requirements in both forward and backward directions, less attention has been paid to relating requirements with other requirements. Relations between requirements influence a number of activities during software development such as consistency checking and change management. In most approaches and tools, there is a lack of precise definition of requirements relations. In this respect, deficient results may be produced. In this paper, we aim at formal definitions of the relation types in order to enable reasoning about requirements relations. We give a requirements metamodel with commonly used relation types. The semantics of the relations is provided with a formalization in first-order logic. We use the formalization for consistency checking of relations and for inferring new relations. A tool has been built to support both reasoning activities. We illustrate our approach in an example which shows that the formal semantics of relation types enables new relations to be inferred and contradicting relations in requirements documents to be determined. The application of requirements reasoning based on formal semantics resolves many of the deficiencies observed in other approaches. Our tool supports better understanding of dependencies between requirements

Requirements traceability in model-driven development: Applying model and transformation conformance

The variety of design artifacts (models) produced in a model-driven design process results in an intricate relationship between requirements and the various models. This paper proposes a methodological framework that simplifies management of this relationship, which helps in assessing the quality of models, realizations and transformation specifications. Our framework is a basis for understanding requirements traceability in model-driven development, as well as for the design of tools that support requirements traceability in model-driven development processes. We propose a notion of conformance between application models which reduces the effort needed for assessment activities. We discuss how this notion of conformance can be integrated with model transformations