When devising a website brief there are many aspects to consider, which when done well can set the foundations for a great product. When done poorly, the product is likely to be the same result as any other run of the mill website.
The difference between High Level & Detailed Requirements
High level requirement - Less about detailed functionality, more about business needs, visual identity and abstract integrations.
“The website needs to interface with our CRM system to capture and track data throughout a customer journey”
Detailed requirements - Tend to be more specific to actual functionalities and refer to parts of the system closer to the development.
“As a user I need to have feedback if I enter my information incorrectly into a form, so that I can correct it and submit successfully.”
The high level requirement refers to many functionalities which underpin and contribute to the overall requirement. High level requirements are left open to interpretation (Discovery) to nail the actual inner workings later.
The detailed requirement is one of many which when combined complete a high level requirement.
Functional vs Non-functional Requirements
There are many definitions which aim to describe this, but simply put…
- WHAT the system should do
- HOW the system should do [something]
In a web build, a brief will usually contain some sensible non-functional requirements (as they are written by the business) perhaps something like:
“The website will strive to be the sector best-in-class, consolidating our brand into a single one-stop-shop consumer portal offering an unrivalled digital experience to customers.”
Along with strategic non-functional requirements come some mindless, generic, non-functional requirements:
- Modern/slick design
- Fast and performing
- Accessible (WCAG)
- SEO Friendly
- Mobile responsive
These requirements are very standard, but sometimes they contain some token clever ones like “HTML5 / Bootstrap / Retina Display” when someone involved in producing the brief has a limited understanding of how websites are made. For anyone that does actually know anything about solid web development, these non-functional “requirements” are actually just traits of a good build.
Some, like “mobile responsive” actually don’t mean anything… someone started using that term and now it appears everywhere! (See the difference between RWD and AWD article).
A functional requirement refers to specifically what should happen at a certain point in the system, for example “As a content editor I want to be able to set workflows for authors of different roles, so that content production can be approved before publish.”
Project Brief - the good, the bad and the unworkable…
With a good brief, individuals involved in assessing high level project requirements could likely provide a ballpark figure for completion (even for projects >500k) - this is often the sign of a well produced brief. Typical traits include high level requirements definition which explain why the requirement exists, with background, not just announcing a requirement. If there is evidence that thought has been put into the requirements, this indicates a strong business that knows what they need and how to get there, with professional help.
Briefs which have meaningless lists of non-functional requirements, or functional requirements which demonstrate no link to business goals, thus no added value, will stand out as poorly produced. This also encourages concern when sizing the project for a ballpark estimate, as lots of time might need to be factored in for “educating” the business as to the optimal route for delivery.
Some people you just can’t work with - usually the brief is a strong indicator. If someone has a thin brief and just wants to “get going,” the ultimate pragmatist, then the chances are they are trouble further down the line. I wish more often, at the project brief stage, these types were eradicated before agreeing to an engagement.
Fortunately, these are few and far between!
Requirements in a Project Brief are a starting point, any web development partner will embark upon an Inception or Discovery piece in order to assist with completion of requirements definition. Regardless, requirements evolve over time also.
It’s important to remember that there are many stakeholders in a large project, each of which have different ways of conveying their requirements, due to the nature of their piece of the pie. For example, someone from the IT department will be more concerned about the due diligence as part of a build (code quality, compliance, regulatory) whereas the marketing team will likely have non-functional requirements about ease of content entry and workflows. The business will almost always be looking at lead generation, lead capture and of course, revenue increase.
Whoever is the project lead responsible for delivering the brief should be able to summarise requirements with a ubiquitous language and from a non-biased perspective, ready for web delivery partners to consumer, criticise and evolve, collaboratively.