Research On Requirements Elicitation And Behavioral Modeling Based On Scenarios

With the rapid development of software engineering, people have already begun to realize the importance of software engineering. As software requirements analysis is an extremely important stage in software life cycle that has an influence on the software project whether is successful or not, and to a large extent affected the quality of software products. Therefore, how to more effectively capture the real needs of users is bound to become the focus of the study. And the scenarios widely recognized as an effective ways for requirements elicitation, documentation and certification, and they support a formal, informal, narrative and concrete style description, and they also concerns the dynamic characteristics of interactive software environment. Thus system devisers and users in the process of needs analysis can easily use the scenarios to express their understanding about the needs for achieving optimal state of the interaction, and better access to user requirements. Only in this way, users take genuine participation in the requirements analysis process can easily map application field problem into computer field, and in the process of iterative requirements capture can automatically adapt to application system requirements constantly changing, and avoid requirements changing resulting in the changing of the structure of the software system. Meanwhile, there exist a timely way to add new or modified not meet the actual requirements of the users, which can help ensure the correct and integrity of application software.At the beginning, we get informal descriptions about scenario, but because software system as an engineer goal consists of runtime environment, they have large differences from context to form. Therefore, mapping between them is essential, which can correctly get modeling on user requirements. Traditional structured method will regard software system as data process, and use function decompose method to make system into difference function module, each module has a sub process. At one time structured method is the mainstream technology in software engineering practice, and has an important influence as yet. With the increasing complexity of modern software systems, continually changing between the various components of dynamic interactive relations, which make the structured method more difficult to use.Therefore, how to induce system functions and interactions between components and participants has become main task in engineering practice. If state model and code frame can be synthesized accordingly, it will be of great benefit to improving software quality and to saving cost. With traditional analysis, informal method and creative thinking will be used in the analytic process. In the meantime, due to different working realms and thinking models, people tend to have communication difficulties, resulting in an incorrect and incomplete requirement specification. So it is also important to fulfill effective communication. Out of these considerations, user should first submit initial positive and negative scenarios, and on the base of which a global system state machine will be created. At the same time, more implicate scenarios (both positive and negative) will be generated, which will assist the generation of the state machine. At last, we will finish the process which involves submitting scenarios of user and requirement model establishment utilizing formal method. Meanwhile, basic concepts of some prevalent formal modeling methods will be introduced with emphasis on automaton and related technologies.In order to study acquiring system behavior specification from scenarios requirement specification, this paper will illustrate procedures of a MSC (Message Sequence Chart) based method for analyzing the requirement specification by an example of modeling a short message system. For the purpose of acquiring formal behavior specification, PTA (Prefix Tree Acceptor) will be synthesized from scenarios submitted by user, that is to say, draw MSC from descriptions of scenarios, then traverse messages in MSC and gain a set of strings of messages, finally connect the messages strings at the point where they have maximum common prefix to form a tree. Because the PTA is directly converted from messages strings of user scenarios, it has not uncover the essence connection between messages and states. It also includes many redundant states which should be merged. Automaton with merged state may accept more strings than unmerged counterpart. These new strings should be submitted to user, so he can judge whether object system permits these messages strings. The answer will assist the merging process. The process is like an abstract machine with inverse signal feedback capability. Its control unit is synthesis algorithm, feedback unit is user, system input is initial scenarios, system output is automaton model with state well merged, feedback input is new messages strings generated from merging state, feedback out is user view on these strings. If have too many or few merge sorts, these excess will be suppressed by negative feedback, making resultant automaton stable and gradual tends to object system. Thus the formal synthesis of user scenarios can be obtained by inducing system model. From resultant automaton, using a set of transition rules, code frame can be written by hand. Finally using object-oriented programming method, each system component will be implemented as a process and filled by concrete codes , the processes from initial scenarios to final codes will be complete.