Software engineers must systematically account for the broad scope of environmental behavior, including nonfunctional requirements, intended to coordinate the actions of stakeholders and software systems. The Inquiry Cycle Model (ICM) provides engineers with a strategy to acquire and refine these requirements by having domain experts answer six questions: who, what, where, when, how, and why. Goal-based requirements engineering has led to the formalization of requirements to answer the ICM questions about when, how, and why goals are achieved, maintained, or avoided. In this article, we present a systematic process called Semantic Parameterization for expressing natural language domain descriptions of goals as specifications in description logic. The formalization of goals in description logic allows engineers to automate inquiries using who, what, and where questions, completing the formalization of the ICM questions. The contributions of this approach include new theory to conceptually compare and disambiguate goal specifications that enables querying goals and organizing goals into specialization hierarchies. The artifacts in the process include a dictionary that aligns the domain lexicon with unique concepts, distinguishing between synonyms and polysemes, and several natural language patterns that aid engineers in mapping common domain descriptions to formal specifications. Semantic Parameterization has been empirically validated in three case studies on policy and regulatory descriptions that govern information systems in the finance and health-care domains.

When defining a new system, the history and functionality of the system to be replaced should be considered. This avoids repeating errors and neglecting important system functionality. The properties and the rationale behind the existing system are typically elicited by analysing concrete system usage-scenarios. The results of the analysis of the existing system are typically represented using conceptual models. To establish conceptual models of high quality, reviewing the models is common practice. The problem faced with when reviewing conceptual models, is that the reviewer can not assess and therefore understand the basis (concrete system usage) on which the conceptual models where build.

One key to improving high-performance computing (HPC) productivity is finding better ways to measure it. We define productivity in terms of mission goals, i.e., greater productivity means that more science is accomplished with less cost and effort. Traditional software productivity metrics and computing benchmarks have proven inadequate for assessing or predicting such end-to-end productivity. In this paper we introduce a new approach to measuring productivity in HPC applications that addresses both development time and execution time. Our goal is to develop a public repository of effective productivity benchmarks that anyone in the HPC community can apply to assess or predict productivity. 1

Abstract not found

The state-of-the-practice in requirements engineering (RE) is still one of the major problems in software development. Even if technology transfer has been exercised for decades now many of the industry representatives still do not know how they could solve their RE related issues. This paper presents the results of an empirical survey showing that the problem is not in the practitioners' lack of desire for improvement but in the management not knowing that many RE issues can be solved with standard practices that are well documented in literature. Raising the management awareness of RE practices would make it easier to start RE process improvement efforts in industry and thus eventually also raise the RE process maturity in companies.

Some systems failures are due to defects in manufacturing and design, however that there are a significant number of system failures which result from errors, omissions and inconsistencies in the system requirements. We thus need methods to support a ‘safe ’ requirements engineering process whose objectives are to specify system requirements such that system states which compromise safety are avoided and to include, along with the requirements, a justification or safety case which explains why the specified system is indeed safe. This paper describes the extension of a viewpoint-based requirements method to incorporate safety analysis.

This paper argues that a user's manual makes an excellent, if not the best, software requirements specification. It discusses several lessons learned from experiences writing user's manuals as requirements specifications. Keywords: ambiguity, requirements analysis, requirements elicitation, requirements validation, requirements, scenarios, specification, test cases; use cases, user's manual 1

This paper illustrates how event/use case modelling can be used to identify, define and access requirements patterns. Event/use case partitioning is widely used as a way of breaking a system into manageable, business-related chunks. Each event/use case is then the subject of detailed analysis, design and implementation. This paper illustrates how event/use case modelling can also be used as the basis for identifying and defining requirements process and data patterns. Given a book of requirements patterns, each project uses context analysis and event/use case partitioning as a way of accessing relevant patterns. Note 1: the terms event (reference McMenamin and Palmer ‘84) and “use case” (Jacobson ‘92) are used to mean the same thing. I acknowledge that there are some differences in application and notation, but for the purpose of identifying and using process patterns the models are interchangeable. Note 2: all references to “system ” refer to all the system’s processes (computerised, manual, mechanised) not just the processes that are computerised.

In this paper we present a novel approach that automatically alerts authors of requirements specifications to the presence of potentially dangerous ambiguities in their text. We first establish the notion of "nocuous " ambiguities, i.e. those that are likely to lead to misunderstandings. We focus on coordination ambiguity, which occurs when words such as “and ” and “or ” are used. Our starting point is a dataset of ambiguous phrases from a corpus of requirements specifications, and a collection of associated human judgements about their interpretation. We then use machine learning techniques combined with syntactic, semantic and word distribution heuristics to eliminate instances of text which people interpret easily. We report on a series of experiments and evaluate the performance of our approach against the collection of human judgements. Our machine learning algorithm has an accuracy of 75 % compared to a 59.6 % baseline. 1.

The computer science department of the University of Pittsburgh offers two undergraduate and two graduate courses in software engineering in which we emphasize the importance of general engineering principles for software development. For the last ten years the undergraduate courses have been based on team projects. This structure has advantages: students see immediately the relevance of what they learn, and the team setting leads to a better understanding of what they learn. The projects in the two courses are of different types. In one course the result is the formal specification and design of a software system. In the other, the teams implement such a system, but emphasis is on testing rather than on the implementation itself. The success of each project is guaranteed by making it open-ended. A team establishes a list of priorities that is to ensure that a useful product will have been built by the time the term ends. We discuss the nature of team projects, and our evaluation schem...