|
|
|||||
Thinkydink Template For Creating A User Requirements Document
If you want to protect yourself from scope creep, that horrible phenomenon whereby the customer approves your intial specs but then swears on his mother's grave that you didn't fulfill the contract when you deliver your program (and maybe uses this as grounds to reduce or withold payment), you'd better get in the habit of writing solid user requirements documents. This document will not only save you from an unending stream of modification requests from the customer, it can serve as a sales tool when responding to general proposal or bid requests.
A requirements document differs from a Software Detailed Design Document (SWDD) in that where a requirements document lays out the WHAT - the required functionality of the application -, a SWDD lays out the HOW - the specs of the design intended to meet the stated requirements. In general, the Requirements Document should contain all of the major headings shown below, with the possible exception of "Test Findings". If a given heading isn't applicable to your particular situation, you should still include the heading and a statement of inapplicability to show the customer that you've thought about that subject and judged it to be outside the scope of your project.
Give an overview of the reason this new application is needed, or of the reported problem that requires you to develop a fix or enhancement for an existing application. If you have cost-benefit analysis data, refer to that document here but keep cost benefit data in a separate document to avoid making the user requirements document unwieldy.
This is an optional heading for new application development, but it is always necessary when developing a fix or enhancement for an existing application. The user reports a bug, but he may not understand the root cause of that bug. This is where the developer says, essentially, "the user/customer reported X, and my findings are Y". Where appropriate, provide a test results matrix in an appendix to the requirements document and reference that matrix here.
Describe your proposed application or bug fix/enhancement solution at a very high level. Think in terms of function rather than detailed design; remember that your design details belong in the SWDD, and this is a document intended for user/customer consumption. Keep technical details out of this document, and instead focus on what the application or solution will do from the user/customer perspective.
If this is a new application, what will the user interface look like? If you are making modifications to an existing application, what changes will be made to the existing interface? Mock up every new or modified user screen and include images of your mock ups. The customer should see exactly what he will be getting.
What new reports will be provided, or what changes will be made to the existing reports? Mock up every new or modified report and include images of your mock ups. As with the user interface, the customer should see exactly what he will be getting.
Again, follow the example of the two previous sections. For a new application, detail the various levels of security to be provided and explain how the provided security will impact the user: what will the login process look like to the user, and if there are to be administrative level users, what rights will the administrator users have? Will the application security be synchronized with network or operating system security? What happens if the user forgets his password? Will inactivity timers be used to automatically exclude users from the security group for this application? Cover all security-related topics and issues here.
How will your new application or modifications impact day-to-day processes of the customer? Will certain manual tasks become automated? Will new tasks or responsibilities be introduced?
This is the place to include two process flow diagrams: one for the existing process flow and one for the process flow after your new application or modifications are introduced. In the case of a bug fix, procedural changes are typically not necessary.
How will your new application or modifications impact production and existing data? Will any data conversion be necessary, and if so, what is your plan to accomplish the conversion? Will any legacy data be excluded from the new solution, and if so, what will be done with that legacy data? Will any downtime be required during implementation or for regular maintenance of your solution, and if so, what will be the frequency, timing, and duration of that downtime? Will any legacy systems be impacted by your solution, and if so, how?
Document every possible impact, however small or unlikely. What looks like a minor impact to you could be a dealbreaker from the customer's perspective.
"Development Issues" is really just a more pleasant-sounding name for risk. This is the place to document all the potential risks of your project. If there are unknowns in the area of budget or schedule, give the best and worst case scenarios. If your project has dependencies on other projects or people, let your customer know what will happen if those dependencies are not met. Any other concerns or possible difficulties should be laid out here, from end-user receptiveness to time and space limititations.
Just what it sounds like: what will the training needs of the user community be, how will it be provided, and who will be responsible for delivery?
This is where you describe who will be responsible for what. Attach names or titles to every function required to make your project a success: project manager, programmer, tester, user liaison, network administrator, account executive, user test group, trainer, accountant, etc. If any of these roles are to be filled by customer representatives, be clear about your expectations. Also include information about who will pay for various expenses, and who will provide needed equipment and office space.
XII. Target Dates and Estimates
Provide a project schedule and a milestone itinerary. Break the project down into a series of tasks and provide estimates for completion of each task down to the hour increment. The task list must be as detailed as possible; for instance, referring to all the programming to be done under a single task heading of "coding" does not give an acceptable level of detail. Include hours for research, coding, debugging and iterations for each module or program element to be included in the project. This is especially crucial if you will be billing by the hour.
XIII. Assumptions and Limitations
Think long and hard about this one before handing in your requirements document. You are probably harboring some assumptions that you're not even aware of. Try to come up with a list of all the things that could happen to sink your project and then rephrase them in the form of assumptions. For example, you are probably assuming that no staffing changes will occur during your project life cycle, and that known dependencies will be met. Spell everything out, no matter how obvious it might seem to you.
This is also where you talk about what is not being included or addressed by your project. If your customer has not requested certain, typical pieces of functionality (i.e., reporting capability, printing capability, etc.) identify the excluded functionality as a known limitation of your solution.
Include any additional screen shots, test findings, financials, etc. here.
XV. Requirements Document Approval
Possibly the most important section of the document, this is where you and your customer literally sign up to accept the terms of your requirements document.
Provide a grid with the names of every responsible party and a space for each to sign and date, plus a blurb above it that says something like, "I hereby give my approval of this requirements document [include title or reference number] as follows." Follow the blurb with three checkboxes: "as is", "with changes (see my attached notes)" and "not approved".
Once you've got a copy of the requirements document with "as is" signatures from every responsible party, you're ready to rock and roll without fear of scope creep, additional liability or confusion between the responsible parties.
|
Send
comments and questions about this site to the Webmaster@Thinkydink.com
All Thinkydink site content copyright April Hamilton, 2000-2002, All
Rights Reserved.
|