dataSpheric Web Development Requirements Gathering Explained

dataSpheric is a Phoenix web site company that knows that the power of successful business solutions is the expertise and insight of you and your people.

You are experts in your field. No computer, no piece of software can replace you. You've also made investments in your people and they know their jobs well. This article's core is the dataSpheric Web Development Requirements Gathering Explained document which is given to clients in a short presentation in the early phases of a web project. Since you web surfers don't have the benefit of the presentation (and because the process, for most people, is completely non-intuitive), a little back ground is in order.

Most organizations find a treasure trove of expertise in the human resources they develop over time. The solution is often right under your nose-you just need to make sure the right voices are heard. dataSpheric's requirements gathering process is geared to unlock creative and collaborative potential in your organization. Our highly participatory workshop process has tangential benefits above and beyond the software we produce. By recognizing and "expertizing" project participants, we can breathe fresh life into organizations. dataSpheric's solutions definition process is comprehensive, exhaustive, nearly aggressive in it's efficiency. It's also where we have the most fun! We don't know of any other Phoenix web development agency that combines these kinds of high level consulting skills for you!

Like many of our dataSpheric web project management templates, this Web Project Requirements Gathering Explained document is packed with subtle hints and indicators for the client but this one isn't a worksheet, it's purely informational. It not only explains how our client's input is used in the development process but it lays out certain ground-rules. Requirements gathering, like any other website development phase, is tightly controlled by time and cost factors. It's imperative that clients realize that delays escalate project cost and duration.

Altogether too often, clients seem to believe that the production process is "the web developer's job". This belief contains three fatal errors:

1. We don't know exactly what you need to do your job.
2. You don't know exactly what we need to do ours.
3. Website design is determined by content.

The first two points have to do primarily with web-enabled, that is, websites that do work like ecommerce or inventory management systems. The final point is most worthy of focus. Website design is in great part determined by content, not the other way around. The nature and quantity of information required by your website or your business is the single greatest determining factor in website design. And in the dataSpheric book, website design as a visual value is secondary to informational content. In other words, to us, what you say is more important than how you say it.

To wrap up our introduction, our reasons for an exhaustive up—front requirements gathering process are to nail down how it should work and what it should say before the real money starts getting spent. OK, here we go:

dataSpheric Arizona Web Project Requirements Gathering Explained

©2000-2004 dataSpheric

This document is intended to explain the requirements gathering process for a typical web project.

This process scales up or down, but remains the same for all projects great or small. It explains how our various activities combine to form a project specification that is achievable and coherent. It arranges these activities along our "critical path" to success. It also indicates where you, the primary stakeholders, will make your crucial contribution to the process.

This process requires much up-front investment of your and my time and expertise. In it, we make most of the crucial decisions and do much of the necessary work that is required for the project.

Each activity is represented in a square below.

The activities are sometimes referred to as worksheets, documents, plans or specifications. These can result from worksheets, meetings, workshops or focus groups depending on the scale of the project. In general, worksheets are followed up by notes which turn into documents which are circulated for approval, and then become briefs, plans and specifications.

I'll describe each and indicate how you are involved.

The Project Initiation Document is one that I use to get as good an idea of the global picture in which this project exists in as short a time as possible. It's kind of like a "cheat sheet" that I use in the first meeting and it's how I formally begin the documentation trail for each technology project. It establishes the universe that I'll operate in and indicates what kind of information I need to find. Most of the information I develop in this hand-filled form will be contained in my report of this meeting. This meeting takes place between myself and top-level primary stakeholder(s). It may result in follow up meetings with subordinates.

The Strategic Worksheet is arguably the most important piece of project documentation that is produced. It guides all further web development work, translates to the metrics we use to determine success and becomes the standard by which we judge ourselves. For the most part, this comes down to effecting the behavior of users.

As with any marketing, public relations, operational or mission-critical effort, this effort must dovetail with overall mission and strategy. It should also dovetail with established marketing, public relations and legal objectives. It must also produce specific key objectives for this project, it's reason to be. It must be simple, yet thorough enough to contain all of the expectations for this project. For these reasons, producing a strategic worksheet can involve meetings, conferences and workshops for a larger enterprise. They can be done on the phone for small outfits. But they cannot be done without your active participation. This document must be absolutely and wholly reflective of consensus and belief in your organization or it's objectives.

The Content Plan is where you must build your case to the consumer, point by point. Just as the strategic plan indicates what we want to accomplish, the content plan describes how we believe we can accomplish it. This involves mapping out the desired user experience through time. What are the key informational or emotional points we need to get across to produce our desired result? Like the strategy, this process can involve many or few people depending on scale. It should include persons with real marketing expertise where possible.

At this point I'll bring up the Visual Content Plan and the Copy Content Plan. These standard plans result from the recognition that some things are best said with words and some are best said with pictures. In fact, there's no reason to limit ourselves to copy and visual design with all the rich media out there, and the inclusion of these would produce their own content plans, and they are all components of the overall Web Site Content Plan. Content plans generally begin in outline format and expand to include Site-Flow or page-flow diagrams (discussed below) or even storyboards in a process similar to traditional media.

The Web Design Creative Worksheet is used to produce the Web Design Creative Brief, the document which guides and influences the work of the visual design people. As the strategy produces the overall goals and measures of success for the project, the Creative Brief becomes the standard by which the user experience can be judged (or defended).

The Functional Specification must frequently take place after the content plan is finalized, however functional requirements are often determined in content planning. This results from a "we want to do this then we want it to do that" scenario. For this reason, the Functional Specification may co-evolve with content planning. In it I identify and detail any functionality that exists in this project. I'm also envisioning the technologies that can perform these functions and the requirements of these technologies. For this reason, I or another technologist usually writes the functional specification using input from the appropriate stakeholders. You will also notice that the Functional Specification in our diagram has bi-directional arrows attached to Page Flow. This indicates the possibility of a feedback loop between what's asked for and what's possible. I usually catch such discrepancies before the point of page-flow diagramming but for more complicated projects, a Solutions Definition phase (discussed in Notes below) is employed to focus on and resolve such issues.

dataSpheric's inclusion of the Functional Specification process results from the fact that we do more in Phoenix and Arizona than build websites. We specialize in web-enabled software development. This usually involves more complex software programming and database development than most Phoenix web designers want to think about.

The Page Flow document is a companion of the content plan and further reflects our strategy. In it we arrange our user experiences and attempt to guide user responses in serial terms. The output of this is a flow chart with explanatory notes detailing content items and other experiential requirements for each module. I generally help you produce this document. It's often modified by input from designers later.

The Technical Specification is a document in which I or another technologist determines the operating environment or operational requirements of our project. This usually comes down to hardware, software, space or bandwidth terms. Of all preceding documents, this one probably least involves you as a key stakeholder aside from cost factors.

I package all of the above documents into the first Project Specification document and submit it for the review of all key project stakeholders. Upon final approval, this document can be easily repackaged as an RFP, or may be distributed whole or in part to development resources to begin work. The completed Project Specification must be complete enough to answer every anticipatable question regarding the project from a production standpoint.

Our technology project requirements gathering process seems rigorous to most of our clients here in Phoenix Arizona, frankly we believe that it's exhaustive in any locale. I think most folks are surprised to find out how much goes into it. It takes a lot of time and a lot of expertise-ours, yours, and your people's-to make your project the success it needs to be.

Notes:
Search engine optimization, where applied, adds another module to this process. Essentially this is a research process which identifies key search strings and trends as well as a review of competitors. A resultant list of keywords is integrated into site copy.

Solutions Definition is the other half of pre-production. This generally involves research, development, prototyping or consulting that may be required to determine feasibility and cost of the functional requirements that we determine in requirements gathering. In more complicated scenarios, Solutions Definition can create a feedback loop with our requirements process and can result in evolving Project Specifications. These result from a kind of bargaining process between technology people and key stakeholders as technologists offer feedback such as "we can't do that", "we could do it if we had X" or "we can't do that but we can do this instead". For this reason, I never consider any iteration of a Project Specification to be 'final', rather each version is numerically incremented, and the last in the series usually ends up being the one which is used in production. The level of resources devoted to Solutions Definition should generally have a direct relationship to the importance of the project or it's ability to impact the operational environment. At higher levels of importance or risk, Solutions Definition may happen well in advance of the greater Requirements Gathering process here described. In this case, usually one where a functional prototype has already been developed, the solution itself becomes the nucleus of requirements definition. This aside, I like the phases of Requirements Gathering and Solutions Definition to be distinct on a conceptual level because I want to know what's needed, not what's imagined to be possible. For smaller or non mission-critical projects, database modifications, determining which server the project will reside on or installing new software on a server are common examples of Solutions Definition. Fortunately for most smaller projects we are on established territory and no doubt exists regarding technological or other capability.

Of course, our requirements gathering and solutions definition flowcharts are more complicated than this in reality because they exist as part of our overall production template that takes more factors into account that we think it important to list for your benefit here. Your Phoenix web development project might variously involve intranet development, rigorous security, top search-engine rankings or such "critical junctures" in web project requirements gathering as to require a different "branch" in our solutions "tree".