People are by nature visual, and creative comps are often used to get across an idea of a product or service. However, as the web becomes increasingly interactive, a static image is not enough to capture the overall experience and functionality. We cannot simply pass a static image to a developer and say “build this” and expect to receive precisely what we had in mind. A picture may be worth a thousand words, but that’s not always enough.
Some of the geeky aspects of product design and development are gaining mainstream popularity. Google’s Avinash Kaushik has made great strides in proving the sexiness of analytics (he compares it to Angelina Jolie). Business analysis is currently accepting applications for such a spokesperson.
No one really wants to write documentation, but it’s the safest way to ensure a project is on track and everyone is going to be satisfied with the outcome. Requirements call out specific tasks or features of a product. It’s basically a sanity check to ensure everyone is clear on the project deliverables. Before a product is released, it is checked against the requirements list. If anything is missing, it’s not ready to go out the door.
Imagine you’re at McDonald’s, and you order a Big Mac meal. The requirements for that order to be fulfilled are
- Big Mac
It’s only once those items have been included that your order – the project – has been completed.
Now, ordering at McDonald’s seems pretty basic to us. Let’s step it up a notch, and try Starbucks. This time you’re ordering for the office. You smile at the brand-new barista while you rattle off your co-workers’ favorites: a venti triple-shot non-fat no-whip caramel macchiato, upside-down, extra hot; a grande white chocolate mocha with soy and two pumps of hazelnut, and a tall decaf latte.
Start to see where requirements would be nice?
Who writes requirements?
This varies from situation to situation, but often this is the role of a Business Analyst. They will work to translate client needs into actionable, measurable items. Requirements should not include words like “some”, “a few” or “to be determined.”
Who uses requirements?
Developers, project managers, and testers. I currently work with numerous freelance development teams, and it’s incredibly difficult to get an accurate quote for “we need a website of between 10-15 pages, functionality TBD”. Requirements help developers scope their work. They help project managers manage project deliverables and ensure things are progressing as expected. And they help testers in writing test plans, by determining what is the appropriate behavior of the functionality.
Don’t requirements mean a lack of flexibility?
Well, yes… but ultimately requirements are beneficial to clients as well as implementation partners. They help to set expectations and ensure things stay on track. This is not to say things can’t change: in many cases there is the opportunity to introduce changes to requirements through what is known as a ‘change control’ process. This acknowledges that there has been deviation from what was initially agreed upon, and any possible changes to timeline or budget may be negotiated. Imagine if your cell phone provider gave you a heads’ up when you went over your plan, rather than just waiting and presenting you with a huge bill!
I’m sold! How do I get me some requirements?
As I mentioned, often requirements are written by a Business Analyst. I have found that the best Business Analysts come from a technical background, as they tend to have a keen sense of how to write verifiable statements. They may also be able to provide some insights into the sort of specific technical challenges that may arise, so that they may be accounted for early in the design process or modified altogether.
In this era of lean and mean budgets, it can seem difficult to justify the addition of a new resource and new deliverables. Yet the benefits of accountability and clarifying expectations can not be easily discounted.