BTS330: Business Requirements Analysis using OO Lecture 7: Understanding User Requirements

BTS330: Business Requirements Analysis using OO

Lecture 7: Understanding User Requirements

Agenda

Review Hearing Requirements Understanding Requirements

Requirements Development Cycle

Elicitation Analysis Specification Validation

Clarify

Correct and close gaps

Rewrite

Re-evaluate

Text, p. 59

Process (Iterative!)

1. Define Vision/Scope

2. Identify users/stakeholders: classes, reps, decision makers

3. Select elicitation techniques

4. Identify, prioritize and develop use cases– Some modeling here (e.g. user interfaces)– Includes business rules

…and so on

Agenda

Review Hearing Requirements Understanding Requirements

Hearing Requirements

Use domain vocabulary, not “techtalk” Provide glossary to explain terms across

project participants Discussing possibilities IS NOT a

commitment Stakeholdersfocus and prioritize “blue

sky” wish

Hearing Requirements

Ask the right questions– Open ended

• “Describe…”

• “Explain…

– Task/Job Descriptions• “What tasks…”

– Suggestions, Exceptions• “What else could…”

• “What things annoy you…”

Categorizing What You Hear

Vision/Scope Document– Business requirements

Use Case Document– Use cases/scenarios

• User needs to <do something>

– Business rules• Must conform to/comply with some policy/formula

Categorizing What You Hear

Software Specification– Functional requirements– Quality attributes– External Interface Requirements– Constraints

Getting It All

Get enough detail to eliminate fuzziness All users? Full Coverage?

– E.g. “life of an order”

Diagrams/Charts CRUD Matrix (p. 128)—use case vs entity

When are you done?

Hearing “nothing new” Hearing only things outside of scope or

release Hearing low priority

Agenda

Review Hearing Requirements Understanding Requirements

Use Cases

A very rough description:– You describe what the users need to do (how

they use the system)– Each of these major system “usages” is a use

case

Use Cases

“A sequence of interactions between a system and an external actor” – text, p.133

Accomplishes a “useful” goal; something “of value”

Use cases encompass all system functionality (sort of).

Actor

A person, software system, department, role, device…etc…. outside of the system that interacts with the system

ActorUse Case

Use Case Diagram

Register Customer

Rent Video

Bank

Clerk

Return Video

ActorAssociation System Boundary

Use Case