The Software Requirements Specification (SRS) is a communication tool between users and software designers. The specific goals of the SRS are as follows:

• 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:

Practical information

Odoo Version: 12

Current Platform: Online

Production Database URL: mycompany.com

Test Database URL: stagng.mycompany.odoo.sh

Admin Login: john.doe@mycompany.com

 

Business Need

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.

Functional Analysis: 

Workflow:

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.

Technical Analysis

Module Setup: 

Feature: DATE SYNCHRONIZATION

User Experience:

• Change the FORM View of the stock.picking model.

• If operation type = pick => scheduled date should be: readonly

• Additional Field: Related Picking beneath Source Document

• Business flow change: 

• When editing scheduled date of a stock.picking record, review the related picking from the same group_id

• if type = pick: set the same date for the user

Data Model:

• STOCK.PICKING Model:

• Add a computed field (related_transfer_id): that points via a Many2one field type to a stock.picking record

• Business Flow Change:

• How to compute the fields

• Find the related picking from the same group

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.

https://odoo-community.org/blog/the-oca-blog-1/post/manage-your-customers-business-requirements-in-odoo-58

https://apps.odoo.com/apps/modules/12.0/business_requirement/