On User Requirements
CS 300 Lecture 2-2
Premise: Your customer doesn't know what they want
- This is true even you are the customer
Consequence: You and your customer will figure it out together
This process is known as requirements gathering ("elicitation")
Subtle, can be painful, hard to V&V
Absolutely crucial to project success
- Especially avoiding requirements rework
Prerequisites For Elicitation
Reasonable level of domain knowledge
Requirements Before Design
Very common mistake: capturing what the customers want you to do, rather than the result they want
You will not know how to design the system well until you know almost everything about what it is supposed to be
The customers will not know how to design the system at all
- If they did, they wouldn't be asking you
Some Obvious Elicitation Tactics
Ask for a description
- Try to gather system requirements, not just SW requirements
Propose requirements and gather feedback
Ask open-ended questions
- Leading questions are terrible
Ask specification-driven questions: soundness, completeness, sanity checks
Validating User Requirements
Usually has to wait until a specification
- Clarity: You and the user have a common vocabulary and understanding
- Soundness: The user requirements are not inconsistent
- Completeness: the user requirements have no "holes"
- Sanity: The requirements pass the "smell test"
This phase always looks easy to you and to the customer, but it's not
Functional and Extra-Functional Requirements
Many requirements are functional: what will the software/system do?
Many are extra-functional "-ilities"
- Quality: How good does the system have to be?
- Affordability: Is the system cheap enough?
- Security: Does the system have to withstand human attack?
- Timeliness: What are the deadlines on the system?
- Intangibles: Style, comfort, etc
Common Elicitation Problems
- Hidden assumptions
- The “Railroad Paradox”
- Asking the wrong questions
- “How,” not “what”
Requirements Work Products
- User Requirements Definition
- Concept of Operations
- Acceptance Test Plan
- System Requirements Specification
- Interface Requirements Specification
- System Validation Plan
Establish up front what the customer will call sufficient
- Even if you are the customer
- "The best is the enemy of the good." --Voltaire
- See the C2 Wiki for more
Establish how you can measure success
- Unmeasurable criteria are worse than useless
Turn this into a formal Acceptance Test Plan
- A test is an input-output pair
Prototype to investigate
Prototyping is a useful technique, but not a process model
Three types of prototyping
- Discardable: keep knowledge, discard code
- Evolutionary: keep knowledge, keep some code
- Incremental: keep knowledge, keep code
Prototyping User Requirements
- Paper-and-pencil prototypes
- Stranger Things
Users Don't Want Software
Users want a solution to their problem
Getting stuck on software-mostly solutions is terrible
- "Let's build a recipe file"
Less software is better
- This is part of why you need to be a domain expert