Supporting Scenario-Based Requirements Engineering IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 24, NO. 12, DECEMBER, 1998 A. G. Sutcliffe, N. A. M. Maiden, S. Minocha, and D. Manuel Presented by Chin-Yi Tsai

2 Outline Introduction Introduction Background Background Method and Tool Support for Scenario-Based RE Method and Tool Support for Scenario-Based RE Conclusion Conclusion

3 Introduction Scenario Scenario Improve requirement engineering Improve requirement engineering communication communication Scenarios often describe information at the instance or example level Scenarios often describe information at the instance or example level Scenarios are used to represent paths of possible behavior through a use case Scenarios are used to represent paths of possible behavior through a use case Validation AnimationSimulationInspection Test case

4 Introduction (cont’d) Describe a method and tool support for scenario-based Requirements engineering that integrates with use case approaches to object-oriented development. Describe a method and tool support for scenario-based Requirements engineering that integrates with use case approaches to object-oriented development. Use Case

5 Background Few methods advise on how to use scenarios in the process of requirements analysis and validation. Few methods advise on how to use scenarios in the process of requirements analysis and validation. Provide more detailed advice about how scenarios can be used in requirements validation. Provide more detailed advice about how scenarios can be used in requirements validation. Traceability (requirement management) Traceability (requirement management) Doors Doors Requisite Pro Requisite Pro Requirement reuse Requirement reuse pattern pattern Rational Rose

6 Method and Tool Support for Scenario-Based RE How Use Case Model

7 Elicit and document use case Elicit and document use case Use case are elicited directly from user Use case are elicited directly from user The use case model is validated for correctness with respect to its syntax and semantics The use case model is validated for correctness with respect to its syntax and semantics Analyze generic problem and requirements Analyze generic problem and requirements A library of reusable, generic requirements attached to models of application classes is provided A library of reusable, generic requirements attached to models of application classes is provided Generic requirements are proposed at two level Generic requirements are proposed at two level General routines for handling different event patterns General routines for handling different event patterns Requirements associated with application classes held in the repository Requirements associated with application classes held in the repository Generate scenario Generate scenario Generate scenarios by walking through each possible event sequence in the use case Generate scenarios by walking through each possible event sequence in the use case Each pathway becomes a scenario Each pathway becomes a scenario Validate system requirements using scenarios Validate system requirements using scenarios Generation is followed by tool-assisted validation which detects event pattern in scenario and presents checklists of generic requirements that are appropriate for particular normal and abnormal event patterns Generation is followed by tool-assisted validation which detects event pattern in scenario and presents checklists of generic requirements that are appropriate for particular normal and abnormal event patterns Interactive dialogue Interactive dialogue

8 Schema for Scenario-Based Requirements Modeling Metaschema for modeling use cases and scenario based knowledge

9 Action Action Cognitive Cognitive Physical Physical System-driven System-driven communicative communicative Each action has one start event and one end event Each action has one start event and one end event Action are linked through eight types of action-link rules Action are linked through eight types of action-link rules Each action involves one or more agents. Each action involves one or more agents. Agents have user-defined properties that describe their knowledge and competencies Agents have user-defined properties that describe their knowledge and competencies

10 Action-agent links are specified by an involvement relation that can be subtyped as {performs, starts, ends, controls, responsible} Action-agent links are specified by an involvement relation that can be subtyped as {performs, starts, ends, controls, responsible} agentactionPerformsStartsEndsControlsresponsible

11 Tool Main Function Incremental specification of use cases and high-level system requirement Incremental specification of use cases and high-level system requirement The domain/use case modeler The domain/use case modeler Automatic generation of scenarios from a use case Automatic generation of scenarios from a use case Scenario generator Scenario generator Manual description of use cases and scenario from historical data of previous system use Manual description of use cases and scenario from historical data of previous system use use case/scenario authoring components use case/scenario authoring components Presentation of scenario, supporting user-led walk-through and validation of system requirements Presentation of scenario, supporting user-led walk-through and validation of system requirements Scenario presenter Scenario presenter Semiautomatic validation of incomplete and incorrect system requirements using commonly occurring scenario event patterns Semiautomatic validation of incomplete and incorrect system requirements using commonly occurring scenario event patterns Requirements validator Requirements validator

12 Tool Support

13 Use Cases Specification The user specifies a use case using CREWS-SAVRE’s domain and use case modeler components. The user specifies a use case using CREWS-SAVRE’s domain and use case modeler components. Software engineer specifies all actions in the domain, defines agents, and objects linked to these actions, assigns types to each action, and specifies permissible action sequence using action-link rules. Software engineer specifies all actions in the domain, defines agents, and objects linked to these actions, assigns types to each action, and specifies permissible action sequence using action-link rules. A use case acts as a container of domain information relevant to the current scenario analysis A use case acts as a container of domain information relevant to the current scenario analysis Actions are defined by Actions are defined by ev(startA) < ev(endA) and ev(startB) < ev(endB) ev(startA) < ev(endA) and ev(startB) < ev(endB)

14 Action-link rule Strict sequence (A then B) Strict sequence (A then B) Part sequence (A meanwhile B) Part sequence (A meanwhile B) Inclusion (A includes B) Inclusion (A includes B) Concurrent (A and B) Concurrent (A and B) Alternative (A or B) Alternative (A or B) Parallel and equal (A parallel B) Parallel and equal (A parallel B) Equal-start (A starts-with B) Equal-start (A starts-with B) Equal-end (A ends-with B) Equal-end (A ends-with B)

15 Checking the Use Case Specification Validation rules check the integrity of the relationships Validation rules check the integrity of the relationships Validation checks are carried out by clusters of rules, called validation-frames which are composed of two parts. Validation checks are carried out by clusters of rules, called validation-frames which are composed of two parts. Structural pattern Structural pattern requirement requirement Frames are used for validating the consistency of use case models against the schema Frames are used for validating the consistency of use case models against the schema

16 Using Application Classes to Identify Generic Requirement A library of application classes, termed object system models (OSMs) has been developed and validated in our previous work on computational models of analogical structure matching. A library of application classes, termed object system models (OSMs) has been developed and validated in our previous work on computational models of analogical structure matching. OSMs are organized in 11 families and describe a wide variety of application classes. OSMs are organized in 11 families and describe a wide variety of application classes. Each OSM is composed of a set of cooperating objects, agents and actions that achieve a goal, so they facilitate reuse at the system level rather than as isolated generic classes. Each OSM is composed of a set of cooperating objects, agents and actions that achieve a goal, so they facilitate reuse at the system level rather than as isolated generic classes.

17 Scenario Generation This stage generates one or more scenarios from a use case specification This stage generates one or more scenarios from a use case specification The scenario generation algorithm reduces this space by first determining the legal sequences of action The scenario generation algorithm reduces this space by first determining the legal sequences of action

18 Scenario Generation

19 Scenario Validation User-led walkthrough User-led walkthrough Semiautomatic validation of requirements through the application of pattern matching algorithms to each scenario Semiautomatic validation of requirements through the application of pattern matching algorithms to each scenario

20

21 Conclusion

22 Rational Unified Process Phases Phases Inception Inception Elaboration Elaboration Construction Construction Transition Transition Disciplines Disciplines Business Modeling Business Modeling Requirements Requirements Analysis & Design Analysis & Design Implementation Implementation Test Test Deployment Deployment Configuration & Change Management Configuration & Change Management Project Management Project Management Environment Environment Iterative Incremental