Before we get into the topic of object-oriented analysis and design (which is when most of us get the most fun out of what we do aside from actually writing code), it’s important to follow-up a few more things regarding understanding customer requirements.
In the previous post, I mentioned:
If you take time to understand what they want from the beginning, then the requirements don’t have to be a 50-page document outlining how every single module has to work.
For example, whenever I put together requirements (or a Statement of Work) as I usually call them when I send them to clients, I rarely exceed ten pages, and it’s often less.
And though there are times when it’s longer, I think that part of the reason that developing a short set of requirements comes with the preliminary discussions to make sure you and the customer(s) have developed a common language with which you can work.
When you do that, the requirements and the statement of work – whatever you opt to call them – don’t have to be as long.
