System use case specification maintain commercial proposals - ESG-Project/documentation GitHub Wiki
← Home / Requirements / System Use Cases / System Use Cases Specification
|
|
Identification |
UC15 |
Use case |
Maintain commercial proposals for each client |
Actors |
Administrator, Technician |
Stakeholders and interests |
Consulting company: Ability to create, read, update, and delete detailed commercial proposals for each client. |
Pre-conditions |
User is logged into the system as an administrator or technician; System has access to relevant client and proposal data storage. |
Minimum guarantees |
System prevents invalid proposal entries. |
Success guarantees |
User successfully manages comprehensive commercial proposals for clients. |
Main Success Scenario
User Action |
System Response |
1. This use case begins when the user selects a client to manage proposals |
2. The system displays the list of commercial proposals for the selected client |
3. The user selects to create a new proposal |
4. The system displays the proposal creation form |
5. The user enters the general information of the proposal (e.g., title) |
6. The system validates the input |
7. The user fills in the list of objectives |
8. The system validates the objectives |
9. The user specifies the list of investments by selecting products offered by the company and defining a value for each product |
10. The system validates the investment list |
11. The user defines the payment terms, including down payment, installment options, or a customized payment plan |
12. The system validates the payment terms |
13. The user sets the timelines for the start and end of activities for each deliverable product |
14. The system validates the timelines |
15. The user adds a descriptive text about exclusions |
16. The system validates the exclusions text |
17. The user lists documentation items |
18. The system validates the documentation list |
19. The user saves the proposal |
20. The system validates all input and saves the proposal details in the database |
|
21. The system confirms the creation of the proposal to the user |
Alternative Flows
3a User cancels the action
User Action |
System Response |
1. The user cancels the action |
2. The system returns to the proposals list without making any changes |
5a-17a Invalid input in any proposal section
User Action |
System Response |
|
1. The system detects invalid input in the current section |
|
2. The system displays an error message to the user |
3. The user corrects the input and resubmits |
4. The system validates the corrected input |
19a Invalid proposal data
User Action |
System Response |
|
1. The system detects invalid data in the complete proposal |
|
2. The system displays an error message to the user |
3. The user corrects the invalid data and resubmits |
4. The system validates the corrected data and saves the proposal |
Special Requirements
- Investment List: Products must be selected from those registered by the administrator, with the option to define a value for each selected product.
- Payment Terms: Must include options for down payment, installment plans, or customized payment methods.
- Timelines: Must specify start and end dates for activities related to deliverable products.
- Form Continuation: The user can exit the form at any point and must be able to return to the step where they left off.
- Draft Saving: The system must allow saving proposals as drafts for later completion.
- Validation Rules: All fields must be validated according to business rules before saving.
- Auto-save: The system should automatically save changes every 5 minutes to prevent data loss.
- Version Control: The system must maintain a history of changes made to each proposal.
- Access Control: Only authorized users can modify proposals based on their role and permissions.
- Search Functionality: Users must be able to search and filter proposals by client, status, and date.