Akira Osada

Identifying Stakeholders and Their Preferences about NFR by Comparing Use Case Diagrams of Several Existing Systems

We present a method to identify stakeholders and their preferences about non-functional requirements (NFR) by using use case diagrams of existing systems. We focus on the changes about NFR because such changes help stakeholders to identify their preferences. Comparing different use case diagrams of the same domain helps us to find changes to be occurred. We utilize Goal-Question-Metrics (GQM) method for identifying variables that characterize NFR, and we can systematically represent changes about NFR using the variables. Use cases that represent system interactions help us to bridge the gap between goals and metrics (variables), and we can easily construct measurable NFR. For validating and evaluating our method, we applied our method to an application domain of Mail User Agent (MUA) system.

Identifying stakeholders and their preferences about NFR by comparing use case diagrams of several existing systems

We present a method to identify stakeholders and their preferences about non-functional requirements (NFR) by using use case diagrams of existing systems. We focus on the changes about NFR because such changes help stakeholders to identify their preferences. Comparing different use case diagrams of the same domain helps us to find the changes that can occur. We utilize the goal-question-metrics (GQM) method to identify variables that characterize NFR. Thus, we can systematically represent changes about NFR using the variables. The use cases that represent system interactions help us to bridge the gap between goals and metrics (variables). Thus, we can easily construct measurable NFR. In order to illustrate and evaluate our method, we applied our method to an application domain of the mail user agent (MUA) system.

Toward quality requirements analysis based on domain specific quality spectrum

It is difficult to identify whether quality requirements are defined adequately or not, but there are few methods to support this kind of requirements analysis. In this paper, we propose a method based on software quality spectrum, that shows a ratio of quality characteristics embedded in a software engineering artifact, such as a requirements specification, a manual and so on. We assume similar kinds of software systems have similar spectrum, thus we can identify the adequacy of quality requirements for a new system by using spectrum of already existing similar systems. We confirmed the assumption above by analyzing actual software systems, i.e., web browsers and drawing tools.

Modeling software characteristics and their correlations in a specific domain by comparing existing similar systems

Software in a specific domain has several characteristics and each characteristic should be fixed when the software requirements are specified. In addition, these characteristics sometimes correlate with each other. However, we sometimes forget to specify several characteristics and/or to take their correlations into account during requirements elicitation. In this paper, we propose a meta-model for representing such characteristics and their correlations, and also propose a method to build a model for a specific domain by using documents about existing software systems. By using our model for a domain, a requirements specification for a system in the domain could be complete and unambiguous because requirements analysts can check the characteristics that should be decided. The specification could be also correct and consistent because the analysts can know side effects of a requirement change by using correlation among the characteristics. We have applied our methods to a case study for confirming the usefulness of such model and the methods.

Exploring How to Support Software Revision in Software Non-intensive Projects Using Existing Techniques

Most industrial products are developed based on their former products including software. Revising existing software according to new requirements is thus an important issue. However, innovative techniques for software revision cannot be easily introduced to projects where software is not a central part. In this paper, we report how to explore and apply software engineering techniques to such non-ideal projects to encourage technology transfer to industry. We first show our experiences with industrial partners to explore which tasks could be supported in such projects and which techniques could be applied to such tasks. As a result, we found change impact analysis could be technically supported, and traceability techniques using information retrieval seemed to be suitable for it. We second had preliminary experiences of a method using such techniques with data in industry and evaluated them with our industrial partners. Based on the evaluation, we third improved such a method by using following techniques, indexing of technical documents for characterizing requirements changes, machine learning on source codes for validating predicted traceability and static source code analysis for finding indirect impacts. Our industrial partners finally evaluated the improved method, and they confirmed the improved method worked better than ever.

Proposing metrics of difficulty of domain knowledge using usecase diagrams

In a system development, the knowledge of a target business is very important factor for the success of a development. The needed part of such knowledge is different for each stakeholder. Therefore, we need a method to measure the level of understanding of a stakeholder and a method to categorize business knowledge. This paper proposes the metric of difficulty level in order to measure the business knowledge. Moreover, we performed the experiment to confirm the suitability of the proposed metric.

A systematic method for generating quality requirements spectrum

Spectrum analysis for quality requirements is useful for measuring and tracking them, but current spectrum analysis largely depends on expertise of each analyst. Therefore, it takes a lot of efforts to perform the analysis and is hard to reuse experiences for such analysis. We introduce domain knowledge called term-characteristic map to improve current spectrum analysis for quality requirements. Through several experiments, we evaluated the improved method for spectrum analysis.