Please have a seat and bring something to drink, coffee or maybe tequila if you feel for that. Because here comes a summary of chapter 2, HFOOAD.
Requirements
There are situations when the system does actually what it is supposed to do but problems still occur. What I mean with this is something that HFOOAD bring up in the first chapter, step 1:
”Make Sure your software does what the customer wants it to do!”
When you as the developer wants to find out the client’s requirements it is often not as simple as just asking the client because most of the time the client himself doesn’t even know what he wants! As said the requirements are not always clear, and that is why it is very important to listen to what the client has to say and ask question back. So, you later can figure out how you ae going to solve the problem.
To help with finding out the right requirements use case is a great tool that becomes handy.
A use case is what people call the steps that a system takes to make something happen. In this chapter they use an example that a dog wants to go outside to do his business, and then back inside. There are three basic parts to a good use case, and you need all three if your use case is going to get the job done:
1. Clear Value
Every use case must have a Clear value to the system. If the use case doesn’t help the customer achieve their goal, then the use case isn’t of much use
2. Start and Stop
Every use case must have a definite starting and stopping point. Something must begin the process, andthen there must be a condition that indicates that the process is complete.
3. External Initiator
Every use case is started of and External initiator, outside of the system. Sometimes that initiator is a person, but it could be anything outside of the system.
REFERENCES
https://learning.oreilly.com/library/view/head-first-object-oriented/0596008678/ch02.html
Olles blog 
