Website Specification

Basic Website Specification Please complete this document to the best of your ability. If you can answer all of these questions then you will have the basis of a website specification for your organisation. The more preparation you undertake before undertaking a web development, the better end result you can expect. It is sometimes useful to have developed a document like this before you speak to a web developer, or, alternatively, this can form the basis of a conversation with your web developer. General 1.1. Overview Explain what your organisation is and what it does. 1.2. Background Explain why you are wanting a website developed at this stage e.g. if it is for a particular project or a particular audience, or if its an upgrade of an existing website. 1.3. Current Situation Give details of what you currently have got, including the website name, if this is appropriate. Tender 2.1. Overview Give details of what the tender covers. 2.2. Timescales Give details of tender process and timescales Specification 3.1. Overview Explain what the website is for and try and summarise it. In the sections that follow you should list what it is you want and explain that tender applicants will be judged on how they interpret the brief, their proven ability (e.g. design, technology); 3.2. Stakeholders The website has a number of different stakeholders -: (amend as appropriate) - existing clients - new/potential clients - funders and statutory bodies - project team The main audience is…. Workers and volunteers in Social Enterprises across Greater Manchester (amend accordingly) 3.3. Design Here list any design issues – relates very much to the audience/stakeholders. i.e. “corporate look” “friendly look” – whether or not it should incorporate any existing design elements, colours or logos. 3.4. Navigation You may not have a clear idea of navigation at this point – but if there are any particular issues or principles then include them here. You may also want to include some features in at this point (e.g. search/site map) but it might be better to work in general principles and see what solutions will be provided by the developers. 3.5. Accessibility Websites should comply with the Disability Discrimination Act. This document has been produced by Manchester Digital Development Agency 2009. It is issued under a Creative Commons AttributionNon-Commercial 2.0 UK: England & Wales Licence. MDDA cannot be held responsible for any way in which this document is used.

A generic statement along the lines of “the website should be designed so that it incorporates relevant accessibility features” can put the onus on the developer to show they understand accessibility. 3.6. Content Give an indication of type of content that will be included on the site. I.E. the site may include text, photographs, audio, video, PDFs etc. 3.7. Integration Increasingly websites need to integrate with back office systems (e.g. ticketing system, financial systems, customer relationship management systems), so be clear where this is the case. E.g. Registrants on the site need to have their details checked against the existing CRM. 3.8. Third Party Plug-ins Web 2.0 functionality increasingly involves integrating with 3rd party applications. E.g. YouTube, Flickr, iTunes, RSS feeds. Even if this is not the case, it’s likely that developers will look to using 3rd party applications to deliver particular functionality (e.g. an online gallery, a shopping cart). 3.9.Administration The site will be administered by One/or a number of users and should be able to be administered from any internet connection. If you have specific levels of “permission” that you require then these should be indicated. If you definitely require a CMS (Content Management System) then say so – otherwise, list the features. E.g. You want to be able to give different update permissions for a number of users; you want to be able to easily upload pictures, audio and text and documents; you want to be able to restructure the site and add different layers of information. You may also want to get web statistics and this will be another function of the administration. 3.10. Additional Functionality If there are any particular functions that you need. E.g. An online poll; a forum or registration system then go into as much detail as possible. I would suggest that you make a distinction between “Must have” and things that you want to see what the price might be. 3.11. Security Any levels of security that you require. E.g. a secure members area; an ecommerce or payments system. 3.12. Hosting Ask for hosting (and domain name registration) costs as a separate item. Give a level of service that you require or don’t require. (i.e. eBay needs 99.99999% uptime – you probably don’t). If you expect a large about of visitors and downloads to the site this can be more expensive as well. Insist that any solution is scalable and can be ongoing beyond the initial period.

This document has been produced by Manchester Digital Development Agency 2009. It is issued under a Creative Commons AttributionNon-Commercial 2.0 UK: England & Wales Licence. MDDA cannot be held responsible for any way in which this document is used.

This document has been produced by Manchester Digital Development Agency 2009. It is issued under a Creative Commons AttributionNon-Commercial 2.0 UK: England & Wales Licence. MDDA cannot be held responsible for any way in which this document is used.