Presenter – Tim Peek (TenStep)

• Process is more important than tools (“Any fool with a tool is still a fool.”)
• Requirements fill in the detail of your scope statement
  • Once requirements are approved, they become part of the scope.
  • Fuzzy scope leads to inaccurate/fuzzy requirements
• Process/functional requirements
  • How it “functions” or works
  • How the deliverable interacts with the user
  • What happens first, second, third
  • How exceptions are handled
  • One subprocess’ output is another’s input
  • If condition A happens, then event B occurs
• Non-functional requirements (features)
  • How it looks
  • Description
  • Size, color, strength
  • look and feel
  • Performance (speed, capacity, reliability…)
• False requirements
  • Opinions (“I think we’re spending too much money on this”)
  • Projected-related statements (“We should prototype this first.”)
  • Assumptions (“The new release will solve this problem.”)
  • Out of scope (“While we are discussing reports, look at shiny objects.”)
  • Technology decisions
  • “Required” aspects, but not “requirements”
    • Policies and standards
    • Technical Architecture
    • Constraints
    • Deadlines
    • “We have to use XP, etc.”
• Technique – use cases
  • Define features and functions
  • Defined in terms of scenarios
  • “A user does an action and something happens”
  • Can use the use case to test for requirements
• Technique – prototyping
  • Create a model of defined requirements
  • Not fully functioning
    • Quick and Dirty
    • Hardcoded Components
    • Minimal functionality
  • Provide users with a visual representation of current state of requirements
  • Forum to more clearly define requirements
  • Uncover “hidden” requirements
• Requirements Development
  • Elicitation – I ask, you talk, I listen (write it down)
  • Validation – I analyze, I ask follow-up questions
  • Specification – I document, I ask follow-up questions
  • Verification  - We all agree
• Techniques for elicitation
  • 1x1 interviews
  • Group interviews
  • Facilitated sessions
  • Joint Application Design Sessions
  • Questionnaires
  • Prototypes
  • Follow people around (Walk-a-mile)
• Validation
  • Where the “analysis” starts
  • Make sure requirements gathered from Elicitation are accurate
    • Consolidate
      • Put requirements for similar processes and deliverables together
      • Please all the requirements at the same level
      • Determine if you have gaps
      • Eliminate requirements that are out of scope
      • Highlight areas of disagreement in the requirements
    • Rationalize
      • Fill in the gaps
      • Reconcile disagreements
        • Majority Wins
        • Escalate
        • Look at potential implications
      • Eliminate non-requirements
      • Put a full picture of all potential requirements
    • Model (Optional)
      • In addition to textual requirements
      • Adds precision to the requirements
      • Uses a precise modeling syntax
      • Usually requires training to create models
      • May require client training to interpret
• Specification
  • Prioritize
    • Determine the scale
      • H, M, L
      • Must, need, nice to have
      • Numeric Scale (1-3, 1-5)
    • Get consensus on the ratings
      • Majority wins
      • Escalate
      • Look at potential implications
  • Ensure traceability
    • Assign a tracking indicator to all requirements
      • Testing
    • Assign tracking indicators to all design, construct and test components
    • Create cross references to track requirements through the lifecycle (Traceability Matrix)
  • Ensure testability
    • Validate that they can be tested
    • Ensures precision
    • Helps catch any statements that are not requirements
    • If it can’t be tested, it’s not valid
    • In some methodologies, build the logical test case now
  • Create Business Requirements Report
    • Major Deliverable of the Analysis Phase
    • Draft up until now
    • Requirements finalized
    • Be as concise as possible
    • Eliminate potential misinterpretation
• Conduct requirements review
  • Formal meeting for final review
  • Does NOT include all stakeholders
  • All interested stakeholders have already seen
  • Review with decision makers and sponsor
  • Review is typically for QA, not accuracy (should already be accurate)
• Obtain sponsor signoff
  • Written signoff is best
  • Email is Ok
  • Verbal is NOT acceptable
  • Approval by default NOT acceptable
  • If sponsor will not approve, project STOPS