DigiDigest

Gather the right requirements for your website

So you have decided you want a new website, or that current tired looking website really needs a fresh look to bring it out of the 1990’s.  Where and how do you start? Here are a few important points to help you through this important phase of your project.

Start with the end in mind

In many projects, especially for large organisations, most ideas and requirements are driven internally within your organisation.  In many cases, the project sponsors (the people paying the bill) will have an agenda the project team will endeavour to satisfy.   While it is obviously important that internal requirements are met, this common practice has often left one important group of people out in the cold - your end users. 
Whether the website is intended for use internally or by the general public, it is a good idea to engage your end users.  This can be done via surveys, reviewing the site with them or even as simple as asking your existing customer for ideas and feedback. Engaging end users early in the project will save you time and effort in the long term and ensure a better end product.

Get on the same page

When defining requirements for your website, there will be many meetings, brain storming sessions, emails and phone calls with your web team.  While today’s technology provides so many ways to communicate, there is nothing better than face-to-face meetings. Not even webcam or videophone will be as effective as being in the same room with other stakeholders.  These meetings should be no longer than 1.5-2 hours as concentration levels and productivity will decline as the meeting drags on.  Have a clear agenda that outlined the objectives and goals of the meeting. Finally, have short coffee breaks if long meetings are unavoidable.

The end result of the requirements gathering phase is a Functional Requirements Document.  This document should contain detailed description of what the web site will do and how it will interact with the end user, broken down into the functionality of each module of the website.   Always avoid including specific implementation methods.  For example, while screen mock ups are useful as visual clues to how the site may operate, they should not be used as a commitment to the design of the website.  Similarly, there should not be any source code or data tables in the requirements document.  These can go in the technical design document if required.

What is the time?

Web projects are constantly under pressure with time and budget constraints.  Just like any other forms of construction, a website that is delivered on time and on budget starts with an effective requirements gathering phase.  As part of gathering requirements, you and your web team should have an idea of budget and timeframe for the project.  This forms a boundary as to how much functionality and features you can include in your website.  Obviously, certain requirements are mandatory and must be included.   However, when time and budget are pressing and you need to get a website out in the marketplace, it pays to think carefully and prioritise your requirements.  Split your requirements into phases and go live with the features you must have first, and then implement the rest in a future phase.

When a requirement specification is agreed by all party involves and signed off, it is important that the scope of the requirements is maintained.  That is not to say that it cannot be changed.  Often, extra requirements are discovered after the requirement document is signed off and work has commenced in the project.  Or half way through implementation, a major issue has been discovered that require changes to the requirements.  Communication is key here and the sooner you and your web team are aware of the potential issues, the sooner a solution can be decided on to minimise project time and budge blow out.

Obviously, this is only the first stage in the development process but its the key one. Projects are not seen to go wrong at the start or in the middle, it is at the end when schedules slip and budgets are affected. By approaching the start of the project effectively you avoid this issue arising and ensure a better result.

Tweet Post