CSC323 2010S, Class 06: Gathering Requirements

Overview:
* About requirements.
* About use cases.
* The dog door example.
* Activity: Use cases for grinnell.edu.

Admin:
* Readings for Tuesday: HFOOAD Chapter 4, Beautiful Code Chapter 30.
* Due time for readings: 9 a.m.
* Next small assignment: Use Cases.
* Class will end at 2:45 today.
* Many of you missed a good convo today.
* EC for Today's CS Extra.
* EC for Tomorrow's CS Table.
* EC for next week's Media Symposium.

A use case gives the steps the user/program/other agent goes through
in accomplishing one of the client's goals.

* How do use cases help in building our agreed upon list of requirements?
  * Both talk about what we want the system to do.
  * A way to think about the meanings of different requirements
  * Necessary: Each requirement is involved in at least one step of
    at least one use case
  * Sufficient: Each step can be solved by one of the required components

* Use cases serve many other purposes
  * A use case is a test
  * The particular parts of a use case often suggest methods or objects
    in the system
    * Remember: Nouns are often objects, verbs are often methods
  * ...

* Use cases focus on the "what" not the "how" of a system

* The use cases can be used in software estimation.  (I don't know how
  well this works.)

---

Our book's primary domain: Doggie Doors
* Client set one: Rich lazy dog owners
* Code positives
  * Simple, clear, understandable
* Code negatives
  * The remote queries the door for its state and then changes it, when 
    in most real systems, the door knows its own state and is responsible
    for changing it.
    * Book requires two way communication between door and remote
    * But it follows the "each object does one key thing" model.
    * May follow the rules of the underlying physical device
  * In the final implementation, the open method also makes the door close
    (should perhaps have a different name, such as "open_for_a_few_seconds_and_then_close")
  * Rhetorical issue: The code's not all in one place, which makes it
    hard to discuss.  (It appears no one bothered to download it.)
  * The door could close on the dog.

Do we have an ethical obligation to teach our clients about better solutions?
* It depends on what Doug the Dog Door Dude tells us about his operation.
* We may not know the better solution.
* But yes, if you know of a better solution or a problem, you should tell
  the client.

Design Principles from p. 141
* Much like methods, requirements should do exactly one thing
* Encapsulation is your friend.
* In the end, we're going to move all the code from the remote to the
  dog door.
  * Choose the place to put methods carefully, or you'll end up moving
    a lot of code.
* Think about requirements beyond the basic functionality. 
* Anticipate what future changes will be.
* Be prepared to refactor: If you're duplicating code, you should 
  quickly write a common version and use that.

Name Search, v1
* Initiator: User
1. User goes to Grinnell home page [Requirement: Grinnell has an obvious home page.]
2. User clicks on "Directory" [Requirement: The home page has a prominantly displayed directory link.]
3. System displays a directory search page [Requirement: There is a directory search page with a field.]
4. User enters last name (e.g., "Rebelsky") [Requirement: The search page provides a last name field.]
5. System displays a list of all close matches [Requirement: The directory system has an approximate matching algorithm; Requirement: The directory system can display multiple entries]
   5.1. If there are no close matches, System displays error
        message

Name Search, v2
* Initiator: User
1. User goes to Grinnell home page
2. Home page displays "Search Directory" field
3. User types in the name in the Directory Search field
4. System displays a list of all close matches
   4.1. If there are no close matches, System displays error message

Name Search, v3
* Initiator: User
1. User goes to Grinnell home page
2. User clicks on "Directory"
3. System displays 
   Browse by last name (alphabetical): A B C D ...
   Browse by department: Computer Engineering, Computer Science, Informatics,
     Software Engineering
4. User clicks on first letter of last name
5. System displays all names that start with that letter
6. User scrolls to desired name
7. User clicks on that name
8. System displays contact info

Additional steps:
* Need login/validation
* Provide additional information (here are all the links to this
  person I've found; here's some blackmail data; ...)

Email responses
* Initiator: User on a page for which she wants followup
* 1. User clicks on the "Ask for more info" link [Must have such a link; Link must provide appropriate contact info for this page]
* 2. User fills in question and email address [Must have space for stuff]
* 3. User clicks send.
* 4. System sends email to designated contact person for the page. [Requirement: Each page must have a designated contact person.  Requirement for client: Someone has to keep this info up to date.  Requirement: System must be able to send email.]