Website Functional Requirements
Document Requirements Using Interviews, Groups, Surveys, Maps & More
Documenting requirements for a website or application can be challenging but some good methods include using workgroups, interviews, surveys, and scenario maps.
First you start by understanding and documenting the business requirements for a website or an application. Once you have these well understood, the next step is to define the functional requirements. Functional requirements outline what a website or an application needs to do. It is the detailed content or functionality that must occur on the site (or in the application). There are many different approaches to getting functional requirements. There are also some very clear guidelines on what you should and should not do as you gather them.
One of the most important things to remember is that you are documenting what a system needs to do and not how it does it. For example, a functional requirement is that an author needs to create a content article easily. It is not that a content management system needs to be purchased. So you don’t say what needs to be done, you say what “functionality” needs to exist in the new application or site. Other examples of functional requirements:
- An article cannot be published until it is reviewed and approved by an editor
- A product cannot be purchased until an email address is given
Functional requirements must always map back to business requirements. There can be more than one functional requirement mapped to a business requirement. A requirements traceability matrix is a form that lists all the business requirements, and their associated functional requirements. Make use of this form. It’s also used to ensure that an application actually implements all the functionality necessary by serving as a checklist for testers.
There are many different ways to gather requirements, including:
- Interviews
- Shadowing
- Focus groups
- Workshops
- Surveys
- Scenario maps
- Use cases.
All of these approaches involve talking to one or more people who use the application or who own the website. One on one interviews and shadowing are great tools to track how a person works and what activities take the most time. You can also document how important an activity is so that you can later focus on making the more important activities work better. Working with groups promotes creative thinking about problems and how they could be resolved (via improved functionality).
It’s important to look for what works well and what doesn’t work well. Your job as documenter of functionality is to ask a lot of questions, be sure you understand the business processes that are performed and what the user sees as their issues or needs. Your job is not to suggest improvements – not during the gathering process. You listen, you learn, you document. Later you work on solutions and suggestions for improved processes and functionality.
