Requirements Documentation
This is a preliminary Requirements Document produced by one of my students in the CS432 class at Regis University. I personally thought it was a good start to the document. As is discussed on the page that references this page, the Requirements Document is never done. It should be kept up to date throughout the life of the project.
The Rubber Ducky Corporation
Note:
Please read Chapter 3 of Jim Arlow and Ila Newstadt’s book: UML 2 and the Unified Process – Second Edition to better understand what needs to be in the Requirements Document. Remember that the Requirements Document is a “living” document and should be updated throughout all phases of the project. Know your customer’s goals and processes as well as your customer.
Background:
Even though a background section is not listed as needed in a Requirements document, I feel it is very important to understanding the company and the people in the company so that what you are developing better fits the needs and wants of the company.
The Rubber Ducky Corporation is an established firm that makes rubber and wooden water fowl or various degrees of realism. They are admired for their hand painted/hand carved wooden water fowl, as well as their spirited multi-colored ducks. They have started rubber ducky races all across the country to promote local charities, as well as to help increase the sales of their products. All of their sales have been through local merchants or phone sales. They would like to enter direct sales to customers through the internet. All of their current phone representatives, manufacturing, and management live in an unincorporated part of Michigan that they lovingly call Water Fowl. They do not want to have much of an impact on their community, but they want to grow their business. Their products are just a little higher than other manufacturers, but they feel that their products are of much higher quality and feel they could offer a longer warrantee than any other company. They are proud of all of their products being manufactured in Water Fowl, but realize that they may have to open another plant if the business takes off too much.
Staff:
When you identify staff, be sure to identify roles first and then people. Remember that roles stay fairly constant, whereas the person filling that role may change. Also, when you start designing your project, you need to design it around roles and not specific people. You may find a better may of doing a process than the way a particular person does a particular process.
- CEO – Mary
- CFO – Bob
- IT Manager – Joseph
- Phone Sales Manager – Marsha
- Phone Sales #1 – Martha
- Phone Sales #2 – Margaret
- Phone Sales #3 – Melissa
- Phone Sales #4 – Megan
- Shipping Clerk – John
- Warehouseman – Jon
- Marketing Manager – Juan
- Marketing Assistant – Matilda
Culture
The staff are all good friends and get along quite well. They want the website to be an extension of their company and not just another website to get lost in the maze of other websites. If possible, they want to incorporate their favorite song, Weird Al’s “I want a new Duck.” They want a more playful presentation for the rubber ducky section. However, they want a more serious presentation of the hand carved and painted wooden water fowl.
Functional Requirements:
Customers:
Who are the customers of Rubber Ducky, how do they currently interact with the company? How would the company like them to interact, i.e. internet, phone, mail? What do you want to know about your customers? What do you want their experience to be? Be sure to cross reference the Security section below and address any security concerns the customer might have.
Products:
What products does Rubber Ducky have? How will they be listed? Will prices be listed directly with the products? Will the prices be on a separate table? How will they be updated, when needed? How will you be able to add in new products? How will you be able to obsolete old products? Are there any other tasks the company would like you do do with the products database?
Orders:
How do you take orders? Is there a shopping cart? How do customers add or remove items to/from the shopping cart? How are the customers informed of what items they have in their shopping cart and how much they cost? If it is a disposable product, like nutritional supplements, can the customer set up automatic orders on a regular basis? Are there any other ideas for good order handling?
Sales:
How does a customer check out and pay for the order? What mechanisms are available? How easy is it? Are there ways to cancel a Sale or portions of a sale. If you allow partial cancellations, then the customer may not cancel the entire order. Allowing cancellation before the order is shipped saves everyone time and money.
Channels:
How can a customer buy your products? Direct sales, web, phone, mail. etc.
Payments:
If you don’t require a credit card payment at the time of order, then how are you going to handle payments?
Other Areas
What other areas are there that have not been covered in this section? How do you get yourself noticed on the internet, including search engines?
Non-functional Requirements:
The project is bound by several natural and artificial constraints. There are some remaining questions that will need to be answered before coding can begin. These are listed in the appropriate section or at the bottom. Each is stated with a brief description of where to gather the necessary information to answer them.
Database Driver:
The entire web site will be built around a back-end database. This database will contain all products and their associated prices. MySQL and Postgres will be analyzed through their documentation to verify they have the necessary features to drive a portal such as this. In addition, research will be done to determine what databases are used on similar portals.
Compatibility:
The site must be 100% usable in either Microsoft Internet Explorer or Mozilla Firefox. This means that there will be no proprietary code used, such as MS ActiveX.
Cost:
Since there is little or no budget to complete this project, most, if not all, of the underlying code needs to be based on open-source software. This may include the use of MySQL for the database, and Perl for much of the content engine.
Architecture:
This system will reside on Linux-based systems, and as such must be compatible with such. Additionally, the web server to be used will be the already implemented Apache 2.0.
Maintainability:
The code must be written in such a manner that it can be maintained by any skilled developer. This means that code will be well commented and documented, and no proprietary systems will be used.
Performance:
How fast do the responses need to be, assuming the customer is using DSL or a Cable Modem? What other performance issues are there and how are they going to be solved?
Capacity:
How many customers or phone clerks can be on the website at the same time without hurting service? How large of database can you have (this might be put in the database section)? Are there any other related issues?
Availability:
When is your system available? Might also include things like to how much of your database will customers or clerks have access? What will be the restrictions? How will these be determined?
Compliance in Standards:
Are there any website or industry standards to which you need to comply?
Security:
What are the security issues you need to address? How will they be addressed? How will you keep your customer data secure? How will you prevent hacking by those who log into the system? How do you prevent spy-ware from infecting your system. How do you prevent “bombing” or other attacks that attempt to bring your server to its knees?
Needed Information:
Will the search engine be developed in-house or purchased? There are several open-source search engines available. These will be examined for their appropriateness. If no suitable cheap engine is found, it will need to be developed.