Desc 72DC ription
- As an Intake Analyst
- I want an automated notification when a request received online is not opened after a 5 business days
- so that I do not miss an new FOI request
Assumptions & Scope
What are the assumptions for this story?
When an FOI request is submitted through the online form, the request details are captured as "Unopened" request in the FLOW DB. All submitted requests are been captured in the DB.
A very small number of emails are not being sent to the Intake Inbox from the FOI Request webform.
The system will match the applicant's email submitted with the request online with requests manually opened in AXIS and synced to MOD. Emails are already in the DBs just need to make the match.
If an applicant makes 3 requests, and only 2 were opened then the Intake team should be notified.
What is IN scope?
What is NOT in scope?
Acceptance Criteria
Scenario 1: Notification for all Intake Users in Notification Log
- GIVEN an request was submitted through the online form
- AND the applicant has provided an email address
- WHEN a request has not been synced from AXIS into FOI Mod within 5 business days
- THEN the system will automatically notify all Intake team members
- AND this message will appear in their notification log, "ALERT: request [INSERT LINK to Unopened Request] was received online from applicant email 5 business days ago. The request has not been synced from AXIS."
Scenario 1: Notification for all Intake Users in Event Queue
- GIVEN an request was submitted through the online form
- AND the applicant has provided an email address
- WHEN a request has not been synced from AXIS into FOI Mod within 5 business days
- THEN the system will automatically post
- AND this message will appear in the Intake Team Event Queue, "ALERT: request [INSERT LINK to Unopened Request] was received online from applicant email [INSERT EMAIL ADDRESS] 5 business days ago has not been synced from AXIS."
Scenario 3: xxxxxx
...
Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)
Validation Rules? (If yes, list here)
Design
@xxx - please link the Design here
Definition of Ready
- Is there a well articulated User Story?
- Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
- If there is a user interface, is there a design?
- Does the user story need user research/validation?
- Does this User Story needs stakeholder approval?
- Design / Solution accepted by Product Owner
- Is this user story small enough to be completed in a Sprint? Should it be split?
- Are the dependencies known/ understood? (technical, business, regulatory/policy)
- Has the story been estimated?
Definition of Done
- Passes developer unit tests
- Passes peer code review
- If there's a user interface, passes UX assurance
- Passes QA of Acceptance Criteria with verification in Dev and Test
- Confirm Test cases built and succeeding
- No regression test failures
- Test coverage acceptable by Product Owner
- Ticket ready to be merged to master or story branch
- Developer to list Config changes/ Update documents and designs
- Can be demoed in Sprint Review
- Tagged as part of a Release
- Feature flagged if required
- Change Management activities done?