Concern Based Document Driven Requirements Analysis Method And Its Supporting Tool

Document Driven Software Development Method advocates formulating complete and precise documentations to guild the process of software development. The classification of those documentations, and the standards and definitions of them were listed in the method. Document Driven Software Development Method emphasizes the validity, consistency, completeness and readability of documentations. Therefore the documentations defined under the demand of Document Driven Software Development Method will do guild the software development process. Document Driven Requirement Method is a reduction of Document Driven Software Development Method applied in requirement domain. It commits itself to defining strict and precise formal requirement documentations with high quality at requirement stage. 4-variable model is a requirement model which is more useful for embedded system requirement analysis. The classification and definition standards of all documentations at requirement stage are given in it. And SCR method, as a specific amplification from 4-variable model, gives the procedure of defining formal requirement documentations. However, in the practice of applying SCR method to requirement case studies, it is discovered that there is quite a bit difficulty to define formal requirement documentations directly from informal textual requirements.As the bridge to step over the gap between informal textual requirements and formal requirement documentations, the idea of separations of concern is added between them, which make the definitions of concern and their relations at requirement level become a cache for deriving formal requirement documentations from informal textual requirements. And this decreases the difficulty of defining formal requirement documentations. As the above idea, the new requirement method-document driven requirement method based on concerns is proposed in the paper. The main thought is that: according to the obtained informal textual requirements, defining concerns and their relations at requirement level with concern-modeling-mechanism; then further defining formal requirement documentations according to the formal definitions of concerns and their relations with 4-viriable and its amplifications like SCR method. Therefore, the requirement method introduced in the paper will make the mapping from the textual requirements to the final formal requirements more precise, and make the process of requirement analysis clearer and easier. The requirements analysis process, which is based on the definitions of concerns and relations at requirement level, becomes concern-modeling-mechanism, one of the main contents in the paper. The concern-modeling-mechanism, as the specific realization of the idea of separation of concerns, becomes the bridge stepping over the gap between informal textual requirements set to formal requirement documentations. This means that there are two steps to derive formal requirement documentations from textual requirements set: defining concerns and their relations at requirement level according to textual requirements; from the definitions of concerns and their relations, defining formal requirement documentations according to 4-variable model.Crosscutting-concern-judging-architecture is actually the specific realization of the AORE idea in document driven requirement method. AORE commits itself to find the connotative aspects to avoid the situation that complex crosscutting problems may cause troubles in later periods or even make the software development failing. Crosscutting-concern-judging-architecture becomes a solution for judging crosscutting characteristics of textual requirements and works on the three levels: possible crosscutting concerns, possible crosscutting concerns according to X type relation and confirming for crosscutting concern. There are also three main contents in crosscutting-concern-judging-architecture: definitions about crosscutting concern, crosscutting concern judging method and the crosscutting concern confirming standard. All the three parts work together to obtain crosscutting requirements set (crosscutting concerns) on the base of concern modeling.In this document driven requirement method based on concerns, concern-modeling-mechanism, concern conflicts checking, crosscutting-concern judging-architecture and crosscutting concern compounding at requirement level are related. Among them, concern-modeling-mechanism at requirement level is a specific implementation of the idea of separations of concern in the requirement method introduced in this paper. The concern-modeling-mechanism consists of concern definition model and concern modeling method of combining top-down and bottom-up. Concern definition model is about the definitions and classifications of concerns and relations at requirement level. And concern modeling method includes there iterative steps: leading top-down, promoting bottom-up and integrating. The crosscutting-concern-judging-architecture gives the solution of judging crosscutting characteristics with three levels, and there are three contents in it: definitions, method and standard. Besides concern modeling-mechanism and crosscutting-concern-judging-architecture, concern conflicts definitions and crosscutting concern compounding are component elements in the requirement method. Concern conflicts definitions are useful for the procedure of defining concerns and their relations at requirement level, and crosscutting concern compounding is useful for confirming crosscutting requirements set (crosscutting concern). Concern conflicts definitions are five kinds of possible logical problems in the process of concern modeling according to concern definition model. And crosscutting concern compounding is to put the confirmed crosscutting concern into concerns-relations-graph-environment to find conflicts and problems. Meanwhile, tools about concern modeling, crosscutting concern judging, concern conflicts checking and crosscutting concern compounding, which were support tools of core functions, were developed in the paper. These support tools are important parts of AODREM1.0 which is the integrated tool for China 863 project-Aspect Oriented and Document Driven Requirements Engineering. In the paper, Concern-modeling-mechanism, crosscutting-concern-judging architecture, concern conflicts definitions and crosscutting concern compounding were applied in requirements of hallway section part in the classic requirement case study-Light Control System, and good results were obtained.The document driven requirement method based on concerns is firstly proposed. After that, concern-modeling-mechanism and crosscutting-concern-judging-architecture are introduced as the main contents in the paper. Concern-modeling-mechanism is essentially the mechanism to divide requirements set, which causes requirements set encapsulated into concerns, and makes requirement analysis easier with the software principle of"divide and conquer". The introduction of concern-modeling-mechanism makes the process from textual requirements to formal requirement documentations easy and precise; Crosscutting-concern-judging-architecture makes it possible to find crosscutting chrematistics in requirement set at concern level. However, there are many works to do in concern based document driven requirements analysis method.1. 4-variable model is useful requirement model in embedded system. Requirement workers should summarize embedded system's characteristics in the practice of requirements analysis, and add the part of experience-guild at concern level, which may make it better when combining concern-modeling-mechanism and 4-variable requirement model.2. The crosscutting degree in crosscutting-concern-judging-architecture is more or less fixed. Some scientific and flexible algorithms should be considered to compute crosscutting degree, and better results may be obtained. 3. The supporting tool in the paper is semi-automatic, and some more works should be done in automation.4. As a formal requirement model, 4-variable is strong and complete, but it is fit for embedded system. Some works should be done to expand 4-variable's application in other kinds of systems, which may make 4-variable more general, not only for embedded system.