This paper proposes a method to generate exceptional scenarios from a normal scenario written with a scenario language. This method includes (1) generation of exceptional plans and (2) generation of exceptional scenario by a user's selection of these plans. The proposed method enables users to decrease the omission of the possible exceptional scenarios in the early stages of development. The method will be illustrated with some examples.

In order to verify the correctness of functional requirements, we have been developing a verification method of the correctness of functional requirements specification using the Requirements Frame model. In this paper, we propose a verification method of non-functional requirements specification in terms of time-response requirements written with a natural language. We established a verification method by extending the Requirements Frame model. We have also developed a prototype system based on the method using Java. The extended Requirements Frame model and the verification method will be illustrated with examples.

There have been many researches about construction and application of ontology in reality, notably the usage of ontology to support requirements engineering. The effect of ontology-based requirements engineering depends on quality of ontology. With the increasing size of ontology, it is difficult to verify the correctness of information stored in ontology. This paper will propose a method of using rules for verification the correctness of requirements ontology. We provide a rule description language to specify properties that requirements ontology should satisfy. Then, by checking whether the rules are consistent with requirements ontology, we verify the correctness of the ontology. We have developed a verification tool to support the method and evaluated the tool through experiments.

A method of generating scenarios using differential scenaro information is presented. Behaviors of normal scenarios of similar purpose are quite similar each other, while actors and data in scenarios are different among these scenarios. We derive the differential information between them and apply the differential information to generate new alternative/exceptional scenarios. Our method will be illustrated with examples. This paper describes (1) a language for describing scenarios based on a simple case grammar of actions, (2) introduction of the differential scenario, and (3) method and examples of scenario generation using the differential scenario.

This paper introduces an ontology-based method for checking requirements specification. Requirements ontology is a knowledge structure that contains functional requirements (FR), attributes of FR and relations among FR. Requirements specification is compared with functional nodes in the requirements ontology, then rules are used to find errors in requirements. On the basis of the results, requirements team can ask questions to customers and correctly and efficiently revise requirements. To support this method, an ontology-based checking tool for verification of requirements has been developed. Finally, the requirements checking method is evaluated through an experiment.

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.

A software requirements specification (SRS) is a document at the first phase of software development. Since it is difficult to make an accurate SRS at the beginning of software development, we propose a supporting method to detect and interpret the inconsistency of SRS. First, we classify and define the inconsistency of SRS. Next, we describe how to detect and interpret the inconsistency of SRS. We use the Requirements Frame Model to detect the inconsistency of SRS. We apply the Dempster and Shafer's theory to interpret the inconsistency of SRS. We illustrate our method with an example.

A communication model and a computer assisted communication method are introduced. With this model incorrect communications between humans are explained and then a method to lead successful communications with computer is illustrated. This method improves qualities of communications and can be applied to co-operative works. On the basis of the communication method, we have been developing a co-operative visual software requirements definition method via network with a visual requirements language named VRDL. Our method will improve quality of software requirements specification (SRS).

There have been few studies on formal approaches to the specification and realization of asynchronous sequential circuits. For synchronous sequential circuits, an algebraic method is proposed as one of such approaches, but it cannot be applied to asynchronous ones directly. This paper describes an algebraic method of specifying the abstract behavior of asynchronous sequential circuits. We select an daisy chain arbiter as an example of them. In the arbiter, state transitions are caused by input changes, and all the modules do not always make state transitions simultaneously. These are main obstacles to specify it in the same way as sychronous sequential circuits. In order to remove them, we modify the meaning of input in specifications and introduce pseudo state transitions so that we can regard all the modules as if they make state transitions simultaneously. This method can be applied to most of the other asynchronous sequential circuits.

Scenarios that describe concrete situations of software operation play an important role in software development and especially in requirements engineering. Scenario details should vary in content when described from different viewpoints, but this presents a difficulty, because an informal scenario from one viewpoint can not easily be transformed into a scenario from another viewpoint with consistency and assurance. This paper describes (1) a language for describing scenarios in which simple action traces are embellished to include typed frames based on a simple case grammar of actions, and (2) a method to accomplish the transformation between scenarios from different viewpoints based on the scenario description language.

In a scenario-based software development, a lot of scenarios should be described in order to clarify the whole behaviors of the target software. By reusing scenarios of similar software systems, it becomes more efficient to newly describe scenarios of the target software. A differential scenario includes the difference between sequences of events of the two scenarios and the difference between nouns in the scenarios. If the nouns of the two scenarios are commonly used in the two scenarios, we regard the two scenarios specify the same or similar system. If the sequences of the events of the two scenarios are corresponding each other, we regard behavior of the two scenarios are similar. In this paper, we derive differential information including different words and events from two scenarios. Then, we propose a method of scenario retrieval using differential information between two scenarios. This method enables to detect similar scenarios for a given scenario. The proposed retrieval method and a prototype system for creating and visualizing differential scenario will be illustrated with examples.

Scenarios that describe concrete situations of software operation play an important role in software development, especially in requirements engineering. Since scenarios are informal, the correctness of scenarios is hard to be verified. The authors have developed a language for describing scenarios in which simple action traces are embellished. The purposes are to include typed frames based on a simple case grammar of actions and to describe the sequence among events. Based on this scenario language, this paper describes both (1) a correctness-checking method using rules to detect errors (lack of events, extra events, and wrong sequence among events) in a scenario and (2) a retrieval method of rules from rule DB that applicable to scenarios using pre and post- conditions.

History data of edit operations are more beneficial than those stored in version control systems since they provide detailed information on how source code was changed. Meanwhile, a large number of recorded edit operations discourage developers and researchers from roughly understanding the changes. To assist with this task, it is desirable that they easily obtain traceability links for changed program elements over two source code snapshots before and after a code change. In this paper, we propose a graph representation called Operation History Graph (OHG), which presents code change information with such traceability links that are inferred from the history of edit operations. An OHG instance is generated by parsing any source code snapshot restored by edit histories and combining resultant abstract syntax trees (ASTs) into a single graph structure. To improve the performance of building graph instances, we avoided simply maintaining every program element. Any program element presenting the inner-structure of methods and non-changed elements are omitted. In addition, we adopted a lightweight static analysis for type name resolving to reduce required memory resource in the analysis while the accuracy of name resolving is preserved. Moreover, we assign a specific ID to each node and edge in the graph instance so that a part of the graph data can be separately stored and loaded on demand. These decisions make it feasible to build, manipulate, and store the graph with limited computer resources. To demonstrate the usefulness of the proposed operation history graph and verify whether detected traceability links are sufficient to reveal actual changes of program elements, we implemented tools to generate and manipulate OHG instances. The evaluation on graph generation performance shows that our tool can reduce the required computer resource as compared to another tool authors previously proposed. Moreover, the evaluation on traceability shows that OHG provides traceability links with sufficient accuracy as compared to the baseline approach using GumTree.

This paper proposes a method to generate alternative scenarios from a normal scenario written with a scenario language. This method includes (1) generation of alternative plans and (2) generation of alternative scenario by a user's selection of these plans. The proposed method enables users to decrease the omission of the possible alternative scenarios in the early stages of development. The method will be illustrated with some examples.