COMMONWEALTH OF AUSTRALIA
FIT2005 Software Analysis, Design and Architecture
Copyright Regulations 1969 WARNING
Module 2: Requirements and Use Case Modelling
www.monash.edu.au
This material has been reproduced and communicated to you by or on behalf of Monash University pursuant to Part VB of the Copyright Act 1968 (the Act). The material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice.
2
Module 2 Objectives
On completion of this session you should have a basic conceptual understanding of: actors, use cases, and the system boundary; the difference between functional and non-functional requirements the purpose and activities of the requirements workflow of the UP; the process by which a detailed use case description is developed
Module 2 Objectives (continued)
On completion of this module you should be able to: identify requirements for a proposed system; classify a requirement as being functional or non-functional; identify actors that participate in use cases and describe their personality; identify use cases that are required to be supported by the system; interpret a use case diagram to reason about a system; produce use case diagrams to summarise a system; develop detailed use case descriptions; interpret use case descriptions; utilise advanced constructs in specifying use case descriptions, including use of alternative flows, selective flows, repeated flows, inclusion and extension of other use cases
3 4
Software Requirements Specification
A set of documents which specifies what the system is required to do/be Requirements do not state how the system will do things. Functional Requirements what behavior the system should offer Non-Functional Requirements specific properties or constraints on the system or its behaviour
E.g. usability, reliability, performance, security and supportability
Software Requirements Specification (2)
Requirements can be expressed as a list of imperative statements, e.g.:
The <system> shall <function> The Library Borrowing System shall allow a patron to borrow up to 10 items concurrently (functional) The Library Borrowing System shall allow 400 concurrent users of the catalogue searching function at all times (non-functional)
Uniquely number each requirement (for referencing) Use Cases should also be used to describe sequences of actions typically intended to support business processes
Use Cases complement the imperative statements
5 6
The Requirements Workflow
Purpose/Goals [Kruchten, ch 9]: To discover and reach agreement with customers and other stakeholders on what the system should do
Eliciting and prioritizing requirements from stakeholders Process of negotiation: balancing conflicting interests/desires
Activities of the Requirements Workflow (1)
To provide system developers with better understanding of the system requirements To define the boundaries of the system To provide a basis for planning the technical content of iterations To provide a basis for estimating cost/time to develop
7 8
Source: Arlow
Activities of the Requirements Workflow (2)
The Requirements Workflow Use Case Modeling
Use Case Modeling is a form of requirements engineering Focused on finding Actors and Use Cases Complements the list of functional and non-functional requirements
Focus is on interactions between the actors and the system
Use cases will form the base (reference) for later modeling tasks
10
Finding Requirements
Interviews Questionnaires Workshop/Brainstorm session
Prioritizing Requirements - MoSCoW
Must have - Mandatory Should have important but not mandatory (could omit) Could have truly optional (include if time permits) Want to have can wait for future software versions
The study guide lists a range of questions to guide the process of thinking about issues when determining requirements. (pp. 26 29 )
11
12
The Subject
Also called System Boundary
FIT2005 Software Analysis, Design and Architecture
Defines what is part of the system (inside) and what is external to the system (outside the boundary) Defined by who or what uses the system
Called Actors
and the benefits the system offers to the actors
Called Use Cases
Use Case Concepts
www.monash.edu.au
14
Actors
An abstraction of a role that some external entity adopts when interacting with the system In the real world, one person may fulfill multiple roles at different times, and one role may be fulfilled by different people Actors need a name which clearly describes the role
Example roles: Customer, OrderClerk, Administrator,
Actor vs Internal representation
Often there is data about particular actors kept in the system. The Actor in use case modelling is always external to system: an actual person, or actual other system
Actors interact directly with the system
Particular actors may be represented by some data object inside the system
e.g. a Customer object which is a representation of information about a particular Customer actor
Actors are always external to the system
Other systems can be Actors for the current system (e.g. Credit Card Agency System can be an Actor of our system)
15
16
Finding Actors
To find actors: Who or what uses the system?
Installs, starts and shuts down, maintains, enters data, produces reports
Actor Personalities
Initiator responsible for starting one or more use cases External server provides information or performs a service required by the system Receiver receives information from the system Facilitator/Proxy an actor who directly interacts with the system on behalf of some other actor
Does anything happen at fixed times or intervals? Who or what uses the outputs of the system? Who or what provides the inputs for the system? What other systems interact with the system?
Time can also be an actor.
Actors are named using a noun
17 18
Use Cases
Something which an actor wants the system to do/allow A specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem or class can perform by interacting with outside actors (Booch) Always started by an actor Written from the Actors point of view
How the actor perceives the systems behavior.
Orientation of Use Cases
Input-oriented use case one which is predominantly for obtaining information from an actor for storing in the system.
For example, entering the customers details into the system.
Output-oriented use case one which is predominantly for producing a report, or giving information to an actor.
Example: printing an invoice
Each use case needs a name
Use a verb-phrase, e.g. Create New Order, Display Exam Results
19
Processing-oriented use case one which is predominantly for manipulating data that is already in the system, usually in response to additional information being received or the passage of time
Example: determine which products are low in stock
20
Identifying Candidate Use Cases
Think about how each actor will use the system
What functions do they want/expect? What information do they want to store and retrieve?
Use Case Specification
Once a use case is identified, need to specify its detail: Name, and maybe a numeric ID for reference Brief description explain purpose/goal of use case Name the actors involved List any preconditions situation required to enable the use case to execute Describe the main flow (next slide) List any postconditions situation which will be true after use case has executed. List possible alternative flows
21 22
What happens when the system changes state
Does an actor need to be notified?
Do external events affect this system?
What notifies this system?
Does this system interact with other systems?
Why, When?
Does the system generate any reports?
What reports? Who for? When/How?
Main Flow of Use Case
Describes the sequence of events to accomplish the goal of the use case Consists of short/atomic steps that are time-ordered Each step is numbered Each step says what is done, and by what (either the Actor, or the System)
<number> The <something> <some action>
Example Use Case
Use Case: Check Unit Results Brief Description: The student checks to see the results for previous semesters Primary Actors: Student Secondary Actors: None Pre-condition: The student has logged in Main Flow: 1. The use case starts when the Student selects to view their past results 2. A list of units which were studied by the student is presented 3. If the Student selects a unit which they have completed
3.1 The system displays the results for that unit
Always begin with the primary actor doing something to trigger the use case
Post condition: None
23 24
Dont be vague
Problems can arise if too imprecise Example: Customer details are entered
Who enters the details? Entered where/ into what? What actually are details?
Branching and Repetition in Use Cases
The IF keyword can be used to indicate a branch (selection) in a flow The things to be done are indented, and given new numbering prefixed by the main-step number Example:
Keyword to indicate selection
Ask the following:
Who specifically ? What specifically ? When ? Where ?
3. If the Student selects a unit which they have completed
3.1 The system displays the results for that unit
Number re-starts at 1, prefixed by parent number and dot.
4. Else
The keyword Else by itself can be used for the alternative situation
4.1 The system display a message stating no result is available
25 26
Branching and Repetition in Use Cases
Repetition sometimes needed when dealing with reporting Can use For, While Body is indented and steps numbered as for the IF Example (Arlow Fig 4.10):
4. The system searches for products which match the customers criteria 5. If the system finds some matching products then 5.1 For each product found 5.1.1 The system displays a thumbnail sketch of the product 5.1.2 The system displays a summary of the product details 5.1.3 The system displays the product price 6. Else 6.1 The system tells the Customer that no matching products could be found
27
Alternative Flows
An Alternative Flow is a deviation from the normal flow of a use case
Error situations Long branches which do not easily fit within the normal flow Interruptions of the main flow
Might return to continue the main flow; might not Can be triggered in one of 3 ways:
Instead of the main flow After a particular step in the main flow At any time during the main flow
First step of alternative flow should say when flow is triggered to commence.
28
Example Alternative Flow [Arlow Fig 4.14]
Alternative Flow: CreateNewAccount:InvalidEmailAddress Brief Description: The system informs the customer that he or she has entered an invalid e-mail address Primary Actors: Customer Secondary Actors: None Pre-conditions: 1. The Customer has entered an invalid e-mail address Alternative Flow: 1. The alternative flow begins after step 2.2 of the main flow 2. The system informs the Customer that he or she entered an invalid e-mail address Post conditions: None
29
Example Alternative Flow [Arlow Fig 4.15]
Alternative Flow: CreateNewAccount:Cancel Brief Description: The customer cancels the account creation process. Primary Actors: Customer Secondary Actors: None Pre-conditions: None Alternative Flow: 1. The alternative flow begins at any time. 2. The Customer cancels account creation. Post conditions: 1. A new account has not been created for the Customer.
30
Use Case Diagram
One of the diagrams in UML Graphically presents a summary of the subject, the actors and the use cases of a system
FIT2005 Software Analysis, Design and Architecture
Advanced Concepts in Use Case Development
[Source: Arlow]
31
www.monash.edu.au
Actor Generalization
Some Actors may participate in common use cases Actor Generalization creation of a more abstract Actor that participates in use cases For example, with many of Monashs online systems (WES, AllocatePlus, etc.) some uses are available to both staff and students.
An actor named MonashPerson could be made, and be the Actor for these use cases Specialized actors can be made which inherit from MonashPerson all the relationships it has to use cases
Actor Generalization Example
Staff can:
Select unit View timetable Display class list
Student can:
Select unit View timetable Select class
33
34
include and inclusion use case fragments
When sequences are frequently needed by multiple use cases
Could be repetitive Factor the common part into its own use case
include Example
One use case (called the base use case) can include the behavior of another use case (the inclusion use case) through an include relationship Must explicitly state where in base that the inclusion is to occur, e.g.: . 3. include (SomeCase) 4. continuation of base use case
35 36
Example Use Case including another
Use Case: SelectClass Brief Description: The student selects a class time to attend for a particular unit Primary Actors: Student Secondary Actors: None Pre-condition: None Main Flow: 1. Include (SelectUnit) 2. The system displays the choices of class time for the selected unit 3. The Student selects one of the class times 4. The system records the students preference of class time Post condition: The students preferred class time has been noted in the system
37
Example Inclusion Use Case
Use Case: SelectUnit Brief Description: The user selects a particular unit Primary Actors: MonashPerson Secondary Actors: None Pre-condition: None Main Flow: 1. The system displays a set of units which are offering classes 2. The MonashPerson selects one of the units Post condition: A unit has been selected
38
Note the more general Actor
Extension Points
Extension Points are provisions in a use case for future or conditional insertion of additional behavior.
Contrasting to inclusion, which is mandatory inclusion.
Avoid Functional Decomposition
Common Error is to form high-level use cases and break these down into lower-level use cases
Bad because this leads to an artificial structuring; higher-level ones dont really do anything Does not match the object-oriented paradigm Hard for stakeholders to understand
A base use case can declare multiple extension points Some other use case (the extension use case) can define 1 or more behavior fragments to be inserted at a subset of the defined extension points. If more than one extension use case exists for a base use case, they might all be inserted when the base executes
Order in which the extension use cases are executed is not defined
Example Bad Design Arlow Fig 5.16
Examples: Arlow figures 5.11 and 5.13
39 40
Readings
Ensure that you have read the Study Guide module
Arlow: Chapters 3, 4 and 5 Armour: selected pages as scanned
Read through the case study to prepare for the upcoming tutorial
41
