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.

[restrict paid=”true”]

Writing a Statement of Work

First, I’d like to differentiate between a Statement of Work and Requirements in the context of this post.

  • Requirements are what the client wants to have built.
  • The Statement of Work details what you’re going to be doing, how you’ll be doing, and for how much.

I’ll cover the latter in more detail in this post. But suffice it to say that requirements can come in the form of discussions, documentation, or both as far as the customer is concerned.

Before jumping into the different parts of what I include in a statement of work, there are a few things that I think are worth mentioning:

  1. Don’t write a Statement of Work until you have all of the requirements from the client.
  2. Make sure the client knows what to expect from a Statement of Work.
  3. If you’re going to take the time to write a Statement of Work, decide if you’re going to charge for the time or not and make sure the customer is aware they will need to pay for it or not

This is one of those things that’s on a freelancer-by-freelancer or agency-by-agency basis. With that said, here are the parts of a Statement of Work that I usually include.

Preparing a Statement of Work

Whenever I prepare a statement of work, I have a template that I use. I’m going to provide a breakdown that covers much of it here.

Here’s how each section works:

1. Statement of Work

The purpose of this document is to [define a proposed solution for THE PROJECT].

The requirements of the project have been provided by [THE CUSTOMER’S NAME], [ROLE OF CUSTOMER NAME AT THEIR BUSINESS’ NAME]. The terms of the agreement are a combination of those agreed upon by [CUSTOMER NAME] and [YOUR NAME of AGENCY NAME].

2. Overview of Requirements

The purpose of this document is to [define a proposed solution for THE PROJECT].

The requirements of the project have been provided by [THE CUSTOMER’S NAME], [ROLE OF CUSTOMER NAME AT THEIR BUSINESS’ NAME]. The terms of the agreement are a combination of those agreed upon by [CUSTOMER NAME] and [YOUR NAME of AGENCY NAME].

3. Languages and Technology

The web server, software, tools, and approach that will be used to build the solution.

4. Supported Browsers

If this is a web-based project, then cover the supported browsers, whether or not there will be responsive functionality, and how the previous points will be tested.

5. Languages and Technology

The web server, software, tools, and approach that will be used to build the solution.

6. Project Requirements & Milestones

Typically the longest section of the document. It summarizes:

  • The requirements,
  • How each requirement will be built and delivered,
  • Any additional notes of which the customer should be aware.

7. Proposed Timeline

This is based on the milestones outlined in the previous section and the feedback from the customer.

8. Other Factors

Miscellaneous things that you opt to include such as what you or your agency opts to bring to the project, how delayed feedback can impact the project, and so on.

9. Estimated Cost

This includes the total cost of the project and an optional breakdown of the payment schedule.

It’s Necessary

I know: I’ve said this before in previous posts in this series. This is not the most glamorous part of what we do. Instead, we’d instead jump right into programming.

But how do you know what to build (and build it well) if we haven’t properly dealt with the problem we’re trying to solve?

And that’s what everything leading up to object-oriented analysis and design gives us.

Object-Oriented Analysis

Now that we’ve gotten the paperwork (or even the “business stuff” as some may refer to it) out of the way, it’s time to start working our way into programming.

Before doing that, though, it’s important to analyze the requirements and determine what parts of the project are going to serve what purpose. For example:

  • Do we need any pre-existing software?
  • Do we need to write any adapters or data layer code?
  • How will we build the application layer and the entities within it?
  • What about the front-end

And for many, this is where the fun begins. So I’m eager to begin talking through this, as well. We’ll be starting in the next post.

[/restrict]