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

2. Agenda  Review  Hearing Requirements  Understanding Requirements

3. Requirements Development Cycle ElicitationAnalysisSpecificationValidation Clarify Correct and close gaps Rewrite Re-evaluate Text, p. 59

4. 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

5. Agenda  Review  Hearing Requirements  Understanding Requirements

6. 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

7. Hearing Requirements  Ask the right questions –Open ended “Describe…” “Explain… –Task/Job Descriptions “What tasks…” –Suggestions, Exceptions “What else could…” “What things annoy you…”

8. 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

9. Categorizing What You Hear  Software Specification –Functional requirements –Quality attributes –External Interface Requirements –Constraints

10. 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

11. When are you done?  Hearing “nothing new”  Hearing only things outside of scope or release  Hearing low priority

12. Agenda  Review  Hearing Requirements  Understanding Requirements

13. 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

14. 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).

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

16. Use Case Diagram Actor Association System Boundary Use Case