Requirements changes sometimes cause a project to fail. A lot of projects now follow incremental development processes so that new requirements and requirements changes can be incorporated as soon as possible. These processes are called integrated requirements processes, which function to integrate requirements processes with other developmental processes. We have quantitatively and qualitatively investigated the requirements processes of a specific project from beginning to end. Our focus is to clarify the types of necessary requirements based on the components contained within a certain portion of the software architecture. Further, each type reveals its typical requirements processes through its own rationale. This case study is a system to manage the orders and services of a restaurant. In this paper, we introduce the case and categorize its requirements processes based on the components of the system and the qualitative characteristics of ISO-9126. We could identify seven categories of the typical requirements process to be managed and/or controlled. Each category reveals its typical requirements processes and their characteristics. The case study is our first step of practical integrated requirements engineering.

Research has been actively proposed into how to specify requirements in the upper stream of software development. For example, the main research issues regarding Structured Analysis and Object Oriented Analysis methodologies include requirements elicitation, modeling, and validation of specifications to give a starting point for software development. At the same time, another area of research has emerged that recognizes the importance of guaranteeing requirements quality by goals. As the impact of IT penetrates to mobile devices, information appliances and automobiles, goal oriented requirements engineering (GORE) approaches for performance and safety in embedded systems have been proposed. Non-Functional Requirements (NFRs) such as business strategy, security and privacy, are now being formalized by Requirements Engineering (RE) technologies, because enterprise business is now heavily influenced by IT, for example in e-Business. As IT is fast becoming ubiquitous in society, the importance of Goal Orientation will increase as socio-technology enables visualization of the role of software in social systems. In this paper, we discuss the current states and trends of GORE from the viewpoints of both academia and industry.

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.

Goal-oriented analysis and use case analysis are well known requirements analysis methods and are putting into practice. Roughly speaking, goal-oriented methods are suitable for eliciting constraints to a system and use case analysis methods elicit concrete system behavior. Thus these methods are complementary and their integration into a new method allows us to get a more powerful requirements elicitation method. This paper proposes a new method where both of the methods are amalgamated. In our method, constraints to the system are refined by goal-oriented style, while system behavior are described with hierarchical use cases. Since a use case is made relate to goals during our elicitation processes, the decomposition of goals and use cases are complementally supported. Furthermore we applied our method to a couple of development projects and assessed its effectiveness.

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).

It is one of the difficulties in enterprise modeling that we must deal with many fragmented pieces of knowledge provided by various domain-experts, which are usually based on mutually different viewpoints of them. This paper presents a formal approach to integrate those pieces into enterprise-wide model units using Rough Set Theory (RST). We focus on business processes in order to recognize and identify the constituents or units of enterprise models, which would compose the model expressing the various aspects of the enterprise. We defined five model unit types of "resource," "organization," "task," "function," and "behavior. " The first three types represent the static aspect of the enterprise, whereas the last two types represent the dynamic aspect of it. Those units are initially elicited from each domain-expert as his/her own individual model units, then they are integrated into enterprise-wide units using RST. Our approach is methodology-free, and any methodologies can include it in their early stage to identify what composes the enterprise.

To bridge a wide gap between the end users and the requirements engineers, we propose a business flow diagram for acquiring users' requirements of the object oriented software development in the business application domain. Each field of this diagram shows either a role or a responsibility of a particular person or an organization. This paper proposes a development method that the engineers acquire the requirements by using our diagrams. We have implemented a supporting tool based on this study for collaborating the requirements engineers with their users. At first, the end users of an information system to be developed draw diagrams representing the flows of information and physical objects in their work from their own points of view. Sometimes the engineers write them with the users. If all users submit their diagrams, then our tool collects them and constructs a total diagram. The requirements engineers analyze the total diagram for improving the business flow. After the engineers complete this diagram, our tool can automatically transform it into an initial version of the class diagram. We show the effectiveness of our approach with some experiments. Comparing the related works, we discuss some issues of the practical aspects of this proposal.