Requirements Elicitation Techniques Research Articles

Improving use case driven analysis using goal and scenario authoring: A linguistics-based approach

Use case driven analysis does not facilitate effective requirements elicitation or provide rationale for the various artifacts that get generated during the requirements analysis phase. On the other hand, goal and scenario based approach is considered to be effective for elicitation but it does not lead to use cases. This paper discusses how to combine goal and scenario based requirements elicitation technique with use case driven analysis using natural language concepts. In our proposed approach, four levels of goals, scenario authoring rules, and linguistic techniques have been developed to identify use cases from text based goal and scenario descriptions. The artifacts resulting from our approach could be used as input to a use case diagramming tool to automate the process of use case diagram generation.

Thoughts on Requirements and Design Issues of User Interfaces for Proof Assistants

This position paper discusses various issues concerning requirements and design of proof assistant user interfaces (UIs). After a review of some of the diculties faced by UI projects in academia, it presents a high-level description of proof assistant interaction. This is followed by an exposition of use cases and object identification. Several examples demonstrate the usefulness of these requirement elicitation techniques in the theorem proving domain. The second half of the paper begins with a consideration of the “principle of least eort” for the design of theorem prover user interfaces. This is followed by a brief review of the “GUI versus text mode” debate, proposals for better use of GUI facilities and a plea for better support of customisation. The paper ends with a discussion of architecture and system design issues. In particular, it argues for a platform architecture with an extensible set of components and the use of XML protocols for communication between UIs and proof assistant backends.

10.8 Integrating Systems Engineering and Marketing

AbstractCustomer Oriented Requirements Understanding (CORU) continues to be the key to successful Systems Engineering and Marketing of large Aerospace and Government systems. Buyers hold all of the Requirements and all of the money. This is defined as the “Customer Needs or Requirements PULL” environment.Systems Engineers ask if the principles of CORU operate in a Commercial “Seller Product or Technology PUSH” environment, and whether causal models can be constructed which address and differentiate (or segment) markets accurately. If so, the principles which are effective in large system acquisition environments (with limited numbers of stakeholders) can be translated to the relatively large stakeholder environment of product development for TELCOs, consumer electronics and high‐technology systems, and other high‐volume commercial products. The key process techniques of Requirements Elicitation and Requirements Causality Modeling are described along with a robust economic and Systems Engineering model for a network‐like architecture of how these processes link the Customers (Buyers) with Needs or Requirements together with the Sellers or developers of Capabilities or Products. Research results are delineated which make the case that these linkages through Requirements Elicitation and Requirements Causality Modeling process techniques are basic principles of CORU which are valid in both the Requirements PULL or DoD environments as well as in the Product PUSH or commercial environments. Examples are given in which Value Hierarchies are aligned across Customer‐Seller boundaries to achieve product success in both the Commercial and the DoD environments.

Generating Complete, Unambiguous, and Verifiable Requirements from Stories, Scenarios, and Use Cases.

Simple scenarios and stories are typically used for requirements engineering in the Agile community (e.g., eXtreme Programming). Use case modeling has also been a popular requirements elicitation and analysis technique for many years. However, stories, scenarios, and use cases typically exhibit a great informality that violates the traditional guidance in the requirements engineering community that requirements should be complete, unambiguous, and verifiable. This is why many professional requirements engineers use these techniques only as tools for informal requirements elicitation, analysis, and validation. Instead during requirements analysis and specification, more experienced requirements engineers tend to develop and specify more formal textual requirements that are complete, unambiguous, and verifiable. This column will show how to transform incomplete and vague stories, scenarios, and use cases into a proper set of complete, unambiguous, and verifiable requirements.

Requirements Elicitation Techniques: Analyzing the Gap between Technology Availability and Technology Use

Many software development projects fail because the resulting software does not satisfy user needs. The process of determining user needs is generally termed requirements elicitation. Although there are many possible reasons for software failures, if analysts practiced more effective requirements elicitation, fewer projects would fail. Although hundreds of requirements elicitation techniques have been developed by researchers to aid analysts in effectively determining user needs, few have ever been used by practitioners. This paper reports on research to study the nature of the gap between requirements elicitation technique availability and use, identifies the major factors that impact the transfer of elicitation techniques to practice, and explores how to improve the transfer of elicitation techniques from research to practice.

AUTOMATED REQUIREMENTS ELICITATION: COMBINING A MODEL-DRIVEN APPROACH WITH CONCEPT REUSE

Extracting pertinent and useful information from customers has long plagued the process of requirements elicitation. This paper presents a new approach to support the elicitation process. This approach combines various techniques for requirements elicitation which include model-based concept acquisition, goal-driven structured interview and concept reuse. Compared with the available approaches for requirements elicitation, the most significant feature of our approach is that it supports both the automation of interaction with customers by using domain terminology, not software terminology and the automated construction of application requirements models using model-based concept elicitation and concept reuse. The capacity of this approach comes from its rich knowledge which is clustered into several abstract levels.

A Balanced Approach to Capturing User Requirements in Business- to- Consumer Web Information Systems

The development of business-to-consumer web information systems pose special challenges in the requirements analysis phase. It is difficult to capture user requirements given that users are relatively autonomous and anonymous and there are no major incentives for users to become involved in the development of a web information system. The researchers reviewed traditional requirement elicitation techniques, marketing research techniques and web usage analysis techniques. Current practice was assessed and the findings suggest that a balanced approach to user requirements capture will result in more complete and user centred requirements. This approach should lead to more effective business-to consumer web information systems.

Automatic Synthesis Of Behavioral Object Specifications From Scenarios

The use of scenarios has become a popular technique for requirements elicitation and specification building. Since scenarios capture only partial descriptions of system behavior, an approach for scenario composition and integration is needed to produce more complete specifications. The Unified Modeling Language (UML), which has become a standard notation for object-oriented modeling, provides a suitable framework for scenario acquisition using Use Case diagrams and Collaboration diagrams and for behavioral specification using Statechart diagrams; yet it does not propose any specific modeling process, let alone a process for transforming scenarios into behavioral specifications. In this paper, we suggest a four-step process for synthesizing behavioral specifications from scenarios. It automatically generates from a given set of Collaboration diagrams the Statechart diagrams of all the objects involved. An automatic analysis of specifications in respect to consistency and completeness is also provided. Our approach is incremental and is fully compliant with the UML. Furthermore, it provides an elegant solution to the problem of scenario interleaving. The underlying algorithms have been implemented and validated with several examples, and they are fit for integration into CASE tools supporting the UML.

A Method for Extracting and Stating Software Requirements that a User Interface Prototype Contains

User interface and requirements prototyping is a requirements elicitation technique. A user interface and requirements prototype is built during the requirements engineering phase of a software system development. Along with the user interface prototype are produced various documents such as the system requirement specification. When a prototype and other documents exist, they may not describe the same functionality, particularly because there may be behaviour of the prototype, artefacts of prototyping, that may not be intended. The problem is that in later development stages, when there is a prototype and other documents, it is often difficult to reconcile the difference between the prototype and the other documents. This paper presents an approach for avoiding this difficulty. It demonstrates the approach by showing its application to parts of a real software development.

Integration and analysis of use cases using modular Petri nets in requirements engineering

It is well known that requirements engineering plays a critical role in software quality. The use case approach is a requirements elicitation technique commonly used in industrial applications. Software requirements are stated as a collection of use cases, each of which is written in the user's perspective and describes a specific flow of events in the system. The use case approach offers several practical advantages in that use case requirements are relatively easy to describe, understand, and trace. Unfortunately, there are a couple of major drawbacks. Since use cases are often stated in natural languages, they lack formal syntax and semantics. Furthermore, it is difficult to analyze their global system behavior for completeness and consistency, partly because use cases describe only partial behaviors and because interactions among them are rarely represented explicitly. We propose the Constraints-based Modular Petri Nets (CMPNs) approach as an effective way to formalize the informal aspects of use cases. CMPNs, an extension of Place/Transition nets, allow the formal and incremental specification of requirements. The major contributions of the paper, in addition to the formal definitions of CMPNs, are the development of: 1) a systematic procedure to convert use cases stated in natural language to a CMPN model; and 2) a set of guidelines to find inconsistency and incompleteness in CMPNs. We demonstrate an application of our approach using use cases developed for telecommunications services.