BTS330: Business Requirements Analysis using OO Lecture 7: Understanding User Requirements
Agenda Review Hearing Requirements Understanding Requirements
Requirements Development Cycle ElicitationAnalysisSpecificationValidation 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 Stakeholders focus 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 –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
Use Case Diagram Actor Association System Boundary Use Case