VIEWS: 2 PAGES: 25 POSTED ON: 9/5/2012
Documenting Requirements using Use Case Diagrams UML • Unified Modelling Language • Developed by Jacobson (1994) • Set of diagrams and techniques to model object oriented analysis and design. – Use Case diagrams – Activity diagrams – Communication diagrams – Sequence diagrams – Class diagrams – State diagrams Use Case Modelling • Used 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. • 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. • Examples • Calculate stock requirements • Create film programme • Create new member • Update member details • Print season report Requirements Gathering: Use Case Diagram shows SCOPE Source: IBM Rational . . 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. Use Case Diagrams • Business requirements – essential use cases Hotel self Book service subsystem spa Order food/ Check valid drink room number Request Guest alarm call Use Case Diagrams Shows subsystem boundary Use case subsystem Use case 1 relationship Includes relationship Use case 2 shows Shared process Use case 3 Actor Each Use Case • Describes a system function from a user’s perspective • Details business events and users interaction with the system during that event • Represents a system activity, a well-defined part of the system’s functionality • Has a goal • Is 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) Types of Use Case • Use 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 descriptions • Real Use Case – more detail about what actually happens – use case template What are the users trying to accomplish and why? Business Requirements use case • Quickly document business events to define and validate requirements • Focus on strategic vision and stakeholder goals System use case • Document use case narratives to more reflect implementation details and detailed system functionality Relationships • Association – communication with use case. Order Phone Customer 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 case • to model an extension to or variation of a use case. Example : Extends… Used to specify optional extras, additional functionality Student registration subsystem register Extension points Late payment If late payment authorised student Process late payment Relationships : Include • Include – shows shared processes • Used 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 Example : Includes… Library Examine account subsystem Search online Login databases student Search ebrary Note..... • Conditions can be shown as UML comments • Arrows always point at the use case that is being included or extended. Relationships : dependency, inheritance • Dependency – depends on – shows sequencing need. • Inheritance. Actors Stakeholders • Who provide inputs to system • Who receive outputs from system • Who trigger events in the system • Who maintain the information in the system Actors are outside the system Relationships between Actors Generalisation and specialisation Example • Campaign manager can do anything a staff contact can do and more – means that his role is a specialisation of a staff contact role. • Inheritance Abstraction Abstracting functionality into super use case - e.g. • Assign staff team • Assign staff member becomes : Assign staff. This helps define the functionality and helps cut excessive repetition. • Primary business actor benefits from action • System actor – triggers system event • External server actor responds to a request • External receiver actor receives something. 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?
Pages to are hidden for
"Documenting Requirements using Use Case Diagrams"Please download to view full document