Functional Specification Template
- Mary Jo Kochendorfer (Deactivated)
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
|
|
|
|
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.
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 ________"
| Must have, nice to have... | Additional considerations or noteworthy references (links, issues) | After review with the development team, these will become stories | |
2 | 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. | ||||
3 | 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 | ||||
4 | 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 | ||||
5 | 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 |
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. |
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.
OpenLMIS: the global initiative for powerful LMIS software