In the previous post in this series, we talked about defining requirements (or a statement of work) and why it matters to have this.
Before we get into actually understanding – and writing – object-oriented code, there’s one more “business-related” topic to discuss: Terms and Conditions.
For many, it’s a bit of a dry topic, but if you’re looking to build solutions for someone else, do so from the ground-up, and do so properly, then it’s important to make sure you have all of the necessary pieces in place before doing so.
And once you’ve:
It’s time to make sure you have the terms under which you’re working.
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.