Object Oriented Analysis and Design — Part 2

OOA&D is all about writing great software 💻 , and you can’t do that without making sure your apps do exactly what customers want them to. Continuing on the OOA&D series, following are the things I learned from Head first’s Object Oriented Analysis and Design’s second chapter 📚 — Gathering Requirements

1. Sometimes even the customer doesn’t know what they really want 🤷‍♂️ — so you’ve got to ask the customer right questions to figure out what they want before you can determine exactly what the system should do and that’s where good requirements and good use-cases come in.

2. Requirements : Requirements are things your system must do to work correctly. Remember that the customer decides when a system is working correctly, so if you leave out a requirement or if they forget to mention something to you — then the system isn’t working correctly. Good requirements ensure your system works like your customers expect.

3. Use case: Use cases detail exactly what your system should do. Each use case provides a scenario that conveys how the system should interact with the end user or another system to achieve a specific goal. It should be very particular and should focus on a single goal. While writing a use-case, we don’t need to worry about the part on “how” we will achieve that but should focus on “what” we need to achieve.

4. There are 3 basic parts to a good use case -
4.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
4.2 Start and Stop — Every use case must have a definite starting and stopping point. Something must begin the process, and then there must be a condition that indicates that the process is complete.
4.3 External Initiator — Every use case is started off by an external initiator, outside of the system. Sometimes that initiator is a person, but it could be anything outside of the system

5. We should only start the implementation part once we are clear on the exact requirements and corresponding use-cases. In real life, it takes much less time to code than to exactly figure out the customer’s requirements.

6. Always remember to think holistically when writing use cases as the good use cases make for good requirements but an incomplete use case can result in bad requirements and a bad customer experience. Think about all the scenarios (happy path, alternate paths) which your customer might have forgotten to mention as your system needs to work in the real world and not just when everything goes as you expect it to.