Some proponents of Agile software development argue these days that Business Requirements documents are outdated and obsolete. This is not quite true. It is more a case of understanding what format, or process is most relevant for your project to document your requirements in, and then applying it accordingly. In most cases, especially where a business is relying on outside funding to be approved, there’s still a need to have a formal Business Requirements document which is well written and formally reviewed and signed-off. This doesn’t necessarily mean that those business requirements won’t change along the way, but rather it’s best to recognise the need to put a stake in the ground, do an estimate of what resources, effort, budget, and risks are involved, based on what is known and what the client wants implemented, today. Even non-waterfall based projects can benefit from having some initial baseline business requirements set down before they embark on an Agile-based delivery and implementation of those business requirements.
So let’s consider these common content sections and the importance and relevance of each. Here’s a quick, basic checklist of things to determine when gathering user requirements for any website or mobile app.
- First up… Why are you doing this? How does this fit into your overall vision of your product or company? Be short, and straight to the point in explaining what you are trying to achieve.
User Interaction and User Experience
- What should users be able to do? List all the activities users should be able to complete whilst visiting. These are called User Stories.
- How will we know when we’ve succeeded?
- What is the structure of the website? Create a Sitemap and Navigation. List the sections and content categories of the website?
- What is the look, feel and brand of the website? Identify the broad styling and design considerations?
- How will people with special needs use the website? List the accessibility requirements to allow access by screen-readers etc?
Content Management
- How will content be managed on a day-to-day basis? Is there a need for a Web Content Management System?
- How will editors update website content? Define the editor environment and everything required to allow editors to do their job?
- How will the website be updated? Define the process for adding new content and making editorial changes.
Website Management, maintenance and support
- What will be in place to make sure the website is secure and safe for visitors to use? List all security considerations.
- How will the website be hosted? Identify the type of hosting (cloud or physical servers) and the site (own hosting or third-party).
- What are the requirements for supporting the website? Define the time periods and level of support needed, including disaster recovery and service continuity.
Marketing
- How will the website be ‘promoted’ in organic search results? List the items and activities to enable this, such as, a unique title and description tags on every page.
- What are the reporting needs of the website? Define a list of KPI’s (Key Performance Indicators) that stakeholders and other interested people will need to know, and how often (number of visitors?, unique visitors? location of users?).
Other Requirements:
- List anything not covered in other sections of the document.
- List any assumptions made about the proposed website.
- List any Exclusions that will not be delivered as part of this project. These two lists include “In Scope” and “Out of Scope” scope items describing what is to be included, and what is to be excluded from the project. Write down a list of related things which may be out-of-scope or you might look at, at a later date. This list will often keep on growing as you explore the problems in depth.
- List any other considerations that need to be taken into account, and any constraints that may exist.