Web site requirements template

Ideally this document would form a part of the Request for Proposal, helping the vendor to make an accurate quotation. It contains a lot of measurable benchmarks or deliverables concerning all aspects of the site. By the time you sign a contract, you need quite a detailed account of what will be done. This document can take you most of the way there, though the vendor will likely have some queries and compromises. Note that these requirements will have a minimal effect on the final choice of content management system, but affect much more how much attention to detail is paid by the developer. A requirement should be an unambiguous want which is either met or not met when the system is delivered. As you compose your requirements, think about how you would test the system to see if it has been implemented. The first section is called 'specific requirements', by which I mean whole areas of functionality which you may or may not require, shown here as examples from which you can borrow. The second section is 'general requirements', which cover all aspects of a web site, and which you will want to borrw from heavily. All requirements fall within one numbering system, for ease of reference. Note how each requirement contains the word 'should'.

Prioritising your requirements

If you don't actually need something, you should be sure somehow to mark it as 'desired' instead of 'required'. You can ask for these to be priced separately but you should be economical and don't forget to include it in the response template. Some responses 'desired' requirements will likely be included automatically, or very easily.

When thinking through your requirements you are bound to reach the limits of your knowledge. It is permissable to ask questions in the text (be sure to repeat them in the response template).

Contents

Example special requirements
Library
Collaborative document authoring
RSS aggregation
Rosta of experts
Contact database / mail handler
Social network
General Requirements
Graphic Design
Editing
Administration
Search
Internationalisation & Localisation
User Involvement & Accounts
Accessibility, Standards & Compatibility
Versioning & Workflow
Publishing & Delivery
Scalability
Security
Reporting
Hosting & Maintenance
Documentation & Training

    Specific Requirements

    The examples given in this section are common amongst NGOs. Feel free to adapt them to your needs.

    Library

    It seems that every NGO wants an online library. Talk a little about the range of publications, the types and how they will be navigated. Hopefully these examples will cover most of what you need. Search is a very important part of library, but that is dealt with later in the document.

  1. There should be a library section of the site, with search tools, pages explaining how to use it etc, and the possibility to list most downloaded, or most rated, or most recent publications.
  2. The library should support OpenSearch. This ensures the content is easy to access and index even from outside of the site.
  3. Search results should be available as RSS feeds. This is not a common need, but supports some people's ways of working, and shouldn't be difficult.
  4. The metadata should conform to the Dublin Core standard. This is just a way of arranging the metadata which will help to make your data more portable and useful.
  5. The full text of each document should indexed. This needs to be stated, as it usually requires some complexity and is unlikely to be provided for free. Also the file-types you need indexing should be stated. Is it all PDFs? Or do you also have PowerPoint, web pages, MS Word files?
  6. The library should use COinS. This is an easy requirement which allows the web site to interact with bibliography software.
  7. The library should be categorised according to a hierarchical vocabulary of keywords, such that selecting 'disease' will bring up all publications tagged with 'polio'. Note that this kind of usefulness requires that the NGO provide detailed meta-information. See the section on preparing content for more
  8. Staff putting new publications in the library should have a widget from which to browse and select existing authors, publishers, before creating a new one. This is to prevent prevent one entity being represented in the library under two names, and to encourage consistency in naming.
  9. Some documents in the library are more important than others. There should be a field denoting the prominence of the document, on a scale of 1-5.
  10. It should be possible to drill down through search results. You might specify a faceted search.
  11. keyword searches should return results showing examples of the word in context in the publication, as google does.
  12. Members should be able to comment on documents, subject to moderation by staff

    13. Collaborative document authoring

    The web site might not be the best place for this to happen, especially with the strength of Google docs, with which you can work offline or simultaneously with other editors. Nonetheless, if you want to host these kinds of activities, these are the things you might require. Don't ask for anything you don't specifically need, as some of these things are tricky.

  13. Some documents will be editable by more users than the rest of the site. Each of these documents will need it's own set of permissions.
  14. The site should prevent one user saving over the work of another.
  15. It should be possible to browse the documents' histories, compare versions, and revert.
  16. There should be a space close to the document to discuss the editing process.
  17. There should be a way for users to be notified when a document is edited.

    18. RSS aggregation

    Your organisation is probably not the only one working in your field. You can make your site more useful by providing a news feed or feeds from related sources of information. You may want to take many feeds and offer an aggregate filtered by key words. You may also want to publish news via a feed or blog.
  18. Each section of the site should show a different filter of news aggregated from many sources.
  19. News items should be shown on a map, positioned automatically.
  20. Contents of external RSS feeds should be imported automatically into the site and be visible in search results.
  21. Users should be able to subscribe to each of the aggregated feeds.

    22. Rosta of experts

    The need for a list of experts, along with their CVs and availability recurs throughout the world of work. You might ask for the following features

  22. All users will be eligible to apply to join the rosta, those who fill in the form will automatically become members of the site.
  23. Members with fuller CVs and more will be prioritised in listings.
  24. There will be a widget for members to enter periods of availability up to a year in advance. The default will be unavailable. Members should be reminded to update their availability every time they log on.
  25. The right to use the rosta as an employer, and to see CVs will be granted to a few, named individuals
  26. The rosta will be invisible to non-members
  27. There will be a set of keywords just for tagging and finding rosta people.

    28. contact database / mail handler

    Contact management is often poorly implemented in non-profits. If your web site members overlap significantly with your contacts database, you should consider integrating them and managing your contacts through the web site.

  28. It should be possible to put contacts into multiple groups, and to send mail to those groups.
  29. The system should integrate with a third party bulk email server.
  30. It should be possible to compose rich text emails, with embedded pictures.
  31. Contact details will be available only to office staff and the contacts themselves
  32. It should be possible to import and export the contacts to Outlook Express, including the group information.

    33. Social Network

    You can create a free social network with some nice features at ning.com. However if you need a social network integrated with your own site, here are some of the features you might require.
  33. The space should consist of lots of pictures of people.
  34. Members should be able to invite others to be friends and to be able to choose which elements of their profiles to reveal to friends
  35. Members should be kept up-to-date with their friends activities, like on facebook.
  36. Members should be able to share attached documents and receive comments on them
  37. members should be able to upload videos for everyone to see
  38. members should be able to rate each other's content

    39. General Web Site Requirements

    Graphic Design

    Your new web site is likely to contain elements of new graphic design work, as well as a lot of work on things like layout, menus, pagination the footer. In this section, you should say what new things will be required. Examples:

  39. The new site should retain the basic design and layout of the old site, but appear fresher and more modern.
  40. To suit our aging users, the default font size should be larger than usual
  41. The User interface should be consistent with the graphic provided in Appendix X.
  42. The new graphic design should inspire trust, competence and functionality. It should have no frills
  43. The new graphic design should use the metaphor of driving

    44. Editing

    There are many levels of sophistication for editing web pages, requiring more or less training. Editing text like in MS Word, is almost standard, but modifying layout, inserting pictures, and inputting metadata usually requires that the editor be more familiar with the system. More sophisticated editors involve different crops of pictures, ways to place pictures, working with different templates for different kinds of pages which enforce certain layouts, restricting or automating the text style, captions and multiple captions for pictures. The ability for editors to add keywords and classify their pages to make them easier to find. Autosave, spell check, custom dictionary may be required or may be standard. Example requirements:

  44. It shall be possible in-house to create new page templates.
  45. The editing interface for our partner editors should be simple enough for them not to need training.
  46. There should be a limited range of styles available to editors.
  47. Only in-house moderators should be able to locate new pages in the navigation tree.

    48. Administration

    There are some occasional tasks which you will want to do in-house and which shouldn't be too difficult. Hopefully you have a member of staff, who, with a little training can do these kinds of operations. You may have mentioned that person already. This section is to say which low-level configuration tasks would you like done in-house. For example:

  48. The administrator should be able to set up a new discussion board.
  49. The administrator should be able to change a user's permissions.
  50. The administrator should be able to adjust the search weighting.

    51. Search

    There are very many different possible mechanisms for search, and the exact options available may depend upon the platform chosen. Here is a list of possible search mechanisms; if you had them all, your search would be too complex. Many web sites settle for a quick search and a detailed search.

  51. word search looks in the html and metadata.
  52. full text search looks inside all the available documents.
  53. Boolean search understands AND, OR and NOT
  54. Google search, covers all the text on your site and gives google results.
  55. Partner site search uses Google to search only sites nominated by you.
  56. Advanced search allows the user to search according to document metadata.
  57. Faceted search or 'flamenco' is becoming very popular because it is very usable for repositories with lots of metadata.

    58. Some search tools will detect the stem of the search term and give a slightly more fuzzy match. Should your search results be ordered by relevance? Should they include a snippet of the search term in the context of the document? These things are harder for some search tools than others, so only require them if they are important. If it isn't important, omit this section.

    Internationalisation and Localisation

    PROVIDE DEFINITIONS OF THESE

    You should indicate how many languages you would like to offer, whether you want the content and the interface translated, and the editing and administration tools translated. Many NGOs operate across borders and have stakeholders across numerous languages. Without support from the CMS, it can be extremely tedious keeping several translations of a web site up to date. Only a few systems available are really good at multiple languages, so you need to be clear just how much language support you need. Some systems through support the translation workflow, and offer the web site interface and menus in a given language as well as the content.

    User Involvement and Accounts

    What can the user do without logging in, what information do you need to collect on your users, and what can they after logging in? Try to connect your answers to the project goals. The following activities may require your users to log in.

    • contribution of content
    • discussion
    • rating / voting
    • collaboration on a document
    • collaboration on a project (this starts to get complex)

    In this section you should give some indication of how much and what kind of information you intend to gather in the user accounts, and what you intend to do with it. If you require users to create an account and log in, this is an opportunity to learn a little more about them, either for your records, or to provide them with a better service (ideally, both). As a guide though, don't be greedy for user information - every filled-in field has to be justified by making life easier for them.

    Accessibility, standards, compatibilty.

    This is all about how your system will connect to other tools in the outside world. Accessibility means making your web site work for users with physical limitations. Generally adhering to standards

    • increase the lifetime of your site
    • make it easier to change systems at the end of its life, or whenever
    • make it easier to re-use your resources in ways you haven't thought of yet
    Compatibility may refer to some kind of integration with MS Office, or other software. NGOs with stakeholders in the developing world should mention here that some of their users may have connection constraints. Websites can be built to go faster. Examples:
  58. the mark-up code should comply with XHTML 1.1, that the styles comply with CSS 1.0, that any RSS feeds be version 2.0 compliant.
  59. The library should employ the Dublin Core metadata standard
  60. The site will be usable in Internet Explorer 5.5, and fairly consistent in other browsers. (Your current web stats package may tell you what browsers are being used to visit your site.)
  61. The site's editing interface should work in all standards compliant browsers. (some CMS can only be administered from Internet Explorer)
  62. Consider offering microformats for things such as contacts or events. Microformats allow the browser to understand these objects in a page, so, typically you can click to add them to your own calendar or contacts directory. Microformats are not well established yet, but should be easy to implement.
  63. the web site should publish an XML sitemap to improve its listing in Google, if not it's ranking.
    64. Finally stop and have a think about your partners and competitors. How might your web site build on or work with theirs?

    Versioning & Workflow

    A web site with an emphasis on the editorial process will want support from versioning and workflow tools. Versioning is storing a copy of previous pages, who edited them, what they did, and being able to roll back to those pages or compare them with the present. This can get complicated. Workflow is a mini-maze that a document passes through in its lifetime.

    [picture]

    Workflow can be very helpful in supporting the translation process. Here are some example requirements for versioning and workflow. Do not include these unless you need them.

  64. The system should support major and minor edits for public editors.
  65. The system should show the differences between any two versions of a page.
  66. The system should show page histories.
  67. Authorised editors should be able to make ad hoc alterations to the workflow.
  68. New pages should trigger translation requests with accompanying workflows.

    69. Publishing & Delivery

    Increasingly, web content is accessed not just through the web browser. Web sites, for example can optimised or completely redesigned for mobile phone small screens and lack of a mouse. RSS is a very useful and standard way to publish lists of articles or other information, without people actually visiting the site. You could specify the target screen size of your audience.

    Scalability

    We need to give an indication of the size of the site. This is an important indicator of the size of the project as well. Be optimistic because it will be more costly later to scale up. You should estimate quantities of everything.

  69. The site should have 4 levels of menu-driven navigation
  70. The site should hold 2000 pages of content with three comments on each page
  71. The taxonomy features should be usable up to 100 terms
  72. The server should cope with 1000 pages per hour
  73. The site may be translated into up to five languages
  74. Every listing of over 20 items should be broken into separate pages

    75. Security

    Few NGOs have special security concerns beyond what is provided for as standard. Every web solution on offer should allow different levels of access to the site with a username and password, and no access to unauthorised people. If you plan to do online transactions first consider using a third party such as PayPal, or justgiving. If your information is especially sensitive, or if you expect attacks for any reason, then consider SSL, a web hosting option. Most NGOs will have no special security concerns beyond:

  75. If the platform is bespoke, it should be certified by a credible third party as reasonably secure.

    76. Reporting

    When the site is up and running you should be doing at least some tracking, to find out which bits of your web site are most popular, and which bits are not working so well. When the web site gives this information, it is called reporting. Reporting is a very tricky field because there is a lot of noise on the web, and the stats are hard to interpret. Most CMSs come with some kind of reporting interface, but it is also very easy to plug into Google's Analytics. Only include this section if you have any special reporting requirements.

    Hosting & Maintenance

    Where will your web site live after it is built? Do you have a relationship with a web host already? What if it needs specialist hosting? Who will apply the patches to the CMS? Is this part of the build budget, or from your office overheads? Most imlementers will have a partner who looks after hardware and live systems, so only write something here if you have a special requirement. You may ask for a separate hosting proposal along with the main request for proposal.

    Documentation & Training

    It's always nice to be able to know your own system, and documentation is the explanation of your system. Most widely used CMSs have readily available documentation, but you can still require documentation of the configuration, or training materials as a kind of documentation. This will all add to the cost though. You need to find some way of describing the level or purpose of the documentation

  76. documentation should be sufficient for another developer to be able to maintain the system
  77. documentation should enable the sysadmin to tweak the system.
  78. all in house editors should receive a half day training with full materials and opportunity for two weeks questions

    79. This document borrowed ideas from the Volere requirements template.