CSC323 2010S Software Design

Head First OOA&D 2&3: Requirements

McLaughlin, Brett D., Pollice, Gary, & West, David (2007). Give Them What They Want. Chapter 2 of Head First Object-Oriented Analysis & Design. Sebastapol, CA: O'Reilly.

McLaughlin, Brett D., Pollice, Gary, & West, David (2007). I Love You, You're Perfect, Now Change. Chapter 3 of Head First Object-Oriented Analysis & Design. Sebastapol, CA: O'Reilly.

Are requirements written primarily as an aid to programming or for an inexperienced audience such as a user of the software?

Requirements are written to ensure that the customer and the programmers agree on the main goals of the software.

Should the development of use cases and requirements both be done with the customer? It eems that everything would be more accurate if both the programmer and the customer were present.

You don't need the customer there all the time, but you should certainly review use cases and requirements carefully with the customer.

The concept of a main (or "happy") path and alternate path makes sense in a use case. Do programmers traditionally write out use cases and scenarios for their programs, or is this an example designed to make us think about how to apply requirements we're given to the programs we write?

Authors of reasonable-sized programs regularly write out use cases. Use cases (or something similar) are an important part of most OO methodologies.

Is there a standard system for modeling use cases that is similar to UML? If there is, why didn't this book describe it, and if there isn't, why isn't there one?

In fact, the UML has a notation for use cases. However, there seems to be less consistency in the OO design community about the detail necessary for use cases. UML use case diagrams seem to have a bit less detail than do the narratives in the book.

Code Details

On page 139, the code for timer is moved from the Remote to the DogDoor but the code for the test: if (door.isOpen()) {...} is left in the remote. Shouldn't this test also be moved to DogDoor so that the Remote only sends a message to DogDoor and then lets the door decide if it's already open or not? Also, should timer.cancel() also be called in close()? Will close() be called twice if the door is already open when close is called the first time? [+]

Good criticisms. Their forucs seems to be more on the overall idea of the project than on all of the details

DogDoor's open() method seems poorly named, given that by the end of Chapter 4, it both opens and closes the door. Is there a better way to design this?

The primary purpose is still opening the door, so I think the name is reasonable. It is worth discussing, though.

How does the actual code interface with the hardware regarding the bark receiver? The text explains that the system acknowledges when it receives a bark, but I'm confused with how it actually knows that a bark has been received.

There's some hidden code that calls the appropriate method. You're not supposed to worry about it.

In chapter 2, why does the remote query the door for its open status? Shouldn't the door be able to take care of that logic for itself? That's how things with remotes work in real life.

Pedagogical reasons, I think.

It seems like a poor design decision to have the door open on every bark by any dog. When you see an obviously bad design like this from a client, should you try to change their minds before implementing it or just do it (and get more money from them when they want it changed)?

I would discuss the design with them. I would also expect a variety of use cases to reveal the problems. Hey, maybe the bark recognizer can distinguish different dogs. But you'll see further analysis of this issue in Chapter 4.

On page 82, it seems like the code is set up to automatically close 5 seconds after it is opened. Isn't this poorly designed? It would be very inconvenient: this means that every time that Fido goes outside, the owners would have to listen for him to bark and let him back in, therefore having to stay awake longer and press the remote twice. The book suggests that this would only happen occasionally - but with the 5 second time limit, this would happen every time the dog went out. Is this the desired operation? Wouldn't some system involving a sensor be better?

I think this is an attribute of the system that would be field tuned.


At what point does a customer requirement reach the point where it makes sense for a software designer to flat out say no rather than telling the customer what the costs of implementing that requirement would be and having them make a decision based on that?

I'd make the cutoff at the point that it wasn't worth my time or energy. More generally, I expect it depends on resources. For example, if you expect that a project will require more resources than you can provide (e.g., because your resources need to be devoted to more than one project), even if the client is willing to pay for them, then I think you have to say no.

How should we document use cases and requirements when designing our own software? Are there tools available to aid this process when designing complex real-world applications?

For now, include the details you consider appropriate. In the end, what format you use will depend on your company's standards.

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Thu Feb 11 10:22:30 2010.
The source to the document was last modified on Thu Feb 11 10:22:25 2010.
This document may be found at

You may wish to validate this document's HTML ; Valid CSS! ; Creative Commons License

Samuel A. Rebelsky,

Copyright © 2010 Samuel A. Rebelsky. This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.