- Get Requirements
- Describe the app
- Identify Main Objects
- Describe Interactions
- 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