Lecture Notes for Software Engineering Concepts

The Requirements Process, 24 January 2000


  1. srs uses

    1. a common document among differing views - customer, developer, user

    2. help the client clarify the problem

    3. a basis for the agreement among client and developer

    4. a reference for the produced system

    5. the first shot at error detection and correction

      1. srs errors do occur because the srs is difficult

      2. srs errors tend to be end-to-end

      3. the cost to fix errors increases with discovery time

      4. early investments in srs error detection and correction pay off

      5. late error detection induces change

      6. changes increase development time and cost

    6. comitting the resources to providing a requirements process

  2. requirements process

    1. context dependent, hardware and software

    2. software only

    3. three subphases: analysis, specification, validation

    4. overall process is iterative and overlapping

    5. much feedback passes among the sub-phases

    6. principle analysis tools: divide and conquer and abstraction

    7. principle specification tools: structural formalisms

    8. the relation between requirements analysis and system design: similar tools different objectives

    9. levels of abstraction - when too much what becomes how

    10. lower levels of abstraction tend toward the how

    11. customer's hows should come at the lower levels of the srs


This page last modified on 24 January 2001.