Animation of requirements specifications

Abstract

Requirements analysis has been recognized as one of the most critical and difficult tasks in software engineering. The need for tool support is essential. This paper reports some work done to provide such support for interpretation and validation of requirements specifications by animation.The Animator provides facilities for the selection and execution of a transaction to reflect the specified behaviour of a particular scenario specified in the requirements specification. Actions are described in terms of input-output mappings and/or functions with pattern matching. Simple rules can be specified to control the triggering of actions. In addition, facilities are provided to replay and interact with transactions. User interaction during animation includes the ability to change data values or role play selected actions as desired. A full graphical interface is supported.The approach has been tested by the provision of an Animator for the requirements analysis method CORE and an associated 'Analyst Workstation'. Animation has been tested on a numberof small examples and a major case study. This paper describes the Animator, justifies the approach taken and discusses experience and future work.KEY WORDS Requirements analysis Requirements specification Animation Tool support INTRODUCTION Requirements analysisRequirements analysis is one of the most critical tasks in software engineering. Unrecognized errors made early in the development process may have widespread repercussions in the later phases. As a consequence, the cost of correcting such errors is high.' Support for requirements analysis is therefore crucial.Requirements analysis consists of three interrelated activities : requirements elicitation, specification and validation. Elicitation is the process of collecting together, from the clients and users, all the facts relating to the required system. The user or client provides his view of the requirements, including both relevant and irrelevant information, and omitting other facts which are forgotten or deemed to be obvious for his application domain. The requirements analyst, who is not necessarily an expert in the particular domain, must try to organize this information into a form which helps to identify relevant and missing requirements, and copes with large amounts of complex information. Requirements analysis is not merely a specification of the system, but rather a process, whose end product is a specification. Since this process is complex

Task-based conceptual graphs as a basis for automating software development

“…As mentioned in Ref. 36, using executable specifications requires more mathematical sophistication than is usually available from analysts or their clients.…”

Using scenarios to validate requirements in a plausibility-centred approach

“…Techniques can be distinguished to be from extrinsic (those with no concern for the semantic properties of the specifications), such as those based on visualisation techniques, to intrinsic (those involving the validation of the contents and use of the specifications themselves), such as those based on syntaxchecking, behavioural checking, or scenario analysis [24]; 3. FORMALITY This distinguishes validation techniques from formal ones (those based on formal methods like modelling languages) such as in [7], to informal ones, such as those based on brainstorming, open-ended meetings, reviewing, or visualisation techniques [17], [19].…”