The Software Requirements Specification (SRS) is a communication tool
between users and software designers. The specific goals of the SRS are
- Facilitating reviews
- Describing the scope of work
- Providing a reference to software designers (i.e. navigation aids, document structure)
- Providing a framework for testing primary and secondary use cases
- Including features to customer requirements
- Providing a platform for ongoing refinement (via incomplete specs or questions)
Gaps between what is expected and what is delivered are often a
source of conflict in a project. The better you can functionally and technically analyze and explain your requirements, the greater chance you have of getting what you want!
Consider that diagrams and images (screenshots) communicate a great deal. If you use them wisely to help illustrate what you require you can benefit from clear communication as well as reduce the amount of descriptive documentation you need.
Requirements analysis and planning are the keys to the success of an implementation.
Here is a simple Example:
Odoo Version: 12
Current Platform: Online
Production Database URL: mycompany.com
Test Database URL: stagng.mycompany.odoo.sh
Admin Login: firstname.lastname@example.org
We deliver IT equipment to educational distributors, school districts, individual schools and tutoring facilities. An important and time consuming aspect of this is the preparation of the products to be shipped.
In order to facilitate the process in Odoo, we are going to – for some of our products - leverage the
Two step (pick + ship) configuration within the Inventory App (picking and delivery).
The scheduled date on a delivery is very important in our case as each scheduled date represents an agreement that is discussed with the site or school but frequently changes after the order is confirmed.
The picking and receiving team packs the products on the same date as the delivery (in the morning) and then dispatches those orders later (in the afternoon). The scheduled dates on both the picking document and the shipping document should always be the same so that the teams only work with products and deliveries needed each day.
Although both documents are created together as soon as the Sales Order is confirmed, it could be easier to see the relationship between the two documents. To improve this, users should be able to switch quickly from one document to another.
1. Create a sale order with several lines
2. Confirm the Sales Order
3. Observe the automated creation of 2 related Stock Transfer documents:
- the PICK -> at this stage, the status of this document is "waiting"
- You can see the link to the document for the second step - WH/OUT
- the OUT -> at this stage, the status of this document is "waiting another operation" (waiting for the WH/PICK to be validated)
- You can see the link to the document for the first step - WH/PICK
Both documents have a default "scheduled date" computed according to the validation date of the Sales Order.
4. We discuss the delivery with our Customer.
5. The delivery date becomes more finalized, and the schedule date is set on the WH/OUT. EACH TIME there is a date change, the same date is set automatically on the WH/PICK. The date on the WH/PICK cannot be changed manually.
6. Based on the final scheduled delivery date, the team will prepare the orders in the warehouse and will validate the WH/ PICK with a barcode scanner when the palette or paletes(s) are ready. Once WH/PICK is validated, the status of WH/OUT becomes "Ready".
7. The team loads the palettes and validates the WH/OUT, indicating the products are on their way to the shool or site.
Feature: DATE SYNCHRONIZATION
Business Flow Change:
Note that Odoo itself is a great tool to collect and document your Business Requirements. You can check out some of the work the Odoo Community Association has done with their Business Requirements App.