Chapter 2 : Gathering Requirements
In the previous chapter, the author insists winning the customer is the most important part of good software.
How do you figure out what the customer really wants? [or] how do we make sure even the customer knows what they want. That is where requirements come into picture.
Requirements - Singular need detailing what a particular product or service should be or do. It is most commonly used in a formal sense in systems / software engineering.
Summary / Takeaways
- Let the customer talk. First you need to know what the system needs to do. How the system should do will happen later.
- Convert whatever you have heard into a requirement.
- Consider alternate path
- alternate path : consider what might go wrong and update to handle that in the requirement list.
- Considering all the steps to complete this requirement, it becomes use case.
- use case : techniques for capturing the potential requirements of a new system or software change. Each use case provides one or more sceanrios that convey how the system would interact with the end user or another system to achieve a specific goal
- use case has three parts - clear value (should achieve customer goals), start and stop, external initiator.