Description of each Section

Why are we doing what we are doing? What important background information is needed for the stories and may describe the pre-conditions or triggers?

Ideally including a statement describing what this functionality seeks to achieve. If possible, the objective would provide criteria guidance of how success would be measured or tested.

Example Functional Documentation

Scope

The steps taken to accept shipped stock, via a proof of delivery within OpenLMIS, into the facility's inventory. The main additional feature is the ability to reject shipments.

Background

The process by which facilities using OpenLMIS for stock management accept shipped stock into their inventory. The shipped stock must come from either a shipment file (from an ERP with OpenLMIS integration) or a fulfillment facility using OpenLMIS. If stock is shipped to the facility with only with a paper POD (perhaps from a 3rd party or donation), that stock will be entered via an adjustment.

Receive verified quantity and quality of goods into store and determine need for remedial action when necessary.

See /wiki/spaces/OP/pages/88670483 for the full example.

Who are the users that will be interacting with this functionality? What are their challenges, responsibilities, and level of connectivity?

These personas are intended to be representative archetypes of the key stakeholders who will participate in theses workflows/scenarios.

Personas

User	Goals	Pain Points	Context, Characteristics, Comments, Quotes
Title: Storeroom Manager	To manage my storeroom stock levels. Ensure timely ordering/issuing of the right commodities in the right quantity. I want my facility to have the right stock at the right time. I want to ensure the right stock is being ordered. I want to minimize stock outs.	Stock outed commodities Over stocked Plays multiple roles	Low technical skills Has limited / poor internet connectivity examples, could be pharmacy assistant or medical assistant, nurses for HIV, Health Surveillance supervisor

See the External User Profiles page for the full list of OpenLMIS user personas.

Describes the tasks and the personas who perform those activities. The diagram provides the context for the user stories and serves as a focal point for achieving clarity and agreement among stakeholders. Looks like a standard flow chart.

Business Process Diagram

See http://www.path.org/publications/detail.php?i=1865.

Short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

User stories

#	Title	User Story	Importance	Notes	Ticket
1		Describe the user and what they are trying to achieve. "As a __(persona)__ , I want/need to _________ so that ________" High level acceptance criteria?	Must have, nice to have...	Additional considerations or noteworthy references (links, issues)	After review with the development team, these will become stories
2	View POD with approved requisition quantities	As a storeroom manager receiving stock into my inventory I want to be able to electronically view and fill out a proof of delivery that shows what I requisitioned, what was fulfilled, and what I actually receive so that I have proof within OpenLMIS of stock movements and visibility into my current SoH.			OLMIS-892
3	Reject shipment outright	As a storeroom manager at any level I want to be able to wholly reject a shipment if it is unacceptable for whatever reason so that I am not held responsible for defective products and can follow the SOP			OLMIS-686
4	Partially reject shipment	As a store room manager I want to be able to partially reject a shipment by receiving the actual quantities of stock that I are delivered to me in good working order so that my stock levels are accurate and I can follow the SOP			OLMIS-685
5	Provide e-signature to POD	As a store manager at any level I want to account for shipments I've received that are going to be quickly sent out/picked up by another facility so that my stock balances aren't artificially high while waiting to send this package onward			OLMIS-237

See OLMIS-646 - Getting issue details... STATUS epic for a list of stories.

Identify initial dependencies that are on the critical path for this functionality and may affect the delivery time and serving of business goals.

Dependencies

Description	Link
Electronic version of a stock card Used to mirror the physical cards that sit in storeroom bins and serve as a log of all past ins and outs for each commodity in the storeroom. Each stock card should contains all transactions for each batch of the commodity. There has to be an electronic stock card prior to the work on local fulfillment can begin.	OLMIS-623

Description

Link

Electronic version of a stock card

Used to mirror the physical cards that sit in storeroom bins and serve as a log of all past ins and outs for each commodity in the storeroom. Each stock card should contains all transactions for each batch of the commodity. There has to be an electronic stock card prior to the work on local fulfillment can begin.

OLMIS-623

See /wiki/spaces/OP/pages/88670474 for an example.

Initial communication between stakeholders and the development team to help understand scope and estimates

Open Questions

Question	Outcome	Status
Is there a need for order generation to be configurable? Right now, it is a manual step.		Open
Do we want to increase the configuration of order templates?		Open
How should the rejected or returned stock be handled at the warehouse?		Open

See /wiki/spaces/OP/pages/88670474 for details.

Elements out of scope for the feature.

Out of Scope

Out of scope features or elements being addressed in future development.

Make sure the development team understands the context and desired feature. Provide mockups and additional diagrams/context.

Additional information

Can include mockups, wireframes and other notes which will help the team understand the context of the feature request.

Browser not supported