CSCE 431 Lecture 5

« previous | Tuesday, January 28, 2014 | next »

Scenarios

• Describe concrete, precise use cases (easier for users to relate)
• Scenario should mention participants
• Don't expect precise/verbose scenarios if system does not exist

Useful Questions:

• What are the primary tasks that the system needs to preform?
• What data will an actor create, store, change, remove, or add in the system?
• What external changes does the system need to know about? (e.g. environment)
• What changes or events will an actor of the system need to be informed about?

Perform task observation if system already exists (re-engineering)

Speak with end-users, not just client

Expect resistance

Use Cases

Based on scenarios

Defines a goal-oriented set of interactions between external actors and the system under consideration.

Use case initiated by user with a particular goal in mind, and completes when goal is satisfied

Includes possible variations of a sequence and events that might lead to errors

System treated as a "black box" (helps define API)

Capture who does what and for what purpose/goal (helps prioritize goals)

Advice

• Describe a business task (something the user wants)
• Not be implementation-specific
• Provide appropriate level of detail
• Be short enough to be implemented by one developer in one release.

Debated Value

• Not abstract enough
• Too specific
• cannot capture all requirements of a system.

Use cases should be used to determine if requirements are adequate.

Unified Modeling Language (UML)

Diagrams to precisely describe objects, systems, or events

• Use case diagrams
  • actor represents role (kind of user) in system
    • has unique name and description
    • e.g. student: a person that studies; random number generator
  • use case represents class of functionality provided by system
    • include narrative containing participating actors, entry conditions, event flow, exit condition, exceptions
    • nonfunctional requirements: security, reliability performance
  • related use cases
    • «extend» handle exceptional/rare situations, but leave details out of main functionality
    • «include» incorporate functionality from other aspects
• Class diagrams
• Sequence diagrams
• Statechart diagrams
• Activity diagrams