CS 458 - Week 6 Lecture 1 - 2017-09-26

Jalote Chapter 3 - Software Requirements Analysis and Specification

*   SRS - Software Requirements Specification

*   requirement - IEEE defines as:
    (1) A condition or capability needed by a user to solve
        a problem or achieve an objective

    (2) A condition or a capability that must be met or possessed
        by a system ... to satisfy a contract, standard, specification,
        or other formally imposed document"

*   specifications of requirements do vary in their
    level or detail or when they are formalized --

    BUT one important characteristic across these is that 
    they describe WHAT the proposed software will do
    without describing HOW the software will do it --

    describes WHAT, not HOW

*   Value of a "good" SRS?
    *   helps to bridge the communication gap between client
        and team (and within the team) to help provide
	a shared vision of the software being built

ASIDE:
VERIFICATON
and VALIDATION
*   verification - did you build it right?
    validation - did you build the right thing?

    *   note that a "good" SRS can provide a reasonable
        reference for validation of the final product;

*   it is the case that many errors are made in
    the requirements phase of a project,

    and that an error in the requirements can manifest
    as an error in the final system...

*   Boehm - the cost of fixing an error increases almost
    exponentially as time progresses

*   Requirements Process -- coming up with your
    requirements and SRS (in whatever form it is taking)
    typically includes three basic tasks:
    *   problem or requirement analysis
    *   requirements specification
    *   requirements validation

*   Desirable Characteristics of an SRS
    [pie-in-the-sky, perfect-world version?]

    some desirable characteristics include (IEEE):
    *   Correct
    *   Complete
    *   Unambiguous
    *   Verifiable
    *   Consistent
    *   Ranked for importance and/or stability

*   poking at these terms a bit:
    *   correct - "An SRS is correct if every requirement included
        in the SRS represents something required in the final
	system"

    *   complete - "An SRS is complete if everything the software
        is supposed to do and the responses of the software
	to all classes input data are specified in the SRS."

    *    unambiguous - An SRS "...is unambiguous if and only if
         every requirement stated has one and only one
	 interpretation"

    *    verifiable - "An SRS is verifiable if and only if every stated
         requirement is verifiable."

	 And: "A requirement is verifiable if there exists some 
	 cost-effective process that can check whether the
	 final software meets that requirement"

    *   consistent - An SRS "...is consistent if there is no
        requirement that conflicts with another"

    *   ranked for importance and/or stability -
        "An SRS is ranked for importance and/or stability
        if for each requirement the importance and the
	stability of the requirement is indicated"

        *   stability: "reflects the chances of its changing
	    in the future"

*   SO - what are/can be some components of an SRS?
    *   functional requirements - specify the expected behavior
        of the system

    *   might include performance requirements
        *   might be STATIC or DYNAMIC

    *   might include design constraints

    *   might include external interface specifications