Goal refinement is a crucial step in goal-oriented requirements analysis to create a goal model of high quality. Poor goal refinement leads to missing requirements and eliciting incorrect requirements as well as less comprehensiveness of produced goal models. This paper proposes a technique to automate detecting bad smells of goal refinement, symptoms of poor goal refinement. At first, to clarify bad smells, we asked subjects to discover poor goal refinement concretely. Based on the classification of the specified poor refinement, we defined four types of bad smells of goal refinement: Low Semantic Relation, Many Siblings, Few Siblings, and Coarse Grained Leaf, and developed two types of measures to detect them: measures on the graph structure of a goal model and semantic similarity of goal descriptions. We have implemented a supporting tool to detect bad smells and assessed its usefulness by an experiment.

Goal modeling is a method that describes requirements structurally. Goal modeling mainly consists of two tasks: extraction of goals and organization of the extracted goals. Generally, the process of the goal modeling requires intensive manual intervention and higher modeling skills than the process of the usual requirements description. In order to mitigate this problem, we propose a method that provides systematic supports for constructing goal models. In the method, the requirement analyst answers questions and a goal model is semi-automatically constructed based on the answers made. We develop a prototype tool that implements the proposed method and apply it to two systems. The results demonstrate the feasibility of the method.

Natural language (NL) requirements are usually human-centric and therefore error-prone and inaccurate. In order to improve the 3Cs of natural language requirements, namely Consistency, Correctness and Completeness, in this paper we propose a systematic pattern matching approach supporting both NL requirements modeling and inconsistency, incorrectness and incompleteness analysis among requirements. We first use business process modeling language to model NL requirements and then develop a formal language — Workflow Patterns-based Process Language (WPPL) — to formalize NL requirements. We leverage workflow patterns to perform two-level 3Cs checking on the formal representation based on a coherent set of checking rules. Our approach is illustrated through a real world financial service example — Global Equity Trading System (GETS).

Defining quality requirements completely and correctly is more difficult than defining functional requirements because stakeholders do not state most of quality requirements explicitly. We thus propose a method to measure a requirements specification for identifying the amount of quality requirements in the specification. We also propose another method to recommend quality requirements to be defined in such a specification. We expect stakeholders can identify missing and unnecessary quality requirements when measured quality requirements are different from recommended ones. We use a semi-formal language called X-JRDL to represent requirements specifications because it is suitable for analyzing quality requirements. We applied our methods to a requirements specification, and found our methods contribute to defining quality requirements more completely and correctly.

Quality requirements are scattered over a requirements specification, thus it is hard to measure and trace such quality requirements to validate the specification against stakeholders' needs. We proposed a technique called "spectrum analysis for quality requirements" which enabled analysts to sort a requirements specification to measure and track quality requirements in the specification. In the same way as a spectrum in optics, a quality spectrum of a specification shows a quantitative feature of the specification with respect to quality. Therefore, we can compare a specification of a system to another one with respect to quality. As a result, we can validate such a specification because we can check whether the specification has common quality features and know its specific features against specifications of existing similar systems. However, our first spectrum analysis for quality requirements required a lot of effort and knowledge of a problem domain and it was hard to reuse such knowledge to reduce the effort. We thus introduce domain knowledge called term-characteristic map (TCM) to reuse the knowledge for our quality spectrum analysis. Through several experiments, we evaluate our spectrum analysis, and main finding are as follows. First, we confirmed specifications of similar systems have similar quality spectra. Second, results of spectrum analysis using TCM are objective, i.e., different analysts can generate almost the same spectra when they analyze the same specification.

We propose requirement validation criteria and a method based on the interaction between actors in an information system. We focus on the cyclical transitions of one actor's situation against another and clarify observable stimuli and responses based on these transitions. Both actors' situations can be listed in a state transition table, which describes the observable stimuli or responses they send or receive. Examination of the interaction between both actors in the state transition tables enables us to detect missing or defective observable stimuli or responses. Typically, this method can be applied to the examination of the interaction between a resource managed by the information system and its user. As a case study, we analyzed 332 requirement defect reports of an actual system development project in Japan. We found that there were a certain amount of defects regarding missing or defective stimuli and responses, which can be detected using our proposed method if this method is used in the requirement definition phase. This means that we can reach a more complete requirement definition with our proposed method.

During software requirements analysis, developers and stakeholders have many alternatives of requirements to be achieved and should make decisions to select an alternative out of them. There are two significant points to be considered for supporting these decision making processes in requirements analysis; 1) dependencies among alternatives and 2) evaluation based on multi-criteria and their trade-off. This paper proposes the technique to address the above two issues by using an extended version of goal-oriented analysis. In goal-oriented analysis, elicited goals and their dependencies are represented with an AND-OR acyclic directed graph. We use this technique to model the dependencies of the alternatives. Furthermore we associate attribute values and their propagation rules with nodes and edges in a goal graph in order to evaluate the alternatives with them. The attributes and their calculation rules greatly depend on the characteristics of a development project. Thus, in our approach, we select and use the attributes and their rules that can be appropriate for the project. TOPSIS method is adopted to show alternatives and their resulting attribute values.

We propose a method for analyzing trade-off between an environment where a Java mobile code application is running and requirements for the application. In particular, we focus on the security-related problems that originate in low-level security policy of the code-centric style of the access control in Java runtime. As the result of this method, we get feasible requirements with respect to security issues of mobile codes. This method will help requirements analysts to compromise the differences between customers' goals and realizable solutions. Customers will agree to the results of the analysis by this method because they can clearly trace the reasons why some goals are achieved but others are not. We can clarify which functions can be performed under the environment systematically. We also clarify which functions in mobile codes are needed so as to meet the goals of users by goal oriented requirements analysis(GORA). By comparing functions derived from the environment and functions from the goals, we can find conflicts between the environments and the goals, and also find vagueness of the requirements. By resolving the conflicts and by clarifying the vagueness, we can develop bases for the requirements specification.

Requirements engineering refers to activities of gathering and organizing customer requirements and system specifications, making explicit representations of them, and making sure that they are valid and accounted for during the course of the design lifecycle of software. One very popular software development practice is the incremental development practice. The incremental development refers to practices that allow a program, or similarly specifications, to be developed, validated, and delivered in stages. The incremental practice is characterized by its depth-first process where focuses are given to small parts of the system in sequence to fair amounts of detail. In this paper, we present a development and validation of specifications in such an incremental style using a tool called ASADAL, a comprehensive CASE tool for real-time systems. ASADAL supports incremental and hierarchical refinements of specifications using multiple representational constructs and the evolving incomplete specifications can be formally tested with respect to critical real time properties or be simulated to determine whether the specifications capture the intended system behavior. In particular, we highlight features of ASADAL's specification simulator, called ASADAL/SIM, that plays a critical role in the incremental validation and helps users gain insights into the validity of evolving specifications. Such features include the multiple and mixed level simulation, real-value simulation, presentation and analysis of simulation data, and variety of flexible simulation control schemes. We illustrate the overall process using an example of an incremental specification development of an elevator control system.

We study the correspondence between problem descriptions and requirements specification documents derived from them. Based on the results of this investigation, a model that integrates the problem space and the requirements specification space is developed. This integration is based on a semantic network representation. We also propose a model of the requirements elicitation process that is consistent with our empirical studies of traceability in requirements documents. In this process, analysts derived requirements specifications from incomplete and ambiguous problem descriptions given by customers, identify missing information, completed it, and then decide the system boundaries that define which part of the problem descriptions to implement as the target system. The model can be used to complete problem descriptions given by customers and determine the system boundaries.