Lecture 2-2

On User Requirements

CS 300 Lecture 2-2
Bart Massey

Requirements Elicitation

  • 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

  • Willing customer(s)!

  • Reasonable level of domain knowledge

  • Time

  • Channel

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

    • Top-down
    • 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

  • Check for

    • 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

  • Ambiguity
  • 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

Acceptance Testing

  • 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

Prototyping

  • 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

  • UI Prototyping

  • Black-boxing

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
Last modified: Tuesday, 6 October 2015, 10:25 PM