CS 458 - Week 6 Lecture 2 - 2016-09-29

*   conceptual integrity, in Brooks' view, is THE most important
    consideration in system design

*   Brooks thinks that a large system's conceptual integrity
    can be adversely affected when design is SEPARATED
    into many tasks done by many people;

*   "architecture" in MMM: "the complete and detailed specification
    of the user interface"
    *   not quite the same as Jalote's SRS! BUT,
    *   it DOES have a similar emphasis on the WHAT rather than the
        HOW -- WHAT the software is to do,
	       rather than HOW it is to do it
  
    * SO, Brooks is arguing for one or a small group of architects --
        coming up with the complete and detailed specification of the
        user interface -- and then many implementers (organized
	into teams) implementing that specification;

*   ultimate test of system complexity?
    RATIO of function to conceptual complexity

*   back to Jalote...

*   Use Cases
    *   specifies functionality of a system by specifying the
        BEHAVIOR of the system,
	captured as INTERACTIONS of the users with the system

    *   DO NOTE: so-called "textual" use cases,    
        the style described here,
	are NOT the same as UML use case DIAGRAMS;

	UML use case diagrams are less detailed,
	Jalote sees them as a nice ADDITION to
	textual use cases, but NOT a substitute;

    *   in this course, "use case" means the textual version,
        and we'll sat "UML use case" for the UML diagram;

*   common "pieces" in use cases:
    *   actor - a person or system that USES the system
        being specified for achieving some goal
        *   primary actor - the MAIN actor that initiates
	    a use case for achieving a goal,
	    whose goal satisfaction is the main objective
	    of THAT use case;

            ... the person/system that actually uses the
	    outcome of the use case,
	    and who is the main consumer of the goal

    *   scenario - for describing interactions, use cases use
        scenarios
        ...a set of actions the *primary actor* wants to
	   do to achieve some goal;

        *   main success scenario - a use case always has!
	    ...the steps (actions/logical/state changes)
	    if nothing fails and all steps succeed

	    MAY also have extension scenarios (also called
	    exception scenarios)

    *   a use case is a COLLECTION of all the success and extension
        /exception
        scenarios related to the goal;

*   note that data flow diagrams and E-R diagrams
    can be useful approaches in the problem analysis stage;

*   note that the requirements, however they are expressed,
    NEED to be VALIDATED;
    DO they meet the user's/client's needs?
    DO these do what the user wants?

    *   Jalote mentions 4 common categories of errors in an SRS:
        *   omission
        *   inconsistency
        *   incorrect fact
        *   ambiguity

    *   the MOST common method of requirements validation
        is a Requirements Review;
        *   a review by a group of people to find errors,
	    point out matters of concern, etc.,
	*   BETTER include clients or representatives of the
	    clients!
        *   may also consider factors affecting quality,
	    such as testability and readability