(textual) use cases - (NOT the same as UML use case diagrams...)
*   specifying functionality by specifying the BEHAVIOR of the system

    captured as INTERACTIONS of the users with the system

    *   actor - a person OR a system which uses the system
        being specified for achieving some goal

        ...really, represents a group of users/systems who behave
	in a similar manner, with similar goals

    *   primary actor - the actor that initiates a use case
        for achieving a goal; whose goal satisfaction is the
	main objective of the use case

    *   scenario - a set of actions performed to achieve a goal
        under some specified conditions

    *   main success scenario - a use case should always include;
        describes the interaction if nothing fails and all
	steps in the scenario succeed

	...but what if they don't?
	can have extension scenarios (exception scenarios)

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

*   developing use cases:
    *   natural levels of abstraction?
    *   actors and goals
    *   main success scenarios
    *   failure conditions
    *   failure handling

    step 1 - identify actors and their goals
             and get agreement with concerned stakeholders
	     as to the goals

    (each goal is considered/turned into a use case)

    step 2 - understand and specify the main success scenario
             for each use case

    step 3 - ...then add the failure conditions

    step 4 - ...and figure what should be done for the failure 
             conditions

*   VALIDATION of requirements is a good idea...!
    *   FOUR common categories of errors in an SRS:
        *   omission - some user requirement is simply not included
        *   inconsistency 
        *   incorrect fact
        *   ambiguity

    *   most common method of requirements validation
        is a Requirements Review
        *   a review by a group of people whose goal is to 
	    reveal any errors in the requirements;
	    NEEDS to include someone representing the
	    clients and/or users

	    can also consider factors affecting quality,
	    such as testability, readability