{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.


That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.


Sorry about this, there is a problem with our search at the moment.
Please try again later.

This report is part of the Template Files for Web Projects bundle.



Web Project Template Files: Project Definition and Start Up
Authors: Sonia Kay, Econsultancy and other expert contributors
Title: Business Requirements Document

About this Guide

According to our research “Web Project Management: The practices behind successful web projects - May 2007” managing requirements is the number one challenge facing web project managers. Not least because (according to 88% of our respondents) requirements are often set knowing that they are likely to change during the course of the project. However, this does not mean that gathering requirements is a pointless exercise. Quite the opposite. Companies that deal with this issue with the most success ensure that they involve the right people up front in gathering requirements, and have an effective means of prioritising and managing their subsequent delivery. In Agile methods, this takes place via stories or features (templates for which are included in our Agile Toolkit) which are reprioritised at the end of each iteration. In more traditional projects, requirements are gathered using a Business Requirements Document, to which all relevant stakeholder parties contribute and sign up. One of the major contributory factors to poor requirements management is that the requirements themselves are sub-standard. Nine times out of ten this is because everyone is so excited about the prospect of a new web project that they want to include every pet feature or idea they’ve been storing up, causing your list of requirements to become bloated and unwieldy. Five top tips to avoid this: Prioritise ruthlessly - if a requirement comes near the bottom of the list is it really a requirement at all? Ask yourself, does each requirement contribute to a specific project objective? Are you articulating a requirement or have you started defining the solution -getting into solution definition at this stage can stifle thinking and cut off more efficient or imaginative ways to achieving your objectives Have you involved the people who really know what the system needs to deliver? Have you thought about asking the customer what they want? Don’t be ambiguous, like SMART objectives, each requirement should be expressed in language (or pictures) that can only have one meaning, and each requirement must be capable of being tested to see if it has been delivered successfully. Note: the BRD may also form a Schedule to the Contract (see Section 2.9.1)