Class diagram is an important model in object-oriented software development. A class diagram specifies the structure of a system with the system's classes, classes’ attributes and methods, and relations among classes. Sometimes class diagrams should be modified in accordance with requirements changes or correction of errors. In such a modification, careless mistakes may lead to include another error in the diagram. In this paper, we propose a method of visualization of the difference between original class diagram and modified one by emphasizing the difference in order to avoid newly produced errors. We illustrate our method with examples.

Edit operation history of source code can be used to understand how the software has been developed. However, since such an edit history is enormous, it is effective to first grasp the outline of development and then look at the details, although existing tools do not well support the process. In this paper, we propose Edited Method Highlight (EMH), which extends an existing operation replay tool called OperationReplayer to support understanding of development tasks by visualizing the recorded operation history. The visualization shows the transition of edited parts (classes and methods) and specific types of operations (debugging and committing) on the timeline displayed in the replay tool. We conducted a preliminary experiment to examine whether users could share a common understanding of task outlines. The result shows they reported task kinds with similar word sets while reported time stamps of task boundaries and word sets for developed functions in each task were various. This paper also discusses several success and failure factors to reach common understanding of development tasks.

Ripple effect in the modification of software requirements should be properly analyzed, since it may cause errors of software requirements. We have already proposed a ripple effect analysis method in deletion or update of data flow requirements. In this paper, we enhance our method considering ripple effect analysis in adding new data flows requirements. Our method will be illustrated with examples.

It is very important to certify the accuracy of non-functional requirements in software development. In this paper, we focus on reliability requirements. We can correctly obtain reliability requirements from software requirements documents by using keywords related to reliability requirements. Retrieved requirements will be checked using a requirements frame model in order to verify the consistency, non-redundancy, unambiguity and completeness of these requirements. Our method will be illustrated with 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 introduce a verification method of non-functional requirements specification, especially time-response requirements and usability requirements written with a natural language. We establish 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.

Knowledge-based software engineering, especially ontology-based method has potential to facilitate requirements engineering. However, the effect of ontology method depends on usage contexts and experiences of software engineers. This paper illustrates the evaluation of ontology-based checking method of requirements specification by two comparative experiments: in each experiment, two groups of subjects checked a same list of requirements but one group used ontology and the other group did not. The working method of two groups exchanged in the second experiment: the group using ontology in the first experiment worked freely in the second experiment and vice versa. In major cases in both experiments, the group using ontology had better results than the group working freely did. Through the experiments, the authors can show the effectiveness of the ontology in checking software requirements specification.

This paper briefly presents a checking method of elicited software requirements using requirements ontology, and introduces two extensions of the method. The first is capability of checking attributes of functional requirements (who, when, where, why, how), and the second is permission of requirements verifiers to specify new rules. The method is illustrated with examples, supported by a checking tool, and evaluated with experiments.

Scenarios are useful to specify and clarify behaviors of system and its user. However, in a scenario-based software development, a lot of scenarios should be written. This paper proposes a method to generate exception scenarios from a normal scenario written with a scenario language using templates of exceptions. This method includes (1) generation of exception plans and (2) generation of exception scenario by a user's selection of these plans. The proposed method enables users to decrease the omission of the possible exception scenarios in the early stages of development. The method will be illustrated with some examples.

Specific software requirements can be organized with different ways, such as user class oriented organization, functional hierarchy oriented organization, stimulus oriented organization, and so on. User class oriented software requirements specification is easy to understand for each class of users' behaviors, but difficult to understand functional hierarchy. We adopt a controlled requirements language named X-JRDL as a requirements language. We can analyze requirements specifications written with X-JRDL using natural language processing techniques. In this paper, we propose a transformation method between two software requirements specifications organized in different ways.

This paper addresses the issue of guaranteeing the correctness of fault diagnosis mechanisms in multi-agent systems. We propose an automated approach to verifying the property of diagnosability by combining fault injection with model checking. In particular we show how to reason about individual agent's and system wide knowledge of faults, which is essential for the agents to cooperate and coordinate to recover from them. The multi-agent system model checker MCMAS is used for verification and epistemic specifications are defined to specify that a system accurately diagnoses faults.

A method of generating alternative/exceptional scenarios using differential information is presented. Behaviors of normal scenarios of similar purpose are quite similar, while actors and data in scenarios are different among these scenarios. We derive the differential information between them and apply the 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.

A method of generating alternative/exceptional scenarios using differential information is presented. Behaviors of normal scenarios of similar purpose are quite similar, while actors and data in scenarios are different among these scenarios. We derive the differential information between them and apply the information to generate new alternative/exceptional scenarios.

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 verify. 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-verification 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 postconditions.

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. The authors have developed a language for describing scenarios in which simple action traces are embellished to include typed frames based on a simple case grammar of actions. This paper describes a transformation method to accomplish the transformation between scenarios from different viewpoints. An empirical investigation demonstrated the usefulness of the method by means of two experiments.

We propose a new requirements elicitation method in the domains of ERP, CRM, and SCM by using specifications of several existing package software. We have analyzed the requirements elicitation processes of experienced analysts in a specific domain, and found that they clarify requirements by referring the specifications of existing packages that seem to be satisfied with customer's needs. This process can be formulated into two subprocesses: 1) package selection, where an analyst compares the customer's needs with functions/nonfunctions of packages and selects the suitable candidates of packages; and 2) requirements evolution, where he examines the selected packages with his customer and an approved part of specifications of packages are added into their requirements. The proposed method, called PAORE (package oriented requirements elicitation method) is designed based on the analysis. We applied this method to a simple but realistic example of Web-based sales supporting system and assessed it.

Scenarios that describe concrete situations of software operation play an important role in software development, and in particular in requirements engineering. Scenario details should vary in content and detail when described from different viewpoints (e.g. types of user or external interface), but this presents a difficulty, because informal scenarios cannot easily be translated from one viewpoint to another 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 procedure for translating a frame-based scenario from one viewpoint into another and (3) integration method of scenarios described from different viewpoints. We illustrate them with examples of program chair's job.

Experts in requirements elicitation interview stakeholders using various levels of knowledge to grasp and elicit users' requirements. This paper analyzes expert interview processes and explores a computation model for simulating them. This model can be used to navigate a novice analyst's interview processes. It consists of a blackboard model and a state transition model in order to narrow the candidates for questions that an expert analyst will ask stakeholders next in the interview process. The candidates are selected based on information that has been elicited from stakeholders, and the blackboard model is for holding this information in the form of IEEE 830, a standard form of requirements specification documents. We have analyzed experts' interview processes and constructed a computation model in the sales management domain. We also recorded novice processes and showed that we could improve them by means of the model.

Establishes a visual support method for developing sequence controller programs. Current sequence controller programming methods have problems such as user-unfriendly programming languages and low programmer productivity. Our support method provides solutions to these problems that lead to a more efficient way of writing a sequence controller program. The method lets a programmer combine software components to define a target system. The software components appear as icons on a monitor. The programmer then develops a sequence controller program by setting conditions as well as actions on the software components. Our method is illustrated in detail, with examples.

Establishes a visual support method for developing sequence controller programs. The method enables users to verify the behavior of their programs with the help of animation. Current sequence controller programming methods have problems such as user-unfriendly programming languages and low programmer productivity. Our support method provides solutions to these problems that lead to a more efficient way of writing a sequence controller program. The support method lets users define a target system with the software components seen as icons on the monitor, and allows them to develop a sequence controller program by setting the conditions as well as the actions of the software components. The method is illustrated with examples.

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 Dempster and Shafer's theory (A.P. Dempster, 1968) to interpret the inconsistency of SRS. The method is illustrated with an example.

The author proposes a method to build a relational database of software requirements specifications (SRSs) from textual and visual SRSs automatically. The author has been developing a requirements model named Requirements Frame, a text-based requirements language and a visual requirements language based on the model in order to improve the quality of SRSs. Since Requirements Frame can be transformed into a relational data model, each of the requirement sentences can be regarded as a tuple of a relational table. The author has been developing both a query language and a relational database management system for an SRS database. One of the features of the SRS DB system is to show an answer with a requirement sentence as an example/counter-example. This feature contributes to verify the SRS from a developer's own viewpoint. Another feature is to detect the changed requirements in modification of the SRS. This feature contributes to effective maintenance of the SRS.

The authors propose a visual software requirements definition method including describing a visual software requirements specification (SRS) with a visual requirements language and executing the SRS. The method proposed provides a describer for defining both the shape and semantics of icons to specify the requirements as he imagines. The method also provides for describing an icons' movements as a scenario description. This scenario enables an execution of the SRS with animation. The describer can confirm his requirements by checking the animation. Furthermore the paper describes a supporting method of visual software requirements definition by multiple developers via a network system.

Computer aided requirements definition methods and an environment are presented. We have proposed a requirements model, named Requirements Frame, and requirements languages based on the model. We have developed several supporting methods of software requirements definition on the basis of the model. They are: analysis of requirements; describing requirements; verification of SRS (Software Requirements Specification); SRS execution; software preliminary design. With these methods, a requirements definer can get an SRS of good quality ie., correctness, testability, traceability, feasibility, and usability. We have been developing an environment of requirements definition, named CARD by realizing these methods. The CARD supports two kinds of requirements languages, that is, textual language and visual language. The CARD includes: (1) SRS analyzer, (2) SRS verifier (3) SRS retriever, (4) SRS executor, and (5) software design assistant.

The author presents a software requirements specification method with a visual language (VRDL) and a text base language (X-JRDL). VRDL language allows to define both the shape and semantics of any icons to specify requirements just what he imagines. X-JRDL language based on the case grammar allows to define case structures of any new verbs to specify requirements naturally and easily. In this sense these languages are customizable. Since these two languages are based on the same model, their internal representations have the same scheme. This fact means that a describer can write down requirements with either/both VRDL or/and (X-JRDL). The model which gives the basis of the languages, features of the languages, and some examples are described.>

Computer-aided requirements definition methods/environment are presented. A composite requirements model (requirements frame) is proposed, and several supporting methods of software requirements definition based on the model are developed. They are: analysis of requirements; describing requirements; verification of an SRS (software requirements specification); SRS execution; and software preliminary design. With these methods, it is possible to obtain an SRS of good quality (correctness, testability, traceability, feasibility, and usability). The authors have been developing an environment of requirements definition, named CARD, by using these methods. They present some examples of experimental uses of CARD.>