Stage 2: The "Implicit" Requirements
 

As we all know, business requirements are never fully gathered upfront. In Stage 2 of this Challenge, you receive these "implicit" requirements, the ones that were considered to be "obvious" by Business, but rarely appear in the original business requirements, rather pop up after business starts using the V1 of the App:
 

1. Validate input data:

   This is to see how validation can be incorporated before system accepts a request:

   1. Do not allow Travel Start date to be before Current date, nor a Travel End Date to be before the Travel Start Date.

   2. Also, Requesters cannot be in two places at the same time, so don't let them submit a request whose travel date range overlaps another Pending or Approved Request from the same Requester. If there is another conflicting Request, let Requester decide if they want to Cancel that conflicting Request. And if the conflicting Request that is being Cancelled was already Approved, then notify the persons who had previously Approved it, that it is Cancelled.
       

2. Allow Cancelling a Request:
   Only the original Requester can cancel their own in-progress Requests. Of course, any Pending approvals for the Cancelled Request should also be Cancelled.
    

3. Disallow inappropriate Data changes:
   For example, Requester should not be able to change anything in the request after it is submitted. Instead, they would need to Cancel the Request and resubmit it with new data. This avoids a situation where one Approver has Approved but the other has not made a decision yet; and Requester goes and changes the request data.
    

4. Control Data security:
   Requesters should only see their own Requests and nobody else's.
   Line Managers should only see the Requests from the people that report to them.
   Department Managers should see Requests from their own department only.
   CFO and CEO should see all Requests.
    

5. Save partial Request Form:
   In this example App the forms are simple. But imagine if the forms were complex, which is common in real-life. Requesters should be able to fill the Travel Request and submit it immediately or save it as Draft for submitting later.
   If it is not submitted within 1 month, then automatically treat it as a Cancelled Request.
    

6. Avoid unnecessary Approvals:
   This is to see how business rules can be catered for.
   If the request is from a Line Manager who reports to a Department Manager, then go straight to Level 2 Approval skipping Level 1 Approval (but not if they report to another higher-up Line Manager).
    

7. Keep an Audit trail:
   The history for a Travel Request should be easily visible for the actors involved in it, to know who did what and when.
    

8. Cater for change of Approver:
   So that processes do not get stuck, if a Line Manager, Department Manager, CFO or CEO changes, then there should be a mechanism to reassign all their Pending Approvals to the new person.
   
    

Graphically, something like this (click to enlarge):