1. 1 BTS330 Requirements Gathering Review

2. What are requirements? It depends who you ask… Requirements try to describe the whole system you are creating. You need to decide on a definition with all project stakeholders…your requirements document will be based on that definition.

3. What are requirements? Intersection of interests of stakeholders: Customers (acquire the software) Users Analysts, developers, testers Legal staff And so on…

4. Why requirements? Foundation for the software system Define them well  terrific product, happy customers/stakeholders Define them poorly  disaster

5. Levels of Requirements Business Organization  vision/scope User  use cases Functional  software specs (not BTS330)

6. Levels of Requirements Nonfunctional Business rules Quality attributes External interfaces Constraints And so on…

7. Requirements Development Cycle ElicitationAnalysis SpecificationValidation Clarify Correct and close gaps Rewrite Re-evaluate Text, p. 59

8. Development and Management Manage Requirements Define baseline—SCOPE Manage changes (**NOT EASY) Manage project activity Manage project plan

9. Why are there problems? Detailed requirements are difficult!!! “…no other part of the work so cripples the resulting system if they’re wrong. No other part is more difficult to rectify later.” (text, p. 15)

10. Cost of Correcting Requirements RequirementsDesignCodeTestOperation 20 40 60 80 100 120 Relative Cost Source: Text, p. 17

11. Common Problems Insufficient user involvement Scope creep Ambiguous requirements “Paper Napkin” syndrome Overlooked users Inaccurate planning (bad promises)

12. The Pain Curve Pain Time Good Requirements Poor Requirements

13. Collaborating with Customers/Stakeholders Take responsibility for ensuring understanding Be respectful Give honest/correct information

14. The Sign-off Myth Signing off requirements is NOT a weapon but a milestone establishes a baseline provides the basis for change management

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

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

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

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

19. Categorizing What You Hear Software Specification Functional requirements Quality attributes External Interface Requirements Constraints

20. Getting It All Get enough detail to eliminate fuzziness All users? Full Coverage? E.g. “life of an order” Diagrams/Charts

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

22. 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 Help in understanding the requirements of the system

23. Use Cases “A sequence of interactions between a system and an external actor” Accomplishes a “useful” goal; something “of value” Use cases encompass all system functionality (sort of).

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

25. Use Case Diagram Actor Association System Boundary Use Case

26. Documenting Requirements in BTS330 Requirements Document as per a given template (posted to the bts330 site)