BTS 330 Requirements Gathering Review 1 What are

BTS 330 Requirements Gathering Review 1

What are requirements? n n n 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.

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

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

Levels of Requirements n n n Business Organization vision/scope User use cases Functional software specs (not BTS 330)

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

Requirements Development Cycle Re-evaluate Elicitation Analysis Clarify Specification Validation Rewrite Correct and close gaps Text, p. 59

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

Why are there problems? n n 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. ” n (text, p. 15)

Cost of Correcting Requirements Relative Cost 120 100 80 60 40 20 Requirements Design Code Test Operation Source: Text, p. 17

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

The Pain Curve Pain Poor Requirements Good Requirements Time

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

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

Process (Iterative!) 1. 2. 3. 4. n Define Vision/Scope Identify users/stakeholders: classes, reps, decision makers Select elicitation techniques Identify, prioritize and develop use cases n Some modeling here (e. g. user interfaces) n Includes business rules …and so on

Hearing Requirements n n 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 n Ask the right questions n Open ended n n n Task/Job Descriptions n n “Describe…” “Explain… “What tasks…” Suggestions, Exceptions n n “What else could…” “What things annoy you…”

Categorizing What You Hear n Vision/Scope Document n n Business requirements Use Case Document n Use cases/scenarios n n User needs to <do something> Business rules n Must conform to/comply with some policy/formula

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

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

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

Use Cases n A very rough description: n n n 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

Use Cases n n n “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).

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

Use Case Diagram Actor System Boundary Association Use Case

Documenting Requirements in BTS 330 n Requirements Document as per a given template (posted to the bts 330 site)