Presentation on theme: "Documenting Requirements using Use Case Diagrams"— Presentation transcript:
1 Documenting Requirements using Use Case Diagrams
2 UML Unified Modelling Language Developed by Jacobson (1994) Set of diagrams and techniques to model object oriented analysis and design.Use Case diagramsActivity diagramsCommunication diagramsSequence diagramsClass diagramsState diagrams
3 Use Case ModellingUsed to document the scope of the system and the developer’s understanding of what the users require.good for modelling the functional requirements of a system.A separate list of systems requirements both functional and non-functional should also be maintained.
4 Each use case represents one system activity or task- a well-defined part of the system functionality as seen from a specific user(actor)’s point of view.They are backed up by behaviour specifications which specify the behaviour of each case using either UML diagrams or sequence diagrams, or in text form as use case descriptions.ExamplesCalculate stock requirementsCreate film programmeCreate new memberUpdate member detailsPrint season report
5 Requirements Gathering: Use Case Diagram shows SCOPE Source: IBM Rational
8 What is the aim of Use Case modelling? Elicit enough requirements information to prepare a model that communicates what is required from a user perspective.If user’s requirements change through the life cycle, then the change is initiated in the use case model.These changes then dictate what changes need to be made to other models.
9 Use Case Diagrams Business requirements – essential use cases Guest BookspaHotel self service subsystemCheck validroom numberOrder food/drink<<includes>>Requestalarm callGuest
10 Includes relationship Use Case DiagramsShows subsystem boundaryUse caseUse case 1subsystemrelationshipIncludes relationshipshowsShared processUse case 2<<includes>>Use case 3Actor
11 Each Use Case Describes a system function from a user’s perspective Details business events and users interaction with the system during that eventRepresents a system activity, a well-defined part of the system’s functionalityHas a goalIs initiated by an actor, but can interact with other actors.Has a more detailed description, possibly specifying a number of scenarios or alternate courses of action ( e.g. documented in a use case template)
12 Types of Use CaseUse cases are initially defined at a high level and successively refined and detailed as the analysis and software development process unfolds.Essential use case – key business requirements – brief scenario descriptionsReal Use Case – more detail about what actually happens – use case templateWhat are the users trying to accomplish and why?
13 Business Requirements use case Quickly document business events to define and validate requirementsFocus on strategic vision and stakeholder goalsSystem use caseDocument use case narratives to more reflect implementation details and detailed system functionality
14 Relationships Association – communication with use case. Order Phone Customer
15 Relationships: extends Extends – extract more complex steps into their own use case. An extension use case is used when it extends the functionality of a single use case.Used to model optional extras, additional functionality in a use caseto model an extension to or variation of a use case.
16 Example : Extends…Used to specify optional extras, additional functionalityStudent registration subsystemregisterExtension pointsLate paymentIf late payment authorised<<extends>>Process latepaymentstudent
17 Relationships : Include Include – shows shared processesUsed if the intent is to factor common behaviour into its own use case.– abstract use case – find 2 or more use cases that have identical functionality
21 Actors Stakeholders Who provide inputs to system Who receive outputs from systemWho trigger events in the systemWho maintain the information in the systemActors are outside the system
22 Relationships between Actors Generalisation and specialisationExampleCampaign manager can do anything a staff contact can do and more – means that his role is a specialisation of a staff contact role.Inheritance
23 Abstraction Abstracting functionality into super use case - e.g. Assign staff teamAssign staff memberbecomes : Assign staff.This helps define the functionality and helps cut excessive repetition.
24 Primary business actor benefits from action System actor – triggers system eventExternal server actor responds to a requestExternal receiver actor receives something.
25 Identifying use cases… What are the main tasks of each actor?What information does the actor need from the system or provide to the system?Does the system/actor need to inform the system/actor of any changes?