SYS366 Presentation

1. SYS366
The Last Stage in Analysis:
System Use Specifications created
through Use case Authoring

2. Today
• Systems Use Case Specifications
• Systems Use Case Authoring

3. Our Metaphor
• Specifications are based
on the dialogue metaphor
• This dialogue expresses
that the User and
Computer Interact by
Sending Messages

4. What is a dialogue?

5. Designing Dialogs
• The process of designing the overall sequences that users
follow to interact with an information system
• the sequence in which information is displayed to and
obtained from the user

6. Sequence
• understanding how the user will interact with the system
• clear understanding of user, task, technological and
environmental characteristics

7. “
”
The [systems] use case specifications
provide the substance of the [systems] use
case model and they are the basis for most
of the …modeling work… More than 90% of
the [systems] use-case model lies beneath
the surface, in the textual use-case
specifications themselves
Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 30

8. “
”
[Systems] use cases are more than just a
named ellipse and a brief description. For
each [systems] use case there will also be a
[systems] use-case specification where the
full story of the use case is told.
Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 30

9. Systems Use Case Specifications
• “The use case specification tells a story of how a
system and its actors collaborate to achieve a
specific goal
• This collaboration takes the form of a dialogue
between the system and its actors
• It is a step-by-step description of a particular way
of using a system”*
*Use Case Modeling, Kurt Bittner & Ian Spence,Addison-Wesley, 2003, p. 24

10. Story-based Structure
• “Just like a story, every
use case should have
• a clear beginning (how the
actor starts the use case)
• Middle (how the system
and actors work together)
• End how the use case is
concluded”*
*Use Case Modeling, Kurt Bittner & Ian Spence,Addison-Wesley, 2003, p. 24

11. Systems Use Case Specification
• Not a complete description of all possible ways that some
task is performed
• Does not say how the system is designed or implemented
• Describes typical ways (or cases) of using the system*
*Use Case Modeling, Kurt Bittner & Ian Spence,Addison-Wesley, 2003, pp. 24-25

12. Systems Use Case Specifications
Systems Use Case Specifications are required to define, in
detail, the processing that needs to happen in each use case

13. Systems Use Case Specifications
• The Systems Use Case Specification must include:
• Who the actors are
• How the actors are interacting with the system at any point in
time
• What data is used and how
• All normal logic (HD)

14. Today
• Systems Use Case Specifications
• Systems Use Cases Authoring

15. “
”
The Systems Use Case and its
Specification evolves through the
authoring process.
*Systems Use Cases Modeling by Bittner & Spence, Page 152

16. The Authoring Life Cycle
Start Discover Briefly Describe
Scenario Detailed Description
Complete System Use
Case Specification
Complete

17. Step 1: Discovery
• Through the identified Features and Functions
• Through experience
• Shown on a Systems Use Case diagram
• Place holder for the Systems Use Case Specification
• AVisual Index, providing a context for the Specification
* Systems Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, pp.
153-154

18. Step 2: Brief Description
• Once the Systems Use Case has been identified, it should
be described
• Example: MaintainUsers
This Use Case enables a System Administrator to
add new users to the system when they join the
company, update existing user information, and
remove users when they should no longer have
access. The manager may also produce reports
and send login information to users if required

19. Step 3: Scenario
• Focuses on the most important behaviour of the system
• Represents a single path through the logic of the use case
• Emphasizes usability
• Helps describe user intent and actions, along with the response of
the system
• Describes what is happening inside the system

20. Example of an Scenario Dialogue
Step Actor (Administrator) System
1 Request to add new user Display user entry form
Request username and password
2 Provide new user’s
username and password
Validate data entered
Request additional information
3 Enter full user details Wait
4 Complete data entry Validate data
Save new user to system
Return to main menu and display
confirmation message

21. The Scenario
The goal of a scenario is to capture the essence of the
required dialog without forcing the designers into any
particular technology or mode of interaction

23. The Scenario and UI
• Scenarios are very effective for facilitating user
interfaces, but do not determine the user interface
• Too much detail often limits and constrains the creativity
of the user interface designer’s possibilities

24. Step 4: Detailed Description
• Start adding to the Scenario the detail required to
complete the full specification of the system:
• Preconditions
• Successful Post Conditions
• Data Used
• Here the use case is evolving as more and more detail is
added to flesh out the processing

25. Step 5: Fully Described
• The final state in the evolution of a use case specification
• The use case specification now has a complete set of
scenarios
• Unambiguously defines all of the inputs and outputs
involved in the processing

26. Step 5: Fully Described
• One of the best checks of whether a use case
specification is finished is to ask if you could use the
scenarios to derive system tests.
• The best way to tell if the use cases fit the purpose is to
pass them along to the test team for test design.
• If the team is satisfied that they can use the use cases to
support this activity, then the use case specifications
contain sufficient levels of detail.