1. Get Requirements
2. Describe the app
3. Identify Main Objects
4. Describe Interactions
5. Create Class Diagram

 

Requirements Analysis

 

• Functional
  • Features
  • Capabilities
• Non-Func
  • Help
  • Legal
  • Performance
  • Support
  • Security

• FURPS
  • Functional
  • Usability
  • Reliability
  • Performance
  • Supportability

Expect Requirements to Change!

 

Expect something documented

 

 

Use Cases

 

User focus

 

Specify how user interacts with app

 

Use Case

• Title What’s the goal? Keep it short
• Actor Who wants it? Different people types or computers / data
• Steps How do you achieve it? Single Paragraph, or Numbered List

Max of 1 or 2 days. Anything else is focussing on use cases, not the product!

 

Remember, requirements will change, stuff will have to be revisited / redone!

 

Actors

 

Can be user, application, system

 

ID Actors

• External Systems / Organisations
• Roles / Security Groups
• Job Titles / Departments

Focus should be on the goal that the actor wants to achieve

 

 

Scenarios

 

• Describes a goal that an actor can accomplish in a single encounter
• Focus on the actors goal, not what they need to do to achieve that goal
• Can have multiple scenarios
• Go for simplicity
• Use active voice
• Omit needless words / detail
• Not pseudo code / too much detail
• Focus on intention
• Use Case Prompts
  • Who does Sys admin?
  • Who Managers users & security?
  • What happens if system fails?
  • Is anyone looking at performance metrics / logs?

 

Use Case Diagrams

 

Diagram of several use cases, looked at the same time

 

To get the bigger picture

 

• List the goals, the use cases – draw ellipse around each
• Draw box around all the goals
• List the actors – use stick figures
• Draw line from actor to goals
• Add any non-human systems, on the other side

• Primary actors on the LHS. These are the actors that initiate
• Secondary actors on the RHS. These actors take more of a reactive role
• No order / sequence