1. SE 555 Software Requirements & Specification1 Use-Case Modeling: Overview and Context

2. 2 SE 555 Software Requirements & Specification Essential SE Process Application Domain Conceptual Models Formal Models Implementation Domain The Software Engineering Process transforms conceptual application models into detailed solution models Transform From Bruce I. Blum, Software Engineering - a Holistic View Problem space Customer-speak Solution space Developer-speak Computer-speak programming languages systems languages Run-time space Computer-speak binary

3. 3 SE 555 Software Requirements & Specification Each Discipline Contributes a Particular Set of Models (and other Artifacts)

4. 4 SE 555 Software Requirements & Specification Model Characteristics RequirementsAnalysisDesignImplementationTest Feature lists Domain models Use cases Customer language External view Unambiguous models Consistent use cases Developer language Internal view Sets solution architecture Conceptual Informal models Few abstractions, subsystems, interfaces Physical Technologies and “-ilities” Many abstractions, subsystems, interfaces Detailed Formal Implement details (source, scripts, binaries, executables, etc.) Distribute executable components across computing nodes Unit test Test cases, procedures, components Integration and system tests Feed results back into process Transform Models

5. 5 SE 555 Software Requirements & Specification Model (specify) requirements as use cases In requirements analysis, model use- case realizations Model an interaction of objects that realize the requirements Class diagrams and object interaction diagrams

6. 6 SE 555 Software Requirements & Specification What is a Use Case? A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system. Use cases are a means for specifying required usages of a system Typically, use cases are used to capture the requirements of a system, that is, what a system is supposed to do The key concepts associated with use cases are actors, use cases, and the subject The subject is the system under consideration to which the use cases apply The users and any other systems that may interact with the subject are represented as actors Actors always model entities that are outside the system The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors [from the UML 2.0 Superstructure Specification]

7. 7 SE 555 Software Requirements & Specification Use Cases Capture Requirements Use cases capture system functional requirements They tell a story of how someone may use the system When an actor (user or external subsystem) uses the system, the system performs a use case Each way the actors use the system is represented by a use case Chunks of functionality the system offers to add an observable result of value to its actors All use cases = all the things the system must do

8. 8 SE 555 Software Requirements & Specification Use Cases Capture Requirements Use cases capture the intended behavior of the system Ways an external user (human or machine) interact with a system System behavior is how a system acts and reacts The outwardly visible and testable activity of a system Use cases describe the system, its environment, and the relationship between the system and its environment For many non-interactive systems (batch processes, data warehousing, infrastructure management, etc.), there may be few use cases with complex use-case descriptions

9. 9 SE 555 Software Requirements & Specification Example Use- Case Diagram Create/Modify Document Publish Document > Find Document Retrieve Document > Document Author or Adopter External Document System Standards User Notify of New/Changed Document > Administer System View Metrics and Reports Administrator (Standards Program Office) External System Data Exchange/Web Site Launch NASA Integrated Technical Standards System

10. 10 SE 555 Software Requirements & Specification Use-Case Realization Collaboration diagram Sequence diagram Class diagram GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) fList 1 FileList add( ) delete( ) 1 File read( ) read() fill the code.. Use Cases Use Case Use-Case Realization  A use-case realization is a description of how a particular use case is realized within the design model, in terms of collaborating objects >

11. 11 SE 555 Software Requirements & Specification Major Concepts in Use-Case Modeling An actor represents anything that interacts with the system A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor UseCase Actor >

12. 12 SE 555 Software Requirements & Specification Use-Case Diagram A use-case diagram shows relationships between actors and use cases Relationships: “communicates with” (exchanges data, signals, events) System Note: the system boundary is usually not shown

13. 13 SE 555 Software Requirements & Specification Use-Case Model A use-case model is more than a uc diagram Each use-case has a specification Use-case name Relationships to actors and other use cases Brief description Start states (preconditions) The first action to perform Flow of events (often captured as a UML Activity Diagram) Basic/normal flow Alternates Constraints How the use case ends Possible end states (postconditions) Special (non-functional) requirements

14. 14 SE 555 Software Requirements & Specification Advanced Use Case Concepts Generalize: child inherits the behavior and meaning of its parent; can substitute for its parent Include: the base use case explicitly incorporates the behavior of another use case at a location specified in the base use case; factor out common behavior – never stands alone Extend: the base use case implicitly incorporates the behavior of another use case at a location specified indirectly by the extending use case; optional behavior

15. SE 555 Software Requirements & Specification15 Requirements Discipline Activities From the Rational Unified Process

16. 16 SE 555 Software Requirements & Specification Requirements Discipline in the RUP Context

17. 17 SE 555 Software Requirements & Specification Requirements Workflow Shown in sequence, but performed continuously and in varied order Inception phase: emphasize understanding the problem Elaboration phase: emphasize defining and refining the system Construction and transition phases: add remaining details and manage changes Focus on these

18. 18 SE 555 Software Requirements & Specification Requirements Artifacts Overview Focus on these

19. 19 SE 555 Software Requirements & Specification Purpose of the Requirements Discipline To establish and maintain agreement with the customers and other stakeholders on what the system should do To provide system developers with a better understanding of the system requirements To define the boundaries of (delimit) the system To provide a basis for planning the technical contents of iterations To provide a basis for estimating cost and time to develop the system To define a user-interface for the system, focusing on the needs and goals of the users

20. 20 SE 555 Software Requirements & Specification Sources: Material © IBM Rational Software Corp.