Some believe that Requirements Engineering (RE) for a computer-based system (CBS) should be done upfront, producing a complete requirements specification before any of the CBS’s software is written. A common complaint is that (1) new requirements never stop coming; so upfront RE goes on forever with an ever growing scope. However, data show that (2) the cost to modify written software to include a new requirement is at least 10 times the cost of writing the software with the requirement included from the start; so upfront RE saves development costs, particularly if the new requirement is one that was needed to prevent a failure of the implementation of a requirement already included in the scope. The scope of a CBS is the set of requirements that drive the CBS’s implementation. We believe that both (1) and (2) are correct, but each is about a different category of requirements, (1) scope determininG (G) or (2) scope determineD (D), respectively. Reexamination of the reported data of some past case studies through the lens of these categories indicates that when a project fails, a large majority of its defects were due to missing D requirements, and when a project succeeds, the project focused its RE on finding all of its D requirements. The hypothesis that waterfall methods (WMs), with their upfront RE, do a better job of avoiding missing D requirements in developing CBSs than do agile methods (AMs) was not supported by the data from 8 WM projects and 8 similar AM projects in one company. In fact, the null hypothesis, that there is no difference between WMs and AMs in avoiding missing D requirements in developing CBSs, cannot be rejected for any logically posssible assignment of the collective data from the 16 projects to 16 specific projects. It appears that intimate knowledge of the domain and development of a CBS is necessary to be able to classify the CBS’s defects arising from missing requirements as of category D or G with respect to (w.r.t.) the CBS’s scope. Finally, software and requirement engineers are able to learn from a half-hour lecture about D and G requirements to correctly categorize most requirements of a familiar CBS as D or G, w.r.t. the CBS’s scope.

Requirement elicitation can be done by individuals or by groups. Computer-based system development life-cycle models suggest having people working together for many steps. Also, recommendations about analysis and design methods indicate that some processes could take advantage of group work. In requirements engineering, groups are suggested for requirements elicitation. From the software and the requirements engineering viewpoints, and in turn for companies, a relevant overall research question is “What is a suitable size for a requirements elicitation group?” Our goal was to answer this question, first by looking for available guidelines in textbooks and secondly by investigating requirements elicitation in companies. To address the research question, we conducted two studies. The first was a review of most widely adopted software and requirements engineering textbooks. The second was a study aimed at identifying factors affecting group size for requirements elicitation, based on an online questionnaire submitted to professional analysts. The review of the textbooks showed that very few give advice on the number of analysts to involve in requirements elicitation sessions. When they do, guidelines are quite general and not supported by empirical data. According to data gathered from the questionnaire, most companies use and suggest using small groups. Data also allowed identifying four categories of factors useful to make decisions about requirements elicitation group sizes: people, relation, project, and output. Both the textbook review and the data from the questionnaire say that it is better to aim for small groups than to have individual analysts working separately. The ideal number of analysts for a requirements elicitation session appears to be 2, but large groups are necessary in some cases. Factors in all the four categories have to be considered in deciding the size of groups.

This paper explains the importance (1) of full user-space identification with categorization in requirements engineering (RE) and of ensuring that the categorization is a partition of the user space, (2) of the creation and application of user-space-covering personas in RE, (3) of the use of grounded analysis to do RE to produce a specification as a grounded theory, and (4) of privacy and security features in computer-based systems. Then it gives the steps of a grounded analysis method for doing user-space identification with categorization and producing personas as a grounded theory that is describing the classes of users for a computer-based system. The paper summarizes a case study of an iterative application of this method to arrive at a set of user-space-covering personas for privacy and security features in computer-based systems, and it shows how these personas can be used to inform RE for these features. The full case study and the descriptions of the personas are found in the appendices.

Context and Motivation Natural language processing has been used since the 1980s to construct tools for performing natural language (NL) requirements engineering (RE) tasks. The RE field has often adopted information retrieval (IR) algorithms for use in implementing these NL RE tools. Problem Traditionally, the methods for evaluating an NL RE tool have been inherited from the IR field without adapting them to the requirements of the RE context in which the NL RE tool is used. Principal Ideas This panel discusses the problem and considers the evaluation of tools for a number of NL RE tasks in a number of contexts. Contribution The discussion is aimed at helping the RE field begin to consistently evaluate each of its tools according to the requirements of the tool's task.

Context and Motivation Systematically engineering a good user experience (UX) into a computer-based system under development demands that the user requirements of the system reflect all needs, including emotional, of all stakeholders. User requirements address two different types of qualities: pragmatic qualities (PQs), that address system functionality and usability, and hedonic qualities (HQs) that address the stakeholder's psychological well-being. Studies show that users tend to describe such satisfying UXes mainly with PQs, and that some users seem to believe that they are describing a HQ when they are actually describing a PQ. Question/Problem The problem is to see if classification of any user requirement as PQ-related or HQ-related is difficult, and if so, why. Principal Ideas/Results We conducted a controlled experiment in which twelve requirements-engineering and UX professionals, hereinafter called "classifiers" classified each of 105 user requirements as PQ-related or HQ-related. The experiment shows that neither (1) a classifier's involvement in the project from which the requirements came nor (2) the classifier's use of a detailed model of the qualities in addition to the standard definitions of "PQ" and "HQ" has a positive effect on the consistency of the classifier's classification with that of others. Contribution The experiment revealed that classification of user requirements is a lot harder than initially assumed.

A primary goal of research in usable security and privacy is to understand the differences and similarities between users. While past researchers have clustered users into different groups, past categories of users have proven to be poor predictors of end-user behaviors. In this paper, we perform an alternative clustering of users based on their behaviors. Through the analysis of data from surveys and interviews of participants, we identify five user clusters that emerge from end-user behaviors-Fundamentalists, Lazy Experts, Technicians, Amateurs and the Marginally Concerned. We examine the stability of our clusters through a survey-based study of an alternative sample, showing that clustering remains consistent. We conduct a small-scale design study to demonstrate the utility of our clusters in design. Finally, we argue that our clusters complement past work in understanding privacy choices, and that our categorization technique can aid in the design of new computer security technologies.

One of the factors that is supposed to have a significant effect on an individual's effectiveness during requirements engineering activities is knowledge of the problem being solved by the system to be built, i.e., domain knowledge. Nevertheless, domain knowledge is a double-edged sword. While in-depth domain knowledge facilitates understanding the details of the problem, in-depth domain knowledge can promote falling for tacit assumptions of the domain and overlooking the obvious. On the other hand, lack of domain knowledge can facilitate more innovative out-of-the-domain-box idea generation. This paper describes a case study carried out in industry of the idea generation part of a requirements idea brainstorming session conducted by a team deliberately constructed with four domain experts supplied by the company participating in the case study and with four domain ignorants supplied by the authors. The results support the conclusion that having a team consisting of a mix of domain experts and domain ignorants improves the effectiveness of the idea generation part of requirements idea brainstorming.

It is believed that the effectiveness of requirements engineering activities depends at least partially on the individuals involved. One of the factors that seems to influence an individual's effectiveness in requirements engineering activities is knowledge of the problem being solved, i.e., domain knowledge. While a requirements engineer's having in-depth domain knowledge helps him or her to understand the problem easier, he or she can fall for tacit assumptions of the domain and might overlook issues that are obvious to domain experts. This paper describes a controlled experiment to test the hypothesis that adding to a requirements elicitation team for a computer-based system in a particular domain, requirements analysts that are ignorant of the domain improves the effectiveness of the requirements elicitation team. The results, although not conclusive, show some support for accepting the hypothesis. The results were analyzed also to determine the effect of creativity, industrial experience, and requirements engineering experience. The results suggest other hypotheses to be studied in the future.

The paper describes the quotations gathered during interviews and focus groups during a consulting engagement to help the client improve its requirements engineering (RE) process. The paper describes also a model of the software lifecycle derived from a Michael Jackson quotation, a model that explains about 95% of the quotations that we gathered. In particular, it explains why basic requirements determination is unstoppable and how management attempts to stop RE lead to the phenomena that are described by the quotations and less than optimal requirements specifications.

Anyone who has built or remodeled a house and has developed or enhanced SW must have noticed the similarity of these activities.This talk describes some lessons about requirements engineering I learned while being a customer in a house building and two house remodeling.The biggest problem is to avoid very expensive requirements creep.The main lesson is the importance of the customer insisting on following a full requirements engineering process, including goal identification, requirements elicitation, analysis, and specification, and validation of the specification.A secondary lesson is that a customer has an important role in requirements engineering and he or she sometimes needs to learn that role.

This paper describes the experiences of the first author in leadership requirements engineering (RE) roles in the developments of two consecutive versions of one software product in one company. The two developments differed in the amounts and the quality of their upfront RE and in their final results. The paper notes a correlation between the quantity and quality of RE and the quality of the final results in a development. The paper concludes with some lessons learned from the experiences and from the differences.

One thing that keeps many software-development organizations from doing serious requirements engineering before beginning development is the perception that doing requirements engineering wastes time and delays getting on to the real work, designing and programming. The first third of this paper presents anecdotal and case study evidence that upfront RE pays off big. The second third is a discussion on structural and cultural barriers to industrial adoption of RE practices. The final third is a free-wheeling discussion on these and related issues

Anyone who has taught object-oriented domain analysis or any other software process requiring concept identification has undoubtedly observed that some students just don't get it. Our evaluation of the work of over 740 University of Waterloo students on over 135 software requirements specifications during the last four years supports this same observation. The students' task was to specify a telephone exchange or a voice-over-IP telephone system and the related accounts management subsystem, based on models they developed using object-oriented analysis. A detailed comparative study of three much smaller specifications, all of an elevator system, suggests that object orientation is poorly suited to domain analysis, even of small-sized domains, and that the difficulties we have observed are independent both of the size of the system under specification and of the overall abilities of the students.

The Second International Workshop on From SofTware Requirements to Architectures (STRAW'03) was held in Portland, Oregon, USA on 9 May 2003 just after the Twenty-Fifth International Conference on Software Engineering (ICSE'03). This brief paper outlines the motivation, goals, and organization of the workshop.

We outline a systematic approach to defining, eliciting, and specifying the structure and the information content of the electronic health record (EHR). The paper presents a scheme for specifying a uniform, but extensible EHR and for eliciting both the structure and contents of this EHR. The next step will be to carry out the proposed process with health-care providers to begin to put some order into health records and to allow specifications of families of interacting HI applications.

We comment on the experimental design and the result of the paper mentioned in the title. Our purpose is to show interested readers examples of what can go wrong with experiments in software research and how to avoid the attending problems.

This paper describes an extension to ditroff/ffortid, a system for formatting bi-directional text in Arabic, Hebrew and Persian. The previous version of the system is able to format mixed left-to-right and right-to-left text using fonts with separated letters or with connecting letters and only connection stretching, achieved by repeating fixed-length baseline fillers. The latest extension adds the abilities to stretch letters themselves, as is common in Arabic, Hebrew and Persian calligraphic printing, and to slant the baselines of words, as is common in Persian calligraphic printing. The extension consists of modifications in ffortid that allow it to interface with (1) dynamic PostScript fonts to which one can pass to the outline procedure for any stretchable and/or connected letter, parameters specifying the amounts of stretch for the letter itself and/or for the connecting parts of the letter, and (2) PostScript fonts whose characters are slanted so that merely applying show to a word ends up printing that entire word on a single slanted baseline. As a self-test, this paper was formatted using the described system, and it contains many examples of text written in Arabic, Hebrew and Persian. Copyright © 1999 John Wiley & Sons, Ltd.

This paper describes a pragmatic, rigorous integration of the mathematical specification language Z with well-known object modeling notations and an object-oriented variant of statecharts. The goal is to preserve the abstraction and flexibility of widely-used design notations while being able to embed the precision and rigor of mathematical specification at selected places. The integration between the notations is based on a mapping between entities of the three models.

In this paper we show how a real-time time-sharing RtTS architecture can be very useful in resolving many of the formidable problems generally posed by complex real-time systems. In particular, we address dynamic multiple job systems, running on shared-memory multi-processor platforms. Each job is multitasked, with task characteristics assumed to be complex, e.g. some critical, some dependent, some aperiodic. Each job may also have multiple states, and may support several alternate modes of operation. Concurrent job sets, modes, states, and even available processor capacities, are all assumed dynamic. To accommodate such complexities, the RtTS architecture adopts a practical divide-and-conquer approach, which is shown to be very effective. The architecture incorporates three distinct and independent software control layers, which together facilitate automatic near-optimal mode selection, dynamic load-balancing, and reliable real-time time-sharing, in a fully integrated manner. The job-oriented strategy allows each job to be developed independently, as a black box with uniform control requirements, herein described. The unique capabilities of this RtTS architecture are illustrated in a dynamic multimedia context, where it is shown to have several advantages over conventional dynamic load-balancing techniques, in supporting complex task characteristics, best-effort system values, dynamic critical task sets, scalability, and portability.

Two independently derived denotational semantics for Prolog are contrasted, Arbab and Berry's for the full language and Nicholson and Foo's for a databaseless language. Using the ideas suggested by the former, the latter can be easily extended to include the database operations.

In this research in design automation, two views are employed as the requirements of a system-namely, the functional requirements and the operations concept. A requirement analyst uses data flow diagrams and system verification diagrams (SVDs) to represent the functional requirements and the operations concept, respectively. System Architect's Apprentice (SARA) is an environment-supported method for designing hardware and software systems. A knowledge-based system, called the design assistant, was built to help the system designer to transform requirements stated in one particular collection of design languages. The SVD requirement specification features and the SARA design models are reviewed. The knowledge-based tool for synthesizing a particular domain of SARA design from the requirements is described, and an example is given to illustrate this synthesis process. This example shows the rules used and how they are applied. An evaluation of the approach is given.>

A technology for automatically assembling large software libraries which promote software reuse by helping the user locate the components closest to her/his needs is described. Software libraries are automatically assembled from a set of unorganized components by using information retrieval techniques. The construction of the library is done in two steps. First, attributes are automatically extracted from natural language documentation by using an indexing scheme based on the notions of lexical affinities and quantity of information. Then a hierarchy for browsing is automatically generated using a clustering technique which draws only on the information provided by the attributes. Due to the free-text indexing scheme, tools following this approach can accept free-style natural language queries.>

Abstract Creating back‐of‐the‐book indexes is a difficult task involving intelligent and clerical processes. Programs have generally not achieved the level of intelligence required to perform the intelligent process of selecting terms for the index. Semi‐automatic indexing programs perform the clerical process of preparing entries once the terms have been selected. The programs do not provide assistance in term determination and most require flooding the text with indexing commands. indx differs from other semi‐automatic indexing programs mainly because it does not require the insertion of indexing commands into the text to be indexed. The method by which indx assists in the creation of an index is introduced and compared with the characteristics of the other programs. This method includes the use of a program that aids the term determination process. The design, implementation, and application of indx are presented. Areas in which indx may be improved or enhanced are identified. An index of this paper created with indx is included as an example.

An axiomatic semantic definition is given of the replacement model of exception handling in an expression-oriented language. These semantics require only two new proof rules for the most general case. An example is given of a program fragment using this model of exception handling, and these rules are used to verify the consistency of the fragment and its specification.

In carrying out SDC's Formal Development Method, one writes a specification of a system under design in the Ina Jo™ specification language and proves that the specification meets the requirements of the system. This paper develops an abstract machine model of what is specified by a level specification in an Ina Jo specification. It describes the state as defined by the front matter, computations as defined by initial states and transforms, and invariants, criteria, and constraints as properties of computations. The paper then describes a number of formal design methods and the kinds of abstractions that they require. For each of these kinds of abstractions, there is a characteristic relationship between refinements that should be proved as one is carrying out the method.

DITROFF/FFORTID , a collection of pre- and postprocessors for the UNIX DITROFF (Device Independent Typesetter RunOFF) is described. DITROFF/FFORTID permits formatting of text involving a mixture of languages written from left to right and from right to left, such as English and Hebrew. The programs are table driven or macro-generated to permit them to be used for any languages written from left to right and from right to left so long as fonts with the proper character sets can be mounted on a typesetting device supported by DITROFF . The preprocessors are set up to permit phonetic, unidirectional input of all of the alphabets needed using only the two alphabets (each case counts as an alphabet) available on the input device. These macro-generated preprocessors can be adjusted to the user's pronunciation, the language's rules about a letter's form, depending on its position in the word, and the language of the user's input keyboard. The postprocessor is set up to properly change direction of formatting when the text switches to a language written in a different direction. The collection of programs is also designed to allow use of any of DITROFF 's preprocessors, such as PIC , EQN , TBL , and the various device drivers.

This paper presents a new model for exception handling, called the replacement model. The replacement model, in contrast to other exception-handling proposals, supports all the handler responses of resumption, termination, retry, and exception propagation, within both statements and expressions, in a modular, simple, and uniform fashion. The model can be embedded in any expression-oriented language and can also be adapted to languages which are not expression oriented with almost all the above advantages. This paper presents the syntactic extensions for embedding the replacement model into Algol 68 and its operational semantics. An axiomatic semantic definition for the model can be found in [27].

The question as to the correct block exit strategy, retention or deletion, is resolved by formally comparing the contour model and the stack model, each of which implements one of the strategies, to the copy rule, a formal definition of block structuring.