Error getting theme layout

Requirements document structure

Posted @ 8:14 am by Alex Kaplinsky | Category: SolutionSet, Technology, User Experience, Web Development Process | 0 Comments

We’ve been spending a lot of time working on our requirements document template here at SolutionSet.  My previous post about methodology mentions that the purpose of the Define phase is to describe “what” the project is.  The final deliverable from the design phase is the Requirements document.  In this article, I will examine the table of contents of our requirements document and why each section is important.

One thing to keep in mind is that this requirements document is slightly different than one for in-house use. When presenting any document to a client in a consulting relationship, it’s important to declare what is in scope and what is out of scope.  The requirements phase is when those involved in digital project start really thinking of “what” they want the project to be.  The problem lies in the fact that when you start thinking of “What would be good to have?” scope has a way of increasing with imagination.  So this table of content is meant to show what is included in a project, but also to be a tool that both parties can agree to in order to keep scope reasonable on the project.

Table of Contents from a sample requirements document:

  1. Introduction — an overview into what this document is about and also the objective and scope.
    1. Business Overview — why this project is being undertaken from a business point of view.  Also included should be any objective  measures and success criteria.
    2. Project Scope — a re-iteration of the project scope, what is to be done with this project, and what is to be left for future projects.  This should contain as much detail as possible and should include a matrix of key pages to be worked on during design. All pages should be wire-framed and designed, all copy should be written, and sample HTML should be produced.  Sometimes these are the only deliverables (if the project stops at HTML), but more often than not these “key pages” will be used to inform the rest of the site.  Setting key pages during requirements forces the joint team to focus on what’s important and re-iterates scope in terms of final deliverables in the design phase.
  2. User Analysis — provides a high level overview of who the users of the digital property are and what they might be doing on once they arrive.
    1. Audience — looks at who the various audiences are and why they would be coming to the site.  Included should be the various high level take aways that the audiences will walk away from the project with.
    2. Personas — defines some sample users of the site.  Typically will include some demographic / psychographic information about the persona, why they would be using the site, and what some common tasks they might try to achieve when coming to the site.
    3. Use cases — define how the various personas would interact with the site.  This will show how the users would actually navigate within the site, what functions they would expect to find, and what the expected result would be.  This allows for the creation of user flows by the UI team to explain what series of screens the user would interact with and what they would be able to do on each screen.
  3. User Experience Requirements — shows how the users will experience and interact with the site.
    1. Site map — shows the organization or “bucketing” of information into primary, secondary, and tertiary navigation items.  The site map will label and identify each page and get the entire team on the same page as to what the navigation choices and names are.  This also informs creative when designing the pages.
    2. Use flows — the use flows show certain decision paths as outlined by the use cases.  The user flows are meant to show how a user (admin or end user) will interact with the site.  Use flows are tightly tied into the site map as ever screen the user interacts with in the use flows is identified in the site map.
    3. Key page wireframes — for those pages considered “key” to the design, wireframes will be produced.  The wireframes are used to build final consensus as to what functions and information each page will contain.  They ensure that everyone knows what elements are on the pages, their relative hierarchy, and a suggestion as to layout.
  4. Creative / Brand Requirements — The creative and brand requirements are a supplement to and summary of the Creative Brief if the project is large enough to merit it’s own creative brief (perhaps covered in a different post).  In all projects, however, they must speak to both Brand and Creative requirements.  For each, the document should describe how the current brand and creative should influence the site.  The brand requirements should restate the major points of the brand platform to be used.  The creative requirements will further list out all the requirements for inclusion and exclusion from a visual perspective.  The purpose of the creative and brand requirements should be to inform all parties as to the framework upon which the content and creative will be produced.  The requirements should set limits and areas for exploration and will be the guiding principles for the visual design and content creation.
    1. In Scope requirements — The in scope requirements are items that are specifically called out in the SOW or proposal.  These items will all be included within the scope of the current project.
    2. Requested enhancements — Requested enhancements are items that the customer or team has requested be part of scope, but which are not called for in the SOW or proposal.  These items may trigger cost changes depending on the size of the request and the overall flexibility of the budget.  The client and consultant must agree upon the cost (even if $0) of these enhancements or they will be considered out of scope.
    3. Future enhancements — Future enhancements are items that should be documented and taken into account when designing the site, architecture, technology, etc.  However, they are explicitly out of scope and the client and consultant have agreed that these items are for reference only.
  5. Marketing requirements — The marketing requirements will define how the users will be brought to the site and messaged.  The marketing requirements covers the types of campaigns to be conducted (Print, media, Ad words, banner adds, SEO, etc.) and what the desired spends are for each.  The marketing requirements also define what the requirements are for the site in terms of SEO compatibility, landing pages, and tracking and analysis of the data.  The purpose of the marketing requirements section is to give all parties a full understanding of what online and offline marketing campaign will be conducted by the consultant and what the requirements of the property to support the marketing campaigns will be.
    1. In Scope requirements
    2. Requested enhancements
    3. Future enhancements
  6. End User functional requirements — the end user functional requirements describe what the site visitor is able to do when they interact with the site.  This will be a full inventory of the activities and functions for all the various types of users.  For basic sites, this will typically be limited to finding various types of information, navigating and searching the site, and contacting the host organization.  For more complex sites, this will include login and registration, profile maintenance, shopping functions, advanced searches of various types of data, personalization, data input, queries of public data, interactions and messaging via multiple devices, etc.  All such requirements should be captured and details should be given to each function.  From reading the end user functional requirements, it should be clear what a user can and can’t do.  It is especially important for the in scope, requested enhancements, and future enhancements to be clearly spelled out.  Best practices to be used in this section include references to similar functionality on other sites and reference to the site map and wireframes for specificity.
    1. In Scope requirements
    2. Requested enhancements
    3. Future enhancements
  7. Administrative functional requirements — Like the end user, all administrative functions need to be described.  Administrative functions are functions performed by members of the host organization (client) or their affiliates who log in with a password to perform certain actions to maintain the website.  On simple sites, this is typically limited to content management and management of data from the site such as user management or order management (in simple e-commerce sites).  For more complex sites, this will expand to descriptions of all administrative search / filtering that needs to be performed on data, all data input and management functions, all reporting functions. All such requirements should be captured and details should be given to each function. From reading the administrative functional requirements, it should be clear what each level of administrator can and can’t do.  It is especially important for the in scope, requested enhancements, and future enhancements to be clearly spelled out.  Best practices to be used in this section include references to similar functionality on other sites and reference to the site map and wireframes for specificity.
    1. In Scope requirements
    2. Requested enhancements
    3. Future enhancements
  8. Technical requirements — should spell out what the requirements are for the system, the core software, front end, and tracking and measurement.
    1. In scope requirements
      1. System and  hosting requirements — will spell out how much traffic (number of users, amount of data in the system, concurrent page views, reads vs. writes, etc) the site will be able to handle.  The requirements will state where the site needs to be hosted and on what base architecture (OS, DB, Web Server).  The systems and hosting requirements will also spell out the redundancy and fail-over requirements for the system.
      2. Core packages (CMS, main systems, etc.) — often times, a project will be based around a core package. Sometimes that package or packages are known and should be stated.  Other times, the requirements for what functions must be supported should be listed.  If the package(s) are not known, then these requirements can become the base for an CMS or other core system analysis and recommendation.  If a recommendation is reached by the time of writing, it should be included.
      3. Front end and browser requirements — It is crucial to decide what what technologies are supported and what standards must be maintained.  If Javascript or Ajax is to be used for interactions, this should be called out here.  If any rich media or interactive objects (Flash/Flex/Silverlight) are required or allowed, they should be discussed.  Front end coding standards (508 compliance, HTML level, etc.) as well as supported browsers will be listed in this section.  This will serve to inform both client and consultant as to what is in scope in terms of QA and coding standards and what might need to be put off till later phases.
      4. Analytics and tracking requirements — To be able to determine if the marketing and overall business requirements are being met, the requirements for analytics and tracking should be listed.  For simpler projects, this might just be simple usage and path analysis (often provided by Google Analytics with little effort).  For more complex sites, this often involves setting up custom tracking codes, conversion funnels and goals, and setup and customization of analytics packages (such as Omniture).  The goal of defining these requirements is to ensure that all parties understand what is needed in terms of tracking to satisfy the business goals and know how successful the site is.
    2. Requested enhancements
    3. Future enhancements
  9. Content requirements — setting up content requirements for the site and assigning responsibility will ensure that the site will have the correct content for (re)launch.  The requirements will often refer to the site map and wireframes (in smaller sites) or a content inventory spreadsheet to define what content needs to be produced.  The requirements will speak to the need to re-write or create entirely new content that speaks to the desired brand and works within the new site architecture and look and feel.  This section will also specify who will provide the content for each of the pages (client or consultant) and when the content will be produced.  By clearly defining the required content, the responsible parties, and the required dates all parties should have a clear understanding of one of the key areas of delay for site launches.
    1. In scope requirements
    2. Requested enhancements
    3. Future enhancements
  10. Updated project plan — the updated project plan should be provided as the final part of the requirements document.  Any changes from the original plan should be noted and more details should be provided.  The details should include all launch / QA plans, and the specifics of which pages will be delivered from content, UI, visual design, HTML, alpha, beta, etc. with each round of deliverables.  This detailed schedule serves to cement the requirements and how the project will unfold to meet all listed requirements with the client and the entire team.
  11. Appendix A: Assumptions — this will capture all the technical, creative, brand, user, admin, and content assumptions made while creating the proposal and requirements document.  These assumptions will be covered with the entire team and client so everyone can understand what the assumptions made in creating the requirements were.
  12. Appendix B: Scope Changes — in a tabular format, this section captures all of the current and future scope changes.  It summarizes each, approximate level of effort (sometimes in people days, sometimes as low, medium and high), and lists out what the cost of the change is and whether the change is agreed upon by the client.  This section of the document will be used to create  change order(s) with a price associated with each item.

If you’ve actually read this far, I hope you’ve found this TOC with explanations helpful.  Keep in mind that the overall goal is for everyone involved to understand what the project is and what the consultant and client responsibilities are in completing the project.  With that goal in mind, and this as on overall framework to structure your thoughts, you should be able to create a meaningful document to share with your clients.

Leave a reply

Error getting theme layout