Documentation Examples
These are sample project documentations I have created as a manager, developer, and UX strategist. I gather all the data needed and put together documents such as these to guide project stakeholders towards accomplishing goals.
Background and Overview ▾
Since the company started shipping the product a few months ago, the ordering process has been heavily paper-based with handwritten forms. Production and order status are listed on a white board and all are also handwritten. There are several problems with this system, to mention a few:
- handwriting can be hard to read which can cause misinterpretation
- paper-based documentation can only be seen in the office, in-person
- we have employees in remote locations who cannot access this information — information on the white board can be accidentally erased
- we will soon work with an external Contract Manufacturer (CM) that we need to remotely manage for parts inventory and production schedules.
It is proposed that an online, intranet system to handle order fulfillment and inventory management be created within the next 3 months (May-August) in time for the new shipments from the new CM.
Time Schedule ▾
Research: first findings must be completed by May 5.
Design: first version must be completed by May 12.
Implementation: first version must be completed by June 15.
Testing: first version must be completed by June 18.
Iteration, refinement (of research through testing): must be completed by July 28.
Launch: must be completed by August 5, 5pm.
Success Criteria ▾
This project will be successful if the time schedule, individual stakeholder/user prioritized needs, software qualities and requirements listed in this document are achieved.
Stakeholder and User Analysis ▾
Stakeholders / Users | Location | Description | Needs / goals |
---|---|---|---|
Sales | remote | Tech savvy, has access to internet, good at communicating | to place an order quickly and easily |
Accounting | remote | fairly tech savvy, uses Quickbooks | to add orders in Quickbooks, create an invoice when the order ships, sort out pay- ment issues with customers if needed |
Accounting | remote | fairly tech savvy, uses Quickbooks | to add orders in Quickbooks, create an in- voice when the order ships, sort out pay- ment issues with customers if needed |
Manufacturing/Production | in-house | technical, can build computers, integrate hardware & software | to prepare the orders to customer’s specification |
Packing | in-house | technical, can access internet | to include all accessories and pack the order |
Shipping | in-house | fairly technical, uses online shipping portals for UPS, FedEx, DHL, USPS, etc. | to create shipping documents and ship the order on time |
Customer Support | in-house/remote | technical, supports for hardware & soft- ware issues of customers | to see order specifications, date of order and shipping when customer calls to follow up on their order |
CEO | in-house/remote | technical, has lots to do | to see all orders (current, standing, shipped) at a glance |
Scenarios ▾
Sales: Sales gets an order from a customer. Sales gets the name, billing/shipping address, contact information, credit card information, the unit model or models being ordered, any additional software to install with authorization key, custom faceplate if preferred, if customer needs UK or EU power cord for performing abroad. Sales puts these information in one location in the ERP system called the Work Order form.
Accounting: Once an order is placed online by Sales, Accounting will add a Purchase Order number that ties it to the Quickbooks records. Accounting will check that all information are there particularly the method of payment. Any additional sorting out for payment is made at this point. A flag will be set to show that this order is good to be fulfilled.
Production: When Production sees the order is okay to fulfill, it will change the flag to show “accepted by production”. It will prepare the unit/s, install additional softwares, do tests and quality control. Production will use the Work Order as a spec sheet for every order to make sure the hardware configuration is correct, all the softwares are installed.
Packing: Once the unit/s passed all tests, it will be packed including additional purchased software discs. The status flag will be changed to “ready to ship”. Packing will look at the Work Order to make sure all the purchased software discs, correct power cord are included in the package.
Shipping: Shipping will prepare the shipping documents using the shipping information on the Work Order. When the shipping label is printed and pasted on the box, the status flag is changed to “ready to invoice”. Shipping cost and tracking number are added to the Work Order and Accounting will then charge the complete amount on the credit card on file. When the charge is cleared, Accounting sends the Customer’s Invoice to Shipping to include it in the package. The unit is then placed in the shipping pick up area and the status flag is changed to “shipped” when the order has been picked up.
Workflow Diagram ▾
This is a workflow diagram showing how the Sales department will go through the ERP system as they handle new orders.
And this one is an example workflow diagram of how the Accounting department will use the ERP system to keep track of billing, invoicing, putting orders on hold if there are payment issues, or releasing orders for shipment.
Functional Requirements ▾
Requirement Number | Description of Requirement | Reason of Requirement | Assumptions | Requirement Source | Dependencies | Reference Documents | History of Changes |
---|---|---|---|---|---|---|---|
FR-01 | The intranet ERP system should be accessible to authorized users only and should authenticate users with login and password. | There is an entry for credit card and contact information of customers who are high profile music artists. It is critical to keep these information safe and secure. | It is assumed that the server is kept safe and secure by the host at all times. | CEO, Accounting, Sales | The intranet is hosted by a remote host and offshore developer / maintenance engineer. | n/a | Created May 5th by AP. |
FR-02 | A summary list of all orders with status, tracking number and ship date (actual or expected) should be easily seen. | Customers call for status of their order and this information should be easily accessible to give them a quick response. | Some customers will call before ship date even though automatic notification is sent out to customers when order has shipped. | Support, Sales | Shipping needs to get the tracking numbers from UPS, FedEx, USPS, or DHL online systems. If online systems are down, use paper shipping form but still get the tracking number. | n/a | Created May 5th by AP. |
FR-03 | The Work Order form should be accepted and saved in the system only when required fields are filled. It is a must to notify the user filling out the form when fields are missing. | It causes great delay in production when work is started on an order and then the process is stopped due to missing information. | It is assumed that 70% or higher are custom orders. | Production | Credit card information and 3rd-party software authorization keys must be available when creating a Work Order form. | May and June sales reports. | Added June 20th by AP - custom orders increased from 60% to 80%. |
FR-04 | The “Create Work Order” button should be accessible. | Work Order creation and order fulfillment should be fast. | n/a | Sales | none | n/a | Added June 20th by AP. |
Nonfunctional Requirements ▾
Requirement Number | Description of Requirement | Reason of Requirement | Requirement Source | Category (External design, Performance, Maintenance, Safety & Security, Regulatory) | History of Changes |
---|---|---|---|---|---|
NR-01 | Labels, especially form labels, should be easy to understand, not abbreviated. | Avoid wrong entries, wrong interpretation. Work Order form is used by Production as the specification for orders. | Production | External design | Created May 5th by AP. |
NR-02 | Work Order form should fit in 8.5 x 11 paper for printing in portrait format. | Accounting needs a printed version of the order when order is completed. | Accounting | Shipping needs to get the tracking num- bers from UPS, FedEx, USPS, or DHL online systems. If online systems are down, use paper shipping form but still get the tracking number. | Created May 5th by AP. |
NR-03 | This custom ERP system should operate 24/7 to be available for access by remotely located Sales and Accounting personel. | Sales and Accounting are remotely located, in the east coast, Canada and California. People work round the clock. | Sales | Performance | Created May 5th by AP. |
NR-04 | The web pages, especially the login page should have the company logo. | To indicate that user is in the correct website. | Production | External design | Created May 10th by AP. |
NR-05 | Time out from active page within the ERP system if no activity on the page or the computer within 5 minutes. Authentication process should restart after timing out. | Avoid unnecessary exposure of critical information. | Production | Safety & security | Created May 15th by AP. |
NR-06 | All errors should be handled correctly, i.e. feedback messages explaining what information is incorrect should be stated clearly. | To get proper feedback if user entered wrong information; for seamless work flow, ease of use. | Production, Accounting | Performance | Created May 15th by AP. |
NR-07 | For Parts Inventory, the short parts should be distinguished and seen prominently. | Parts that are short should call attention so there will be no delay in procurement and production. | Production | External design | Created May 15th by AP. |
Software Quality ▾
User-friendliness – This ERP system will be a daily work environment for Music Company hardworking staff, this system must be easy to use and user-friendly.
Correctness – As this system will have critical information and mathematical calculations for orders, production schedules and parts inventory, it is imperative that this system performs correctly.
Reliability – To support on-time shipments of orders, it is a must for this system to be reliably working at all times.
Extensibility – Additional sections to support other future products and processes should be allocated. This system should be extensible.
Robustness – All error handling is expected to run properly to prevent crashes. All links are expected to connect to correct pages. All errors should be handled correctly by displaying feedback messages that clearly explain what the user did incorrectly. Feedback messages should be displayed near the screen area where the error occurred.
Maintainability – The system should be easily maintainable. (Maintenance role currently assigned to developer).
Repairability – In case of discovery of any bugs in the future, repairs should be easily performed. Safety & security – Customer credit card information and contact information of high profile music artists will be in this system. It is imperative to have the system safe and secure.
Understandability – To support extensibility, repairability, and maintainability, it is imperative that all aspects of this ERP system (design, code, test cases and documentation) be easily understandable, even to future developers who are not currently involved in the creation of the system.
Specifications ▾
This site has four main sections:
(1.0) Current Orders List
and under Section 1.0 is a sub-section: (1.1) Work Order Form
(2.0) Shipping Summary
(3.0) Production Schedule
(4.0) Parts Inventory
(1.0) Current Orders List is a one-page table that lists all active orders, with the most recent order listed on top. List items:
Item # | Work Order # | P.O. # | Order Date | Order Status | Customer Name | Order Description |
---|---|---|---|---|---|---|
(1.1) Work Order Form is a form with the details about an order. Most are form fields that user will type in information except for the bold, italicized items that have selectable choices listed next page:
Customer Name | Order Status | |
Billing Address | Phone Number | Work Order # |
Shipping Address (if different from Billing) | Credit Card Info | Purchase Order # |
Order Date | Ship Date | Expected Ship Date |
Model | Custom Faceplate | Custom CPU |
Custom Power Cord | Additional Software to Install | Accessories |
Shipping Method | Tracking Number | Additional Shipping Documents |
Comments / Notes | Work Order Author |
Form field items with selectable choices:
Order Status: NEW, HOLD, OK TO FULFILL, IN PRODUCTION, READY TO BILL, READY TO SHIP, SHIPPED
Model: MODEL 1, MODEL 2, MODEL 3
Custom Faceplate: LIGHT GRAY, ELECTRIC BLUE, BLACK
Custom CPU: AMD 34, AMD 40, AMD 45
Custom Power Cord: UK, EU, US
(2.0) Shipping Summary is a list of all orders that have shipped. Recent shipment on top. Sortable and searchable by customer name, model (in order description), order date or ship date. List items:
Item # | Work Order # | P.O. # | Ship Date | Order Date | Customer Name | Order Description | Tracking Number |
---|---|---|---|---|---|---|---|
(3.0) Production Schedule is a list of quantities per model located in various stations. It also lists the weekly build quantity based on the P.O. submitted to the Contract Manufacturer (CM). List items:
QTY. In-house | QTY. at CM | QTY. of WIP | QTY. to build for current P.O. | |
---|---|---|---|---|
Model 1 | ||||
Model 2 | ||||
Model 3 |
MONTH 1 | MONTH 2 | ||||||
---|---|---|---|---|---|---|---|
WEEK 1 | WEEK 2 | WEEK 3 | WEEK 4 | WEEK 1 | WEEK 2 | WEEK 3 | WEEK 4 |
(4.0) Parts Inventory is a list of all parts based on current Bill of Materials (BOM) showing the parts information and quantities. List items:
Item # | MFG P/N | Company P/N | Part Description | QTY. in-hand (CM) | MOQ | Lead-time | QTY. needed for P.O. 1 | QTY. needed for P.O. 2 |
---|---|---|---|---|---|---|---|---|
Sitemap ▾
This is the sitemap that shows the sections of this custom intranet ERP site.
Wireframes ▾
A sample annotated wireframe for the Current Orders List.
An annotated wireframe for the Work Order Form.
Mockups ▾
A mockup for the Login page of the ERP site.
A mockup of the Work Order Form.
A mockup of the Current Orders List page.
Revision History ▾
Version # | Date | Description of Change | Section | Author | Approval |
---|---|---|---|---|---|
3.0 draft 1 | |||||
2.0 approved | |||||
2.0 draft 4 | |||||
2.0 draft 3 | |||||
2.0 draft 2 | |||||
2.0 draft 1 | June 20 | Added FR-03, FR-04 | Functional Requirements | AP | JC |
Added NR-07 | Nonfunctional Requirements | AP | JC | ||
1.0 approved | May 15 | Added NR-05, NR-06 | Nonfunctional Requirements | AP | JC |
1.0 draft 2 | May 10 | Added NR-04 | Nonfunctional Requirements | JD | JC |
1.0 draft 1 | May 7 | First version, first draft | AP |