CS 458 - Week 6 Lecture 1 - 2016-09-27

discussion of Jalote Ch. 3 --
    software requirements analysis and specification

*   requirement: IEEE definition:
    "(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"

    *   regardless of the software development process
        model or style of requirements specification,

	an important characteristic is:

	it "describes WHAT the proposed software should
	do without describing HOW the software will
	do it"

*   value a "good" SRS?
    SRS = Software Requirements Specification

    *   aids in COMMUNICATION!
        ...between clients and developers,
	...also between developers!

    *   a "good" SRS BRIDGES various potential
        communication GAPS; helps work toward
	a SHARED vision;

	...establishes a basis for AGREEMENT
	on what the software should do;

    *   we'll be talking about the difference
        between VERIFICATION and VALIDATION
        *   verification: does it do what it claims
	    to do "correctly"?
	*   validation: does it do the "correct" thing?

        *   ...a "good" SRS provide a REFERENCE for
	    VALIDATION of the final product or the
	    iterations along the way;

*   HOPEFULLY -- "high-quality" requirements REDUCE
    the development cost (since the cost of FIXING
    errors due the errors in the requirements can
    be high!)

*   requirements PROCESS -- how do you get these/state
    these?

    *   MORE than one way to approach --
        BUT Jalote mentions three TASKS that are
	often involved:
	*   problem or requirement analysis
        *   requirements specification
        *   requirements validation <- determining IF these ARE
	                               the "right" requirements

*   the understanding obtained by the
    problem or requirement analysis forms the
    basis of the requirements specification;

...and the SRS can be one way of expressing a requirements
specification;

*   from the SAME IEEE technical report that
    "requirement" was defined in:
    some desirable characteristics of an SRS are:
    *   correct
    *   complete
    *   unambiguous
    *   verifiable
    *   consistent
    *   ranked for importance and/or stability

    *   correct: an SRS is considered to be CORRECT if
        every requirement included in the SRS
	represents something required in the final
	system

    *   complete: an SRS is considered COMPLETE if everything (!)
        the software is SUPPOSED to do and the responses of the
	software to all classes of 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
        requirement is verifiable, if there exists some
	cost-effective process to check whether the final
	software (or an iteration) meets that requirement

    *   consistent: an SRS is consistent if no requirement
        CONFLICTS with another