Lecture 3-2

From Elicitation To Specification

CS 300 Lecture 3-2
Bart Massey

Difference between elicit and specify

  • Elicit: Get the requirements from the user

    • Usually fairly unorganized
    • Looking for a big picture
    • Looking for an agreement: Acceptance Tests
  • Specify: Organize the requirements for design

    • Check the requirements for soundness, completeness
    • Validate the requirements
    • Identify design constraints
    • Identify infeasible requirements; prepare for design
    • System Tests

Software Requirements vs System Requirements

  • SRS vs SRS: Obviously need both; similar on smaller projects

  • IEEE STD 29148:2011 (paywalled, thanks IEEE)

IEEE 29148: SRS Outline

  1. Introduction
    1.1 Purpose
    1.2 Scope
    1.3 Product overview
    1.3.1 Product perspective
    1.3.2 Product functions
    1.3.3 User characteristics
    1.3.4 Limitations
    1.4 Definitions
  2. References
  3. Specific requirements
    3.1 External interfaces
    3.2 Functions
    3.3 Usability Requirements
    3.4 Performance requirements
    3.5 Logical database requirements
    3.6 Design constraints
    3.7 Software system attributes
    3.8 Supporting information
  4. Verification
    4.1-4.8 see 3.1-3.8
  5. Appendices
    5.1 Assumptions and dependencies
    5.2 Acronyms and abbreviations

English vs Formal Specifications

  • English is messy

    • Ambiguous
    • Verbose
    • Hard to manage
  • Formal is hard

    • Requires training
    • Time consuming
    • Z, Alloy are good examples
  • Whole pile of semi-successful compromises, e.g. graphical

Use Cases and Scenarios

  • Use Case: How will the software / system be used?

    • ATM: Withdraw money, deposit money, empty machine
  • Scenario: Walk through an interaction in detail

    • ATM: Describe every button press and timing
  • Both are useful:

    • Use cases for every expected use
    • Scenarios to clarify use cases
    • Scenarios for corner cases

Example SRS

Last modified: Tuesday, 13 October 2015, 9:29 PM