Capturing Requirements As Use CasesRequirements WorkflowArtifact: Use Case ModelArtifact: ActorUse CaseUse Case InstanceDescription of Use CaseExample: Global Network SystemsArchitecture Description - View of Use Case ModelUse Case GlossaryOverview of Use Case DiagramUse Case RelationshipsUse Case RelationshipWorkerSystem AnalystUse Case Specifier and Interface DesignerWorkflow for Capturing RequirementsFind Use Cases and ActorsIdentify Use Case and ActorsBasic StepsDetailing Use CasesFinding ActorsFinding Use CasesConstructing Use Cases1Capturing Requirements As Use Cases•To be discussed–Artifacts created in the requirements workflow–Workers participating in the requirements workflow–Requirements capture workflow, including detailed activities2Requirements Workflow3Artifact: Use Case Model•Allows developer and customer to agree on requirements, I.e. conditions and capabilities to which the system must conform•A model of system containing actors and use cases and their relationships4Artifact: Actor•Represents user type, external system•Each type of users may be represented by one or more actors•Often corresponds to worker in a business–A role of a worker defines what the worker does in a particular business process–The roles can be used to derive corresponding actors will play•An actor plays one role in each use case5Use Case•Each use case represents a way the actors use the system–A use case specifies a sequence of actions, including alternatives of the sequence, that the system can perform–Is a specification of the behavior of all possible instances of that use case–E.g. withdraw money (granted, denied, different amounts, etc)–Purpose: to define a piece of coherent behavior without revealing the internal structure of the system, hence it is not a manifest construct in the implementation of the system–in UML term, a classifier that has operations and attributes, thus can include startchart, activity, collaboration and/or sequence diagrams6Use Case Instance•Is the execution of a use case–It is one path through the use case–An sequence of interactions between an actor instance and the use case•Use case instance does not interact with other use case instances–only kind of interaction is between actor and use case instances–don’t deal with interfaces between use cases, concurrency, and other conflicts (e.g. sharing of objects) between different use case instances (Note: this does not mean interference between different instances does not exist.)•Use Case instance is atomic–either performed completely or not at all7Description of Use Case•Statecharts specifies lifecycle of use case instances–each transition is a sequence of actions•Activity diagrams describe the lifecycle in more detail by describing sequence of actions that occur within each transition•Collaboration/sequence diagrams are used to describe between a typical actor instance and a typical use case instance•Such “formal” description may or may not be necessary depending on the complexity of a use case•Textual description can be used if appropriate8Example: Global Network Systems•Largest system in the world, composed of systems of systems across different areas and countries•Made of different technologies (local and international switches, land and satellite transmission systems•Each system is a large scale one (e.g. 1000 man-years)•Main reason of success: precisely defined interfaces (both structural and semantic)–via provide-require mechanism–is in fact use case specification9Architecture Description - View of Use Case Model•Architecture view (of use case model) describes architecturally significant use cases–use cases describing important and critical functionality–involving important requirement that must be developed early in the software’s lifecycle–used as input when use cases are prioritized to be developed within an iteration•Usually corresponding use case realizations can be found in the architectural views of analysis, design models10Use Case Glossary•Used to define important and common terms used in describing the system•Useful for reaching consensus between different stakeholders regarding definition of various concepts and notions–especially important for large development effort•Can be derived from domain or business models11Overview of Use Case Diagram12Use Case Relationships13Use Case Relationship14Worker•Refer to a position (in a project) to which a person can be assigned, who are responsible for building the use cases•Three types of workers:–system analyst–use case specifier–user interface designer15System Analyst•System analyst responsible for the whole set of requirements (functional and nonfunctional) modeled as use cases –responsible for delimiting the system–for finding actors and use cases and for defining glossary–for ensuring that the use case model is complete and consistent–Assisted by use case specifier and interface designer16Use Case Specifier and Interface Designer•Assist system analyst•Use case specifier responsible for detailed description of one or more use cases–need to work closely with real users•User interface designer responsible for UI–usually one interface prototype for each use case17Workflow for Capturing Requirements18Find Use Cases and Actors•We identify use cases and actors to:–define system boundary–outline who and what (actors) will interact with the system and what functionality (use cases) is expected from the system–capture and define in a glossary common terms that are essential for creating detailed descriptions of the system’s functionality19Identify Use Case and Actors20Basic Steps•Finding the actors•Finding the use cases•Briefly describing each use case•Describing the use case model (including glossary) as a whole•Describe use cases in detail•Steps does not have to be performed in any particular order21Detailing Use Cases22Finding Actors•If a business model known, use each worker in the business as an actor initially•Criteria for enlisting actors–should be possible to identify at least one user who can play the candidate actor–minimal overlap between roles that instances of different actors play in relation to the system•Example: –buyer, seller, accounting system (page 147)•Brief description of actors, used as starting point for finding use cases23Finding Use Cases•Interviewing or analyzing each