Login page

Here is a structured breakdown of user stories with screen fields,

dependencies, and validations related to enforcing password-based access
control:

🔐 Epic: Enforce Password-Based Access Control

🧑‍💼 User Story 1: User Registration with Password Setup

As a new user,
I want to create an account by setting a secure password,
so that I can securely log in to the system.

✅ Acceptance Criteria:
 Users must provide a password that meets defined security criteria.
 Passwords are stored securely (eg., hashed and salted).
 Users confirm their password to avoid typos.

Screen Fields:
 Username or Email (Required, Unique)
 Password (Required, Masked Field)
 Confirm Password (Required, Must match Password)
 Employee Id as required when it is not system User.

🔗 Dependencies:
 Password policy must be defined in system configuration.
 Unique user ID/email must be verified before registration.

Validations:
 Password must:
 Be at least 8 characters long
  Include upper- and lower-case letters
 Include at least one digit and one special character
 Password and Confirm Password must match exactly.
 Username/email must not already exist.

🔑 User Story 2: Login with Password Authentication

As a user,
I want to log into the system using my credentials,
so that I can access authorized functionality securely.

✅ Acceptance Criteria:
 Users must enter valid username and password to gain access.
 Passwords are never shown in plain text.
 Login fails after a defined number of incorrect attempts.

Screen Fields:
 Username or Email (Required)
 Password (Required, Masked Field)
 Captcha with Alphanumeric generated and Input place holder for Captcha

🔗 Dependencies:
 Account must exist and be active.
 Password hash must match stored value.

Validations:
 Required fields must not be empty.
 Lock account after as per policy defined by IT failed attempts.
 Captcha enter by the user and System Generated Captcha Should Match. If
it not match system need to show Error Message on the Above Container.
 Display generic error on failure (avoid "user not found”, “Password not
correct”).
🔁 User Story 3: Change Password
As a logged-in user,
I want to change my password from my profile or settings page,
so that I can maintain account security.

✅ Acceptance Criteria:
 Users must enter current password to authorize change.
 New password must meet policy requirements and not match previous
password.

Screen Fields:
 Current Password (Required)
 New Password (Required)
 Confirm New Password (Required, must match)

🔗 Dependencies:
 User must be authenticated and logged in.

Validations:
 Current password must match stored hash.
 New password must be different from previous N passwords.
 Enforce same password strength policy as registration.

❓ User Story 4: Forgot Password / Reset Password

As a user who forgot my password,
I want to reset it via email verification,
so that I can regain access securely.

✅ Acceptance Criteria:
 User enters email to request password reset.
 A secure reset link is emailed and expires after X minutes.
 User sets a new password using the link.

Screen Fields:
Request Reset:
 Email (Required)
Reset Page:
 New Password (Required)
 Confirm Password (Required)
Security :
 Mobile OTP
 E-Mail OTP

🔗 Dependencies:
 Valid email and Mobile number must be associated with a user.
 Email and Mobile service must be functional.

Validations:
 Rate-limit reset requests to prevent abuse.
 Reset token must expire and be single-use.
 Password must meet strength requirements.
 OTP to Mobile & E-mail both has to Enter.

🔍 User Story 5: Enforce Password Expiry and History

As a system,
I want to enforce password expiry and history rules,
so that users change their password regularly and avoid reuse.

✅ Acceptance Criteria:
 Password must be changed every as per the Policy by the Department.
 System warns users X days before expiry.
 System prevents reuse of last N passwords.

🔗 Dependencies:
 Password expiry policy configured in system settings.
 Password history maintained securely.

Validations:
 Prevent login if password is expired. System Should send a Mail for Rest
Password.
  Prevent setting a password that matches any of the last N passwords.

Session Management -

Session Timeout After Inactivity

As a logged-in user
I want my session to expire after a period of inactivity
So that the system remains secure and prevents unauthorized access

🔁 Session Management Behavior:

Attribute Rule
Session Duration Defaults to X or N minutes of inactivity (configurable)
Warning Message Optional popup 1–2 minutes before timeout
Auto Logout Redirect to login page with message: Session expired. Please log in
again.

✅ Validations / Handling:
 Upon session expiry:
o Clear session token/cookie
o Redirect to login page
o Display:
pgsql
CopyEdit
🔒 Session Expired
Your session has expired due to inactivity. Please log in again to con-
tinue.

 Prevent any further API calls using expired token

🧾 User Story 3: Maintain Session State (Optional)

As a user
I want to be able to stay logged in for longer sessions if I choose
So that I don’t get logged out too quickly while actively working
Fields (Optional):
 ✅ "Remember Me" checkbox on login
o Stores session token for longer period (e.g., 7 days)
o Only on trusted devices

GPS coordinates -
As an auditor,
I want to upload photos with embedded GPS coordinates,
So that the audit system can verify the location of audit events and artifacts.

Screen Fields
Upload Photo (File input – mobile camera or local file)
Auto-Fetched GPS Coordinates (Latitude, Longitude – read-only)
Person/Subject in Photo (Dropdown: Auditor, Auditee, Artefact)
Description/Notes (Text area)
Audit Engagement ID (auto-linked or selected)
Upload Button

Dependencies
 Mobile device or browser with GPS/location permission
 Photo metadata reader (to extract EXIF GPS data)
 Secure file storage system
 Audit engagement module

Validations
 Image file types allowed: JPG, PNG (others rejected)
 If photo lacks GPS data, prompt user or request confirmation
 Reject uploads without valid engagement link
 Limit file size (e.g., max 10MB per image)
 Validate GPS coordinates are within expected audit area (optional)
User Story 2: Capture Real-Time Photo with GPS Data (Mobile)
As an auditor using a mobile device,
I want to capture photos in real time and auto-embed GPS coordinates,
So that the system accurately logs the audit location of the photo.

Screen Fields
 Open Camera Button
 Auto-Capture Location (GPS status indicator)
 Subject Type (Dropdown: Auditor, Auditee, Artefact)
 Capture Button
 Preview Image
 Confirm and Upload Button

Dependencies
 Mobile device with camera and location services
 Location permission granted by user
 Native camera or web-based camera integration
 Backend support to save image and metadata

Validations
 GPS signal must be active before capture
 Warn user if location permission is denied
 Block upload if GPS data is missing or corrupted
 Photo metadata must include timestamp and coordinates

User Story 3: View Geo-Tagged Photo with Map Visualization

As an audit manager or reviewer,
I want to view uploaded geo-tagged photos on a map,
So that I can visually verify the locations where audit evidence was collected.

Screen Fields
 Audit Engagement Filter
 Date Range Filter
 Map View (Google Maps or similar)
  Photo Markers (clickable pins with thumbnails and metadata)
 Photo Details Modal (Image, Timestamp, Location, Uploaded By)

Dependencies
 Mapping API (Google Maps, Leaflet, Mapbox)
 GPS metadata from uploaded images
 Photo storage service

Validations
 All photo markers must correspond to valid GPS coordinates
 Show warning if photo metadata is incomplete
 Clicking a marker must display accurate photo and uploader info

User Story 4: Configure Photo Upload Requirements

As a system administrator,
I want to configure rules for photo uploads (e.g., required GPS, max size),
So that only valid and useful photo evidence is captured.

Screen Fields
 Require GPS Tag (Toggle: Yes/No)
 Maximum Upload Size (Input: MB)
 Allowed File Types (Checkbox: JPG, PNG, etc.)
 Retention Period (Input: days/months)
 Save Settings Button

Dependencies
 System settings module
 Photo upload service
 Validation enforcement engine

Validations
 Admin must configure all required fields
 Invalid combinations (e.g., require GPS but allow non-image files) must be
blocked
  Retention must fall within acceptable limits (e.g., 30–3650 days)

🔐 System-Level Requirements
 All uploaded photos must be securely stored (encrypted at rest).
 Metadata (timestamp, GPS, uploader) must be tamper-proof.
 Access to view or delete photos must be role-restricted.
 Each upload should be logged in the audit trail (who, when, from where).

Department Selection

To define user stories along with screen fields, dependencies, and valida-
tions for the hierarchy you've provided, we can break this down by levels and cre-
ate detailed requirements for each. This would suit a system (e.g., an organiza-
tional hierarchy or management portal) where different units are nested within
each other.

🔷 Entities and Their Hierarchy

1. DEPARTMENT – Level 1
2. DIRECTORATE / AGENCIES & BOARDS – Level 2 (both depend on DE-
PARTMENT)
3. OFFICES – Level 3 (depend on DIRECTORATE or AGENCIES/BOARDS)
4. STATIONS/FIELD UNITS – Level 4 (depend on OFFICES)
5. PROGRAMS/SCHEMES – Linked to any above level (depends on use case)
6. PROJECTS – Usually tied to PROGRAMS/SCHEMES

🔹 Sample User Stories with Screen Fields,

Dependencies, and Validations
🧾 User Story 1: Add a Department (LEVEL-1)
As an Admin, I want to add a new Department so that I can organize the
top-level structure of the organization.

 Screen Fields:
o Department Name (Text)
o Department Code (Unique, Alphanumeric)
o Description (Text Area)
o Status (Active/Inactive)
 Validations:
o Name and Code are required.
o Department Code must be unique.
o Status must be selected.

🧾 User Story 2: Add a Directorate or Agency/Board (LEVEL-2)

As an Admin, I want to add Directorates and Agencies/Boards under a
Department so that I can structure them properly.

 Screen Fields:
o Type (Dropdown: Directorate, Agency/Board)
o Name (Text)
o Code (Unique)
o Parent Department (Dropdown – Populated from Level 1)
o Status (Active/Inactive)
 Dependencies:
o Must select a Department first.
 Validations:
o Name, Type, and Parent Department are required.
o Code must be unique.
o Must validate that selected Department is Active.

🧾 User Story 3: Add an Office (LEVEL-3)

As an Admin, I want to add Offices under a Directorate or Agency/Board
so that office-level operations can be defined.

 Screen Fields:
o Office Name
o Office Code
o Type (Dropdown: HQ, Regional, etc.)
o Parent Unit (Dropdown – Only Directorate or Agency/Board)
o Location
o Status
 Dependencies:
o Parent must be either Directorate or Agency/Board (Level 2)
  Validations:
o Cannot assign to both Directorate and Agency/Board simultaneously.
o Office Code must be unique.

🧾 User Story 4: Add a Station/Field Unit (LEVEL-4)

As an Admin, I want to register Stations or Field Units under Offices to
map ground-level operations.

 Screen Fields:
o Station Name
o Code
o Location (GPS or Address)
o Parent Office (Dropdown – Level 3)
 Dependencies:
o Must have a valid parent Office
 Validations:
o Location is mandatory
o Code must be unique

🧾 User Story 5: Create a Program or Scheme

As a Program Manager, I want to define Programs/Schemes and
associate them with any organizational level to track implementation.

 Screen Fields:
o Program Name
o Type (Program/Scheme)
o Related Entity (Dropdown with Department → Station)
o Start and End Dates
o Objectives
 Dependencies:
o Related Entity must be selected from a valid active unit
 Validations:
o Start Date < End Date
o Program Name must be unique within the selected entity

🧾 User Story 6: Add a Project

As a Project Officer, I want to create Projects under a Program so that we
can manage deliverables.

 Screen Fields:
o Project Name
o Associated Program/Scheme
o Budget
 o Milestones
o Status
 Dependencies:
o Must be linked to an existing Program/Scheme
 Validations:
o Budget must be a positive number
o Associated Program must be active

Audit Period

Here are user stories with screen fields, dependencies, validations, and but-
ton actions for managing Audit Periods and a Proposed Audit Schedule, in-
cluding workflow actions like Save, Send for Approval, Approve, and Reject:

✅ USER STORIES – AUDIT PERIODS & SCHEDULE

🧾 User Story 1: Enter or Edit Audit Periods

As an Audit Officer, I want to record the Last and Current Audit Periods
so that the system reflects accurate audit history.

🖥 Screen Fields:

 Last Audit Period (Date Range – From, To)

 Current Audit Period (Date Range – From, To)
 Remarks (Optional text area)
🔄 Dependencies:

 Cannot create a current audit period unless the last audit period is defined.
 Current audit period must be sequential (i.e., after the last audit period).

✅ Validations:

 Both date ranges must be valid and not overlap.

 Last Audit Period “To” date must be before Current Audit Period “From”
date.
 Periods must not span more than one fiscal year (if required by rules).

🧩 Buttons/Actions:

 Save – Save draft without workflow.

 Send for Approval – Submits data to designated approver.

🧾 User Story 2: Propose an Audit Schedule

As an Audit Officer, I want to propose an Audit Schedule for a given
period so that it can be reviewed and approved.

🖥 Screen Fields:

 Audit Period (Dropdown/List – Select from previously entered Current Audit

Period)
 Department/Unit (Dropdown – Based on org hierarchy)
 Audit Start Date
 Audit End Date
 Auditor(s) (Multi-select – Users assigned audit roles)
 Scope/Notes (Textarea)

🔄 Dependencies:

 Schedule must be tied to a valid Current Audit Period.

 Audit End Date must be after Start Date.
 Auditor must be selected from active users with auditor role.

✅ Validations:

 Cannot overlap with existing approved audit schedules for the same unit.
 Dates must fall within the selected Audit Period.
 All fields (except Notes) are required.

🧩 Buttons/Actions:

 Save – Save proposed schedule as draft.

 Send for Approval – Submit to approver with status “Pending Approval.”
 Approve (visible to Approver only) – Finalize and lock the schedule.
 Reject (visible to Approver only) – Send back with optional comments.
🧾 User Story 3: Approve or Reject Proposed Audit Schedule
As an Approver, I want to review, approve, or reject proposed audit
schedules so that audits are properly planned and tracked.

🖥 Screen Fields:

 Review Audit Period & Schedule Details (Read-only)

 Comments (Optional – required on rejection)

🔄 Dependencies:

 Only records in “Pending Approval” state should be shown for action.

✅ Validations:

 Comments must be entered if Reject is selected.

🧩 Buttons/Actions:

 Approve – Updates status to “Approved,” locks editing.

 Reject – Updates status to “Rejected,” returns to initiator.

🔁 Workflow Summary
Status Action Next Status Role
Audit
Draft Save Draft
Officer
Send for Pending Audit
Draft
Approval Approval Officer
Pending
Approve Approved Approver
Approval
Pending
Reject Rejected Approver
Approval

Audit Team Selection

Here's a set of detailed user stories for an Audit Team Selection feature, in-
cluding screen fields, dependencies, validations, and workflow actions
(Save, Send for Approval, Approve, and Reject). These stories assume a standard
workflow management system such as used internal audit software.

🧾 User Story 1: Create Audit Team

As an Audit Manager
I want to create and assign team members to an audit
So that the team can begin preparing for the audit

Screen Fields:
 Audit Name (auto-filled / read-only)
 Audit ID (auto-filled / read-only)
 Audit Period
 Audit Type (e.g., Internal, External, Compliance)
 Team Lead (dropdown – list of eligible users)
 Team Members (multi-select dropdown – users with “Auditor” role)
 Remarks / Notes

Validations:
 Team Lead must be selected
 At least 2 Team Member must be selected
 No duplicate selections (e.g., Lead should not also be listed as a member)
 Team Lead and Members must be active users
 Audit Period must be valid and not overlap with closed audits

Dependencies:
 Users available for selection must belong to the same business unit (or de-
fined scope)
 User roles and availability pulled from User Management system

Workflow Actions:
 Save: Store team draft; editable later
 Send for Approval: Locks the entry, triggers approval workflow
✅ User Story 2: Approve Audit Team
As an Audit Director
I want to review and approve the selected audit team
So that the team can officially start audit activities

Screen Fields:
 View-only fields: Audit Name, ID, Period, Team Lead, Members, Remarks
 Approval Comments (optional)

Validations:
 Only users with “Approver” role can approve
 Cannot approve unless “Send for Approval” was triggered
 If any team member is no longer valid (e.g., inactive), show a blocking error

Workflow Actions:
 Approve: Locks team configuration, marks it “Approved”
 Reject: Sends back to Audit Manager for rework; status “Rejected”

🔁 User Story 3: Rework Audit Team (Post-

Rejection)
As an Audit Manager
I want to revise the team based on feedback
So that I can resubmit the team for approval

Screen Fields:
 All editable fields from User Story 1
 Rejection Reason (displayed read-only from previous rejection)

Validations:
 Same validations as original team creation
 Must address the feedback before re-submission

Workflow Actions:
 Save
 Send for Approval (again)
🧮 User Story 4: View Audit Team Status
As an Auditor or Manager
I want to view the status of audit team assignments
So that I know if I’ve been assigned or the team is approved

Screen Fields:
 Audit ID, Audit Name, Status (Draft / Pending Approval / Approved / Re-
jected)
 Team Lead, Members, Approval Status, Comments

Workflow Status Transitions Summary:

Action From Status To Status
Save - Draft
Send for Pending
Draft
Approval Approval
Pending
Approve Approved
Approval
Pending
Reject Rejected
Approval
Save (after
Rejected Draft
Reject)

Audit Intimation

Here’s a refined set of user stories for the Audit Intimation feature, incorpo-
rating the fields you mentioned, including screen fields, field dependencies,
validations, and the Send Intimation button as the primary workflow trigger.

🧾 User Story 1: Compose and Send Audit

Intimation
As an Audit Manager
I want to compose and send an audit intimation to selected recipients
So that stakeholders are officially notified about the audit schedule and the
assigned team
Screen Fields (Input UI):
Field Name Type Description
Recipient Multi-email input (comma- One or more email addresses of
Email separated or tag-style) stakeholders
Intimation
Rich Text / Multi-line Text The message body to be sent
Message
Audit
Schedule Date Picker Start date of the audit
From
Audit
Date Picker End date of the audit
Schedule To
Select Audit List of Approved audit teams
Dropdown
Team (name + ID)
Auto-fetched from selected
Audit Name Auto-filled Text
audit team
Auto-fetched from selected
Audit ID Auto-filled Text
audit team
Send Triggers email dispatch and
Button
Intimation logs the action

✅ Field Validations:
 Recipient Email
o Must not be empty
o Must contain at least one valid email address ( [email protected])
o No duplicates
o Each address validated with regex or backend check
 Intimation Message
o Required field
o Minimum 10 characters
o Max 1000 characters (optional limit for concise communication)
 Audit Schedule From & To
o Both required
o From date must be ≤ To date
o Cannot overlap with already scheduled audits for same team (busi-
ness rule)
 Select Audit Team
o Required
o Only approved teams shown in dropdown
o On selection, populate Audit Name and Audit ID
 Send Intimation (Button)
o Enabled only if all required fields are valid
o On click, triggers:
 Email dispatch to recipients
 Record log of intimation (timestamp, sender, recipients)
  Status change (e.g., to "Intimation Sent")

🔄 Dependencies & Logic:

 Selecting an Audit Team auto-fills:
o Audit ID
o Audit Name
o Optionally restrict available dates for scheduling based on team avail-
ability
 Email sending uses back-end mail service; confirmation of success/failure
required
 The list of approved audit teams is pulled from the previously approved
team configurations

✅ User Story 2: View Sent Audit Intimations

As an Audit Admin or Manager
I want to view a list of all sent audit intimations
So that I can verify who was notified and when

📋 Display Fields:
Field Description
Audit ID / Audit
To identify which audit
Name
Comma-separated or tag-
Recipients
style emails
Intimation Sent
Timestamp
Date
Audit Schedule From
Scheduled audit window
/ To
Team Assigned Team Name and Lead
First 100 characters or view
Message Preview
full

Popup for Intimation:

Here’s a focused user story and functional detail for the “Audit Intimation
Sent Successfully!” popup, including screen fields, dependencies, valida-
tions, and behavior upon a successful send.
🧾 User Story: Display Success Popup After
Sending Audit Intimation
As an Audit Manager
I want to see a confirmation popup when the audit intimation is sent successfully
So that I know the recipients have been notified and the process was completed
without error

💬 Popup Message:
css
CopyEdit
✅ Audit Intimation Sent Successfully!
The intimation email has been sent to all selected recipients.

Popup Fields / Elements:

Field / Element Type Description
Icon (green
Success Icon Visual confirmation of success
tick)
Message Title Text (bold) "Audit Intimation Sent Successfully!"
Additional context, e.g., "Email has
Message Body Text
been sent."
Close Button Button Closes the popup
[Optional] View Button
Navigates to audit intimation history
Log Button (optional)

✅ Popup Trigger & Dependencies:

 Shown only if all validations pass and email dispatch is confirmed
successful
 Triggered after clicking “Send Intimation”
 Backend response (e.g., HTTP 200 OK from email service) is required before
showing the popup

❌ If Email Sending Fails:

Instead of success popup, show an error toast or modal:
cpp
CopyEdit
❌ Audit Intimation Failed!
Please check email addresses and try again.
🧩 Validations Prior to Triggering Popup:
 All required fields filled and valid (email, schedule, team, message)
 Backend confirms:
o Email addresses are reachable (SMTP response)
o Message template processed successfully
 No runtime exceptions during dispatch

🧭 User Flow Example:

1. User fills in intimation details
2. Clicks Send Intimation
3. System validates form
4. Email service responds success
5. ✅ Popup appears with confirmation
6. User clicks Close or View Log

Task Assignment

Here’s a detailed breakdown of user stories for a Task Assignment feature, in-
cluding screen fields, dependencies, validations, and support for Add and
Remove buttons to manage multiple tasks dynamically.

🧾 User Story 1: Assign Tasks to Team Members

As a Project Lead or Audit Manager
I want to assign tasks to individuals with deadlines and task descriptions
So that each team member clearly knows their responsibilities

Screen Fields (Per Task Entry):

Field
Type Description
Name
Task Name of the task (e.g., “Collect Financial
Text (single line)
Name Statements”)
Assign Dropdown List of users (filtered by role/team if
 Field
Type Description
Name
To needed)
Deadlin
Date Picker Deadline for task completion
e
Task Textarea / Rich Detailed description or instructions for the
Details Text task
Add / Remove Add a new task row or remove an existing
Action
Button one

➕ Add Button Behavior:

 Adds a new blank row with all the fields (Task Name, Assign To, etc.)
 Maximum number of tasks can be limited if needed (e.g., 20)

➖ Remove Button Behavior:

 Removes the current row
 If only one row remains, may optionally disable removal to avoid empty
state (optional)

✅ Validations (Per Row):

Field Validation Rules
Task Required, min 3 characters, no special
Name characters like < > { }
Assign Required, must be an active user in the
To system
Deadlin
Required, must be a future date
e
Task
Optional, but if filled, limit to 1000 characters
Details

🔄 Dependencies:
 Assign To dropdown is populated from the current audit team or project
team
 Deadline may be constrained within project/audit period dates
 Task Name suggestions can be driven by task templates (optional)
🧾 User Story 2: Save or Submit Task
Assignments
As a Project Lead
I want to save or submit the task assignments after filling them out
So that the tasks are recorded and assigned to the responsible persons

🔘 Actions:
Button Function
Save Saves all task assignments in current state for later
Draft edits
Validates and finalizes assignments, notifies
Submit
assignees (optional)

🧩 Backend/Workflow Dependencies:
 On submit, system should:
o Save tasks to database
o Optionally notify users via email/notification
o Log who assigned the task and when

💡 Optional Features (Can Be Separate Stories):

 Task Status (e.g., Not Started, In Progress, Completed)
 Attachment field in Task Details
 Priority field (Low / Medium / High)

Popup for Intimation of Task Assignment

Here’s a focused user story and functional detail for the “Task Assignment
Sent Successfully!” popup, including screen fields, dependencies, valida-
tions, and behavior upon a successful send.
🧾 User Story: Display Success Popup After
Sending Task Assignment.
As an Audit Manager
I want to see a confirmation popup when the Task Assignment is sent
successfully
So that I know the recipients have been notified and the process was completed
without error

💬 Popup Message:
css
CopyEdit
✅ Task Assignment Sent Successfully!
The intimation email has been sent to all selected recipients.

Popup Fields / Elements:

Field / Element Type Description
Icon (green
Success Icon Visual confirmation of success
tick)
Message Title Text (bold) "Task Assignment Sent Successfully!"
Additional context, e.g., "Email has
Message Body Text
been sent."
Close Button Button Closes the popup
[Optional] View Button
Navigates to Task Assignment history
Log Button (optional)

✅ Popup Trigger & Dependencies:

 Shown only if all validations pass and email dispatch is confirmed
successful
 Triggered after clicking “Send Intimation”
 Backend response (e.g., HTTP 200 OK from email service) is required before
showing the popup


❌ If Email Sending Fails:

Instead of success popup, show an error toast or modal:
cpp
CopyEdit
❌ Task Assignment Failed!
Please check email addresses and try again.
🧩 Validations Prior to Triggering Popup:
 All required fields filled and valid (email, schedule, team, message)
 Backend confirms:
o Email addresses are reachable (SMTP response)
o Message template processed successfully
 No runtime exceptions during dispatch

🧭 User Flow Example:

7. User fills in intimation details
8. Clicks Send Intimation
9. System validates form
10. Email service responds success
11. ✅ Popup appears with confirmation
12. User clicks Close or View Log

Audit Prerequisite Document Submission

 Epic: Audit Prerequisite Document Submission
 User Story 1: Submit Audit Prerequisite Documents
As an internal user (e.g., compliance officer),
I want to upload and submit required audit documents through a structured form,
So that the audit process can be initiated in a timely and compliant manner.
 Screen Fields
 Document Type (Dropdown – e.g., Financial Report, Compliance Report,
etc.)
 Document Name (Text – Required)
 Upload File (File Picker – Required; Accept: PDF, DOCX, XLSX)
  Submission Date (Auto-filled, Read-only)
 Comment / Description (Textarea – Optional)
 Dependencies
 Document types must be pre-configured in the admin panel.
 Submission only enabled if all mandatory documents are uploaded.
 Validations
 Only allowed file formats: .pdf, .docx, .xlsx.
 Maximum file size: 10MB.
 Duplicate document names for the same type must be flagged.
 Required fields cannot be empty.
 Submission date auto-filled with current date; not editable.

 User Story 2: View Submitted Documents

As an internal user,
I want to view a list of previously submitted documents,
So that I can verify and download them if needed.
 Screen Fields
 Document List Table:
o Document Type
o Document Name
o Submitted On
o Status (Pending Review, Approved, Rejected)
o Actions: View, Download, Delete (if status = Pending)
 Dependencies
 Pulls data from the audit submission database.
 Edit/Delete only allowed before audit review begins.
 Validations
 Only documents with "Pending" status can be deleted.
 Status updates are controlled by audit reviewers, not editable by
submitters.
  User Story 3: Validate Completion of Prerequisite Submissions
As an audit coordinator,
I want to check if all required prerequisite documents have been submitted,
So that I can flag missing submissions before initiating the audit.
 Screen Fields
 Checklist View:
o Required Document Types
o Submission Status (Yes/No)
o Submitted On
o Submitted By
 Dependencies
 Document requirements are based on audit type (e.g., Financial,
Operational).
 Audit cannot proceed if any required documents are missing.
 Validations
 Submission status should auto-update based on uploaded documents.
 "Proceed with Audit" button disabled until all required docs are marked as
submitted.

 User Story 4: Notify Users of Missing or Incorrect Submissions

As the system,
I want to send notifications if required documents are missing or rejected,
So that users can take timely corrective action.
 Screen Fields / Components
 Notification Module:
o Alert Banner in dashboard
o Email Notification
o Audit Submission Reminder Popup (Optional)
 Dependencies
 Tied to document review status.
  Must integrate with user profile/contact info.
 Validations
 Notifications must only trigger for required document types.
 Avoid duplicate notifications for the same document within 24 hours.

Audit Observation Details

 Epic: Audit Observation Details

 User Story 1: Add Audit Observation

As an auditor,
I want to log a new audit observation with detailed information,
So that findings can be documented, tracked, and addressed.
 Screen Fields
 Observation ID (Auto-generated – Read-only)
 Audit ID / Reference (Dropdown or Searchable – Required)
 Category (Dropdown – e.g., Compliance, Financial, Operational – Required)
 Observation Title (Text – Required)
 Description (Multiline Text – Required)
 Risk Rating (Dropdown – Low, Medium, High – Required)
 Impact (Multiline Text – Optional)
 Auditor Name (Auto-filled from user – Read-only)
 Observation Date (Date Picker – Default to current date – Required)
 Attachments (File upload – Optional; Accept PDF, DOCX, XLSX, PNG)
  Dependencies
 Audit ID must exist in the system and be active.
 Categories and risk ratings are pulled from admin-configured master data.
 Validations
 Mandatory fields: Audit ID, Category, Observation Title, Description, Risk
Rating, Date.
 Title must be unique within the same audit.
 Description must have a minimum of 50 characters.
 File size limit: 10MB per attachment.
 File types restricted to allowed formats.

 User Story 2: Edit Audit Observation

As an auditor,
I want to edit an existing observation that I logged,
So that I can correct or clarify the details before submission is locked.
 Screen Fields
(Same as Add Observation, fields are editable)
 Dependencies
 Observations can only be edited before review/approval.
 Only the original auditor or a supervisor can edit.
 Validations
 Same as Add Observation.
 Edit not allowed if observation status is “Finalized” or “Closed.”

 User Story 3: View Audit Observation Details

As an auditor or audit reviewer,
I want to view detailed information about each observation,
So that I can review findings or prepare follow-up actions.
 Screen Fields
 All fields from Add Observation, displayed in read-only format
 Observation Status (e.g., Draft, Submitted, Under Review, Finalized)
  Action Taken (If any – populated by corrective action flow)
 Review Comments (Optional – entered by reviewer)
 Dependencies
 Observation status determines which users can see the record (e.g., Draft
visible only to author).
 Validations
 Read-only mode must reflect the latest saved data.
 Only authorized users can view restricted observations.

 User Story 4: Review and Update Observation Status

As an audit supervisor or reviewer,
I want to change the status of an observation and provide feedback,
So that it reflects the current stage of review or follow-up.
 Screen Fields
 Observation ID (Read-only)
 Status Dropdown (Draft, Submitted, Under Review, Finalized, Rejected)
 Review Comments (Text – Required for status changes)
 Reviewed By (Auto-filled)
 Reviewed Date (Auto-filled)
 Dependencies
 Role-based access for status changes (only reviewer/supervisor).
 Status cannot be reverted from Finalized.
 Validations
 Review Comments required if status is changed.
 Status transitions must follow allowed path (e.g., Draft → Submitted →
Under Review → Finalized).
 Date and user fields must populate automatically on save.

 User Story 5: Search and Filter Audit Observations

As a user,
I want to search and filter audit observations by various parameters,
So that I can quickly find relevant entries for review or reporting.
 Screen Fields
 Search By: Observation Title / ID
 Filter By:
o Category
o Risk Rating
o Observation Status
o Audit ID
o Date Range
 Dependencies
 Filter options populated from observation metadata.
 Search requires index for performance on large datasets.
 Validations
 Search field must not be empty on submit.
 Date range should not exceed 2 years.
 At least one filter must be selected to avoid empty results.

Audit Observation Details having button Like save as a

draft,accept,Reject and Discard

 Epic: Audit Observation Workflow Management

 User Story 1: Save Observation as Draft

As an auditor,
I want to save the audit observation as a draft,
So that I can return later to complete and finalize the submission.
  Screen Fields
 Observation Title (Text – Required)
 Observation Description (Textarea – Optional in Draft)
 Audit Reference (Dropdown – Required)
 Category, Risk Rating (Optional in Draft)
 Attachments (Optional)
 Buttons: Save as Draft
 Dependencies
 Drafts are only visible to the author.
 System stores draft in "Draft" status.
 Validations
 Minimum field required: Observation Title and Audit Reference.
 No need to validate full content unless submitted.
 System generates a draft ID on save.

 User Story 2: Accept Observation (Review Approval)

As an audit reviewer,
I want to accept an observation after review,
So that it can be marked as finalized and moved to the next audit phase.
 Screen Fields
 Observation Details (Read-only)
 Reviewer Comments (Textarea – Required)
 Reviewer Name, Date (Auto-filled)
 Button: Accept
 Dependencies
 Only reviewers/supervisors can accept.
 Observation must be in “Submitted” or “Under Review” status.
 Validations
 Reviewer Comments must be filled before acceptance.
 Status updates to “Accepted” or “Finalized.”
  Audit observation becomes read-only for further edits.

 User Story 3: Reject Observation

As an audit reviewer,
I want to reject an observation with feedback,
So that the auditor can make necessary corrections.
 Screen Fields
 Observation Details (Read-only)
 Rejection Reason / Reviewer Comments (Textarea – Required)
 Button: Reject
 Dependencies
 Available only to reviewer roles.
 Status must be “Submitted” or “Under Review.”
 Validations
 Rejection Reason is mandatory.
 Status updates to “Rejected.”
 Observation becomes editable again by the author.

 User Story 4: Discard Draft Observation

As an auditor,
I want to discard a draft observation,
So that unwanted or mistakenly created entries are removed.
 Screen Fields
 Observation Title (Read-only)
 Confirmation Modal: “Are you sure you want to discard this draft?”
 Buttons: Discard, Cancel
 Dependencies
 Only applicable to observations in "Draft" status.
 Discard action should be irreversible and confirmed.
 Validations
 Only the creator can discard.
  Discard removes entry from the UI and database.

 Screen Action Buttons and Conditions Table

Enabled When
Button Visible To Required Fields Next Status
Status Is

Save as Any (except Title, Audit

Auditor Draft
Draft Finalized) Reference

Submitted / Finalized /
Accept Reviewer Reviewer Comments
Under Review Accepted

Submitted / Reviewer Comments

Reject Reviewer Rejected
Under Review (Rejection)

Auditor Deleted
Discard Draft Confirmation
(creator) (soft/hard)

 Optional Enhancements
 Auto Save Draft every 5 minutes.
 Audit Trail for all status changes.
 Visual status indicators (e.g., color tags for Draft, Rejected,
Finalized).
Would you like a process flowchart showing how these statuses and
actions connect?
A network error occurred. Please check your connection and try again. If
this issue persists please contact us through our help center at
help.openai.com.
Retry

 Epic: Manage Audit Observation Attachments

 User Story 1: Attach File to an Audit Observation

As an auditor,
I want to attach relevant supporting documents to an observation,
So that evidence and reference materials are available during audit
review.
 Screen Fields
 Attach File (Button)
 File Picker Modal:
o Select File (File picker – Required)
o File Description (Text – Optional)
o Upload Button
 Attached Files List:
o File Name
o Description
o Uploaded By
o Upload Date
o Actions: View / Download / Delete (if in Draft)
 Button: “Attach File”

 Dependencies
 Observation must exist (draft or submitted) before attaching.
 Only auditors or reviewers assigned to the observation can upload
files.
 File uploads linked to the observation ID.

 Validations
 Allowed file formats: .pdf, .docx, .xlsx, .jpg, .png.
 Maximum file size per upload: 10MB.
 Max total file size per observation: e.g., 50MB.
 File name should not duplicate existing file names for the same
observation.
 Only files in Draft or Rejected status can be deleted by the
uploader.
  Description character limit (optional): 250 characters.

 User Story 2: View Attached Files

As an auditor or reviewer,
I want to view or download attached files related to an observation,
So that I can examine supporting evidence during audit evaluation.
 Screen Fields
 Attached Files Section:
o File Name (as hyperlink)
o Description
o Uploaded By
o Uploaded Date
o Actions: View / Download
 Dependencies
 Observation ID is used to fetch attached files.
 Access is role-based: auditors, reviewers, and compliance officers
can view.
 Validations
 Access logs should capture file views/downloads (optional).
 If file is deleted, a log or audit trail should retain reference.

 User Story 3: Delete Attached File (Draft Only)

As the uploader,
I want to delete a mistakenly uploaded file before submission,
So that only relevant files are retained in the observation.
 Screen Fields
 Attached Files Table (Delete icon available)
 Confirmation Modal: “Are you sure you want to delete this file?”
 Buttons: Delete, Cancel
 Dependencies
 Deletion only allowed in "Draft" or "Rejected" status.
  Only the original uploader can delete the file.
 Validations
 Show warning if file is associated with a finalized observation.
 Log deletion activity with timestamp and user.

 Summary Table – Attach File Button Behavior

Enabled
Action Visible To Required Input Restrictions
When

File (mandatory),
Attach Draft / Auditor, File type & size
Description
File Submitted Reviewer constraints
(optional)

View / All with File must be

Any None
Download access available

Not allowed if status

Delete Draft / Uploader Confirmation
is Finalized or
File Rejected only required
Accepted

Respond to Audit Enquiries by CTO Circle Office

 Epic: Respond to Audit Enquiries by CTO Circle Office

 User Story 1: View Audit Enquiry Details

As a CTO Circle Office user,
I want to view the full details of the audit enquiry received,
So that I can prepare and submit an appropriate response.
 Screen Fields
 Enquiry ID (Read-only)
 Audit Reference Number (Read-only)
  Enquiry Description (Read-only)
 Date of Enquiry
 Priority Level (Low / Medium / High – Read-only)
 Attachments (Hyperlink to documents – View / Download)
 Status (Read-only – e.g., Open, Responded, Closed)
 Dependencies
 Enquiry details are fetched from the central audit system.
 Available only to assigned Circle Office users.
 Validations
 User must have valid access rights to view the enquiry.
 Audit Reference must be linked to an active audit.

 User Story 2: Prepare and Submit Response

As a CTO Circle Office user,
I want to prepare and submit a written response to an audit enquiry,
So that the audit team receives clarification or required information.
 Screen Fields
 Response Text (Textarea – Required)
 Upload Supporting Documents (Optional; PDF, DOCX, XLSX – Max size:
10MB per file)
 Response Date (Auto-filled)
 Responded By (Auto-filled)
 Buttons: Submit Response, Save as Draft
 Dependencies
 Enquiry must be in “Open” or “Pending Response” status.
 Only users assigned to the circle can respond.
 Validations
 Response Text must be minimum 100 characters.
 Allowed file formats and size limits enforced.
  Mandatory to attach documents if the audit enquiry specifically requests
documentation (configurable).
 Duplicate file names not allowed.
 Auto-save draft capability every X minutes (optional).

 User Story 3: Save Response as Draft

As a CTO Circle Office user,
I want to save my response as a draft,
So that I can complete it later without losing progress.
 Screen Fields
(Same as User Story 2)
 Dependencies
 Drafts are visible only to the author.
 Saved in "Draft" status.
 Validations
 No required fields enforced at draft stage except basic response intent (e.g.,
Response Text not empty).

 User Story 4: View Submitted Response and Receipt

As a CTO Circle Office user or auditor,
I want to view the response and the receipt confirmation,
So that I have a record of communication history and timestamps.
 Screen Fields
 Submitted Response (Read-only)
 Attachments (View/Download)
 Submission Timestamp
 Status: Submitted/Responded/Closed
 Button: View Receipt

 Button: View Receipt

 Opens PDF or modal showing:
 o Enquiry ID
o Response ID
o Responded By (Name, Designation)
o Submission Timestamp
o Document hash/checksum (optional for integrity)
o Signature or system acknowledgment

 Dependencies
 Response must be submitted to generate receipt.
 Receipt is auto-generated and stored on submission.
 Validations
 Receipt must be accessible only to authorized users.
 Show error if response not yet submitted or if receipt file is corrupted.

 Summary Table – Key Buttons and Their Conditions

Button Visible To Enabled When Validations/Rules

Submit Circle Office Enquiry status = Response text required; file optional
Response User Open unless flagged as mandatory

Save as Circle Office Anytime before

No strict validations; saves to “Draft”
Draft User submission

View Circle Office Response Receipt file or acknowledgment must

Receipt + Auditors submitted exist

Audit Report Preparation and Review Workflow

 Epic: Audit Report Preparation and Review Workflow

 ✅ User Story 1: Add Sections or Findings to the Audit Report

As an auditor,
I want to add new sections or findings to the audit report,
So that I can document audit observations, conclusions, and recommendations.
 Screen Fields
 Section Type (Dropdown – e.g., Introduction, Scope, Observations,
Recommendations – Required)
 Section Title (Text – Required)
 Section Content (Rich Text Editor – Required)
 Observation Reference (Optional – Links to observation ID)
 Attach File (Optional – .pdf, .docx, .xlsx)
 Buttons
 Add Section
 Dependencies
 Report must be in "Draft" or "Under Preparation" status.
 Audit must be active and in post-observation phase.
 Validations
 All required fields must be filled before adding.
 Section Title must be unique within the same report.
 Word count minimum: 100 characters in Content field.
 Attachment must not exceed 10MB per file.

 ❌ User Story 2: Remove Section from the Audit Report

As an auditor,
I want to remove a section from the audit report,
So that I can eliminate incorrect or outdated content.
 Screen Fields
 Section List (with checkbox or delete icon)
 Buttons
 Remove (for each section)
 Dependencies
 Only editable in Draft or Under Review status.
  Locked after report is approved.
 Validations
 Prompt confirmation before removal.
 Cannot remove the last remaining required section (e.g., Summary or
Conclusion).
 Audit trail should record section deletion.

 💾 User Story 3: Save Audit Report as Draft

As an auditor,
I want to save the current state of the audit report as a draft,
So that I can return later to complete or edit it.
 Screen Fields
 All current report content
 Report Status (Read-only)
 Buttons
 Save as Draft
 Dependencies
 Available in all editable phases.
 Auto-save logic every 5 minutes (optional enhancement).
 Validations
 No validations required to save as draft.
 System should notify user on successful save.

 ✅ User Story 4: Submit Audit Report for Approval

As an auditor,
I want to submit the audit report for review and approval,
So that it can be finalized and shared with stakeholders.
 Buttons
 Submit for Approval
 Dependencies
  All required sections (e.g., Executive Summary, Observations) must be
present.
 All linked observations must be marked as finalized.
 Validations
 Required sections must be completed.
 No section should have placeholder text (e.g., “TBD”).
 Submission locks editing unless rejected.

 ✔️User Story 5: Approve Audit Report

As a reviewer or audit supervisor,
I want to review and approve the submitted audit report,
So that it can be officially closed and published.
 Screen Fields
 Full report in read-only mode
 Reviewer Comments (Optional)
 Approver Name, Date (Auto-filled)
 Buttons
 Approve
 Dependencies
 Report must be in "Submitted" or "Under Review" status.
 Role-based access for approval.
 Validations
 Status changes to “Approved” and locks the report.
 Email notifications sent to stakeholders (optional).
 Reviewer Comments optional but logged if provided.

 ❌ User Story 6: Reject Audit Report

As a reviewer or audit supervisor,
I want to reject a submitted audit report with comments,
So that the auditor can revise and resubmit.
 Screen Fields
  Rejection Comments (Textarea – Required)
 Rejector Name, Date (Auto-filled)
 Buttons
 Reject
 Dependencies
 Report must be in “Submitted” or “Under Review” status.
 Validations
 Rejection comments required.
 Status changes to “Rejected,” enabling editing again.
 Notification triggered to the original author.

 🔘 Button Behavior Summary Table

Available In Next
Button Role Validations / Rules
Status Status

Draft, Under Required fields, unique title,

Add Section Auditor N/A
Preparation word count

Remove Draft, Under

Auditor Confirmation, audit trail N/A
Section Preparation

Any Editable
Save as Draft Auditor Minimal validation Draft
Phase

Submit for Required sections completed, Under

Auditor Draft
Approval valid observations Review

Review Optional comments, locks

Approve Under Review Approved
er report

Review Mandatory comment, unlocks

Reject Under Review Rejected
er editing

 Recording of Audit Observations

 ✅ User Story 1: Record a New Audit Observation

As an auditor,
I want to input and save details of an audit observation,
So that I can document audit findings for further action or review.
 Screen Fields
 Observation ID (Auto-generated – Read-only)
 Audit Reference (Dropdown or Searchable – Required)
 Observation Title (Text – Required)
 Detailed Description (Rich Text Editor – Required)
 Risk Rating (Dropdown – Low, Medium, High – Required)
 Category (Dropdown – e.g., Financial, Compliance – Required)
 Observation Date (Date Picker – Required)
 Observed By (Auto-filled – Read-only)
 Attachments (Optional – File Upload; PDF, DOCX, XLSX, JPG, PNG)
 Buttons
 Save
 Export to PDF
 Clear
 Close

 💾 User Story 2: Save Audit Observation

As an auditor,
I want to save the observation I entered,
So that I don’t lose my work and can review or edit it later.
 Button: Save
 Dependencies
 Available only if mandatory fields are filled.
 Saves in "Draft" or "Saved" status.
 Validations
 Required fields: Audit Reference, Title, Description, Risk Rating, Category,
Date.
 Minimum content length: 100 characters in the Description.
  File upload validations:
o Max file size: 10MB
o Valid formats: .pdf, .docx, .xlsx, .jpg, .png
 Duplicate titles under the same audit reference must be flagged.

 📄 User Story 3: Export Observation to PDF

As an auditor,
I want to export the audit observation as a PDF,
So that I can archive or share it with stakeholders.
 Button: Export to PDF
 Dependencies
 Observation must be saved before export is allowed.
 Validations
 Ensure all data is saved before export.
 PDF includes:
o Header with Observation ID, Date, and Auditor
o Full description and metadata
o Attached files (names listed, not embedded)
 Show error if observation is not yet saved.

 🧹 User Story 4: Clear All Fields

As an auditor,
I want to clear all the fields in the observation form,
So that I can restart entry from scratch if needed.
 Button: Clear
 Dependencies
 Only active in “New Entry” or “Draft” mode.
 Prompts user before clearing to avoid accidental loss.
 Validations
 Confirmation modal: “Are you sure you want to clear all entered data?”
  Action should not affect saved observations.

 ❌ User Story 5: Close Observation Entry Form

As an auditor,
I want to close the observation entry form,
So that I can exit the screen without saving further edits.
 Button: Close
 Dependencies
 Warn user if unsaved changes exist.
 Redirects user to Observation List or Dashboard.
 Validations
 If unsaved data exists, show confirmation modal:
o "Unsaved changes will be lost. Do you want to continue?"

 🔘 Button Functionality Matrix

Enabled
Button Function Validations / Notes
When

Save entered data to Mandatory Enforces all required field

Save
system fields filled validations

Export to Generate and download Prevents export if data isn’t

After save
PDF observation report saved; formats PDF properly

In draft or new
Clear Reset form fields Requires confirmation modal
entry

Warns user of unsaved changes

Close Exit form screen Any time
if applicable

Recording of Audit Observations

 Recording of Audit Observations

 ✅ User Story 1: Record a New Audit Observation

As an auditor,
I want to input and save details of an audit observation,
So that I can document audit findings for further action or review.
 Screen Fields
 Observation ID (Auto-generated – Read-only)
 Audit Reference (Dropdown or Searchable – Required)
 Observation Title (Text – Required)
 Detailed Description (Rich Text Editor – Required)
 Risk Rating (Dropdown – Low, Medium, High – Required)
 Category (Dropdown – e.g., Financial, Compliance – Required)
 Observation Date (Date Picker – Required)
 Observed By (Auto-filled – Read-only)
 Attachments (Optional – File Upload; PDF, DOCX, XLSX, JPG, PNG)
 Buttons
 Save
 Export to PDF
 Clear
 Close

 💾 User Story 2: Save Audit Observation

As an auditor,
I want to save the observation I entered,
So that I don’t lose my work and can review or edit it later.
 Button: Save
 Dependencies
 Available only if mandatory fields are filled.
 Saves in "Draft" or "Saved" status.
 Validations
 Required fields: Audit Reference, Title, Description, Risk Rating, Category,
Date.
 Minimum content length: 100 characters in the Description.
  File upload validations:
o Max file size: 10MB
o Valid formats: .pdf, .docx, .xlsx, .jpg, .png
 Duplicate titles under the same audit reference must be flagged.

 📄 User Story 3: Export Observation to PDF

As an auditor,
I want to export the audit observation as a PDF,
So that I can archive or share it with stakeholders.
 Button: Export to PDF
 Dependencies
 Observation must be saved before export is allowed.
 Validations
 Ensure all data is saved before export.
 PDF includes:
o Header with Observation ID, Date, and Auditor
o Full description and metadata
o Attached files (names listed, not embedded)
 Show error if observation is not yet saved.

 🧹 User Story 4: Clear All Fields

As an auditor,
I want to clear all the fields in the observation form,
So that I can restart entry from scratch if needed.
 Button: Clear
 Dependencies
 Only active in “New Entry” or “Draft” mode.
 Prompts user before clearing to avoid accidental loss.
 Validations
 Confirmation modal: “Are you sure you want to clear all entered data?”
  Action should not affect saved observations.

 ❌ User Story 5: Close Observation Entry Form

As an auditor,
I want to close the observation entry form,
So that I can exit the screen without saving further edits.
 Button: Close
 Dependencies
 Warn user if unsaved changes exist.
 Redirects user to Observation List or Dashboard.
 Validations
 If unsaved data exists, show confirmation modal:
o "Unsaved changes will be lost. Do you want to continue?"

 🔘 Button Functionality Matrix

Enabled
Button Function Validations / Notes
When

Save entered data to Mandatory Enforces all required field

Save
system fields filled validations

Export to Generate and download Prevents export if data isn’t

After save
PDF observation report saved; formats PDF properly

In draft or new
Clear Reset form fields Requires confirmation modal
entry

Warns user of unsaved changes

Close Exit form screen Any time
if applicable

Welcome Dashboard

 Epic: Dashboard Navigation and Functionality

  🧭 User Story 1: Access Main Dashboard View
As a logged-in user,
I want to see a personalized dashboard overview when I log in,
So that I can view important audit and financial information at a glance.
 Menu Option: Dashboard
 Screen Fields
 Welcome Message (e.g., “Welcome, [User Name]”)
 Summary Cards:
o Total Audits (This Year)
o Pending Reports
o Financial Health Score
o Notifications / Alerts
 Recent Activities (List)
 Quick Links (Buttons to Audit Report, Financial Overview)
 Dependencies
 User must be authenticated.
 Content is role-specific (e.g., auditor sees audits; finance manager sees
budgets).
 Validations
 Data fields should not be empty; show placeholders or messages like “No
data available.”
 Access control must apply to widgets based on user role.

 📄 User Story 2: Navigate to Audit Report Module

As an auditor or reviewer,
I want to access the Audit Report module from the dashboard menu,
So that I can create, review, or approve audit reports.
 Menu Option: Audit Report
 Screen Fields
 List of Reports:
o Report ID, Title, Status, Last Modified Date
 o Action Buttons: View, Edit, Approve
 Search and Filter (By Date, Status, Audit Type)
 Dependencies
 Only users with audit-related roles see this menu item.
 Status filters are dynamic (e.g., “Draft,” “Under Review,” “Finalized”).
 Validations
 Unauthorized users are redirected or shown access denied.
 Filters require valid input (e.g., valid date range).

 💰 User Story 3: Access Financial Overview

As a finance or audit user,
I want to view financial performance data and trends,
So that I can assess fiscal compliance and budget status.
 Menu Option: Financial Overview
 Screen Fields
 Budget vs Actuals (Bar/Line Chart)
 Quarterly Spending Breakdown
 Key Financial Metrics (e.g., Variance %, Forecast Accuracy)
 Download Report Button (PDF/Excel)
 Dependencies
 Financial data must be integrated with the reporting system.
 Role-based access must restrict this to finance/audit users.
 Validations
 Charts must display meaningful values; show “No data” if unavailable.
 Report download must validate export format and file size constraints.

 ⚙️User Story 4: Access and Modify Settings

As a user,
I want to update my profile settings, notification preferences, or password,
So that I can personalize my experience securely.
  Menu Option: Settings
 Screen Fields
 Profile Info (Name, Email – Read-only or Editable)
 Change Password (Old Password, New Password, Confirm)
 Notification Preferences (Checkboxes or Toggles)
 Save Changes Button
 Dependencies
 Profile fields are pre-populated from user database.
 Password updates require verification of the old password.
 Validations
 Email format must be valid.
 Password must meet complexity requirements (e.g., 8+ characters,
upper/lowercase, symbol).
 Notify user on successful update or error.

 🚪 User Story 5: Logout of the System

As a user,
I want to log out securely from the application,
So that my session ends and no unauthorized access occurs.
 Menu Option: Logout
 Dependencies
 Available to all authenticated users.
 Validations
 Prompt confirmation: “Are you sure you want to logout?”
 Clear session tokens and redirect to login screen.

 🔘 Menu Behavior Summary Table

Menu Item Visible To Key Fields or Actions Validations / Conditions

Summary widgets,
Dashboard All users Role-specific data visibility
activities, quick links
Menu Item Visible To Key Fields or Actions Validations / Conditions

Auditors, Report list, filters, Restricted by role and

Audit Report
Reviewers actions status

Financial Finance, Senior Charts, metrics, Charts must load only if

Overview Managers downloadable reports data is available

Profile management, Input format, password

Settings All users
password change strength

Confirmation required,
Logout All users Session end, redirect
session tokens cleared

Department Master Management in Audit System

 Epic: Department Master Management in Audit System

 🏢 User Story 1: Add a New Department (Entity)

As an admin user,
I want to add a new department to the audit system,
So that it can be used in audit reports, assignments, and workflows.
 Button: Add Entity
 Screen Fields
 Department Code (Text – Required, Unique)
 Department Name (Text – Required, Unique)
 Description (Textarea – Optional)
 Parent Department (Dropdown – Optional)
 Location (Text – Optional)
 Status (Active/Inactive – Default: Active)
 Dependencies
  Department Code and Name must not already exist.
 Parent Department must be from existing active departments.
 Location is optional but validated against master list if integrated.
 Validations
 Required: Department Code, Department Name
 Code and Name must be unique (case-insensitive)
 Max character limits: Code (10), Name (100), Description (500)
 No special characters allowed in Department Code

 ✏️User Story 2: Edit Existing Department

As an admin user,
I want to update the details of an existing department,
So that it reflects the latest organizational structure.
 Button: Edit Entity
 Screen Fields
(Same as Add, pre-filled with current data)
 Dependencies
 Entity must exist and be in "Active" or "Inactive" status (not archived).
 Only selected fields may be editable depending on usage (e.g., Code locked
if already referenced in audit records).
 Validations
 Same as Add, with additional check to ensure uniqueness if fields are
changed.
 Changes to name/code must be propagated to related modules (e.g., audit
logs, assignments).

 ❌ User Story 3: Delete a Department

As an admin user,
I want to delete a department from the master list,
So that irrelevant or incorrect entries are removed from the system.
 Button: Delete Entity
  Dependencies
 Only departments not referenced in any audit or user assignment can be
deleted.
 Entity must be in "Inactive" status to be eligible for deletion.
 Validations
 System must check if the department is referenced in:
o Past or ongoing audits
o User profiles
o Audit logs
 If referenced, system must show error: "Department cannot be deleted as it
is in use."

 User Story 4: Archive a Department

As an admin user,
I want to archive a department instead of deleting it,
So that it is retained for audit history but no longer used for new assignments.
 Button: Archive Entity
 Dependencies
 Can be applied to both active or inactive departments.
 Archived departments are hidden from dropdowns in other modules.
 Validations
 Show confirmation: “Archiving will prevent future use of this department.
Proceed?”
 Update status to “Archived.”
 Archived entries must remain viewable in reporting/export modules.

 📋 Entity Action Buttons – Summary Table

Actio Button Allowed User

Validations
n Name Status Role

Add
Add N/A Admin Unique Code & Name, mandatory fields
Entity
Actio Button Allowed User
Validations
n Name Status Role

Edit Active/ Field limits, prevent editing locked/linked

Edit Admin
Entity Inactive values

Delet Delete Inactive

Admin Cannot be referenced in audit, users, logs
e Entity only

Archiv Archive Active/ Archive confirmation, remove from

Admin
e Entity Inactive dropdowns but retain for audit references

 🔐 Additional Notes on Access & Integrity

 Only system administrators can access this module.
 All create/edit/delete/archive actions must be logged in an audit trail.
 Archived entities should not be permanently removed and should be
accessible in read-only mode for audit history.

Generate and Manage Audit Project

 Generate and Manage Audit Project

 📝 User Story 1: Generate Audit Project

As an audit manager,
I want to generate a new audit project,
So that I can assign tasks, set deadlines, and initiate the audit workflow.
 Button: Generate Project
 Screen Fields
 Project ID (Auto-generated – Read-only)
 Project Name (Text – Required)
 Audit Type (Dropdown – Financial, Compliance, Operational, etc. – Required)
 Start Date (Date Picker – Required)
  End Date (Date Picker – Required)
 Assigned Team (Dropdown – Multiple selection)
 Department (Dropdown – Required)
 Project Description (Textarea – Optional)
 Status (Dropdown – New, In Progress, Completed, Archived)
 Dependencies
 All mandatory fields must be filled before generation.
 Start Date cannot be later than End Date.
 Assigned Team and Department must be valid.
 Project cannot be generated without a defined department and team.
 Validations
 Start Date must be earlier than or equal to End Date.
 Project Name must be unique within the same department.
 All dates should adhere to organizational date formats (e.g., DD/MM/YYYY).
 Project Status should default to “New” upon creation.

 🔨 User Story 2: Create Ad-hoc Audit

As an auditor,
I want to create an ad-hoc audit under a new project,
So that I can handle special audits that arise unexpectedly.
 Button: Create Ad-hoc Audit
 Screen Fields
 Ad-hoc Audit ID (Auto-generated – Read-only)
 Project Name (Dropdown – Select from existing projects)
 Audit Title (Text – Required)
 Scope of Audit (Textarea – Required)
 Date of Audit (Date Picker – Required)
 Assigned Auditor (Dropdown – Multiple selection)
 Dependencies
 Only active projects can be selected.
  Assigned Auditor(s) must be users with the role of auditor.
 Audit Title must be unique within the selected project.
 Validations
 Scope of Audit must be at least 100 characters long.
 Assigned Auditor(s) must have no conflicts with other ongoing audits.
 Date must fall within the project’s start and end date.

 🔗 User Story 3: Integrate Audit Data

As an audit manager,
I want to integrate relevant data into the audit project from external systems,
So that I can pull necessary records and data for the audit.
 Button: Integrate
 Screen Fields
 Source System (Dropdown – e.g., ERP, CRM, Financial Systems)
 Data Type (Dropdown – Financial Data, Compliance Data, Operational Data)
 Integration Status (Read-only – e.g., Pending, Successful, Failed)
 Dependencies
 The external system must be connected and accessible.
 Relevant data type and source system must be selected.
 Validations
 Integration status should show success or failure based on connection.
 User should be notified if integration fails due to system issues.
 Data integration logs should be recorded for auditing.

 💾 User Story 4: Save Amendment to Audit Project

As an audit manager,
I want to save amendments made to an existing audit project,
So that I can track changes and update project details as necessary.
 Button: Save Amendment
 Screen Fields
 Project ID (Read-only)
  Updated Fields (Highlight changes)
 Reason for Amendment (Textarea – Required)
 Date of Amendment (Auto-filled)
 Dependencies
 The project must be in “In Progress” status.
 All fields that were amended should be tracked.
 Validations
 Reason for amendment must be provided.
 Audit team must acknowledge significant changes to scope or timeline.

 📩 User Story 5: Send Intimation about Audit Project

As an audit manager,
I want to send an intimation about the audit project to stakeholders,
So that everyone involved is notified about the project’s initiation.
 Button: Send Intimation
 Screen Fields
 Recipient(s) (Dropdown – Select from user list or custom email addresses)
 Subject (Auto-filled – e.g., “Audit Project Initiated: [Project Name]”)
 Body (Text – Predefined template, can be edited)
 Attachments (Optional – Upload supporting documents)
 Dependencies
 Recipient(s) must have valid email addresses.
 Body must contain project details by default.
 Validations
 Email address validation.
 Subject and body must not be empty.
 File size for attachments must not exceed 10MB.

 📤 User Story 6: Send Request for Information (RFI)

As an auditor,
I want to send a Request for Information (RFI) to relevant departments or teams,
So that I can gather necessary data for the audit process.
 Button: Send Request
 Screen Fields
 Recipient(s) (Dropdown – Select from department/team)
 Subject (Auto-filled – e.g., “RFI for Audit Project: [Project Name]”)
 RFI Details (Textarea – Required)
 Deadline (Date Picker – Required)
 Dependencies
 Recipient(s) must be part of the department or team involved in the audit.
 RFI details must be filled in.
 Validations
 Deadline must be set and within a reasonable range (e.g., 1-2 weeks).
 RFI details should not be empty or just a placeholder.
 Confirmation message when RFI is sent successfully.

 📢 User Story 7: Send Communication about Audit Project

As an audit manager,
I want to send a general communication about the audit project’s status or
updates to stakeholders,
So that all parties are kept informed.
 Button: Send Communication
 Screen Fields
 Recipient(s) (Dropdown – Select from user list or custom email addresses)
 Subject (Text – Required)
 Communication Body (Text – Required)
 Attachments (Optional)
 Dependencies
 Recipient(s) must have valid email addresses.
 Communication body must be filled out.
  Validations
 Email address validation.
 Subject and body must not be empty.
 Attachments, if included, must not exceed the file size limit (10MB).

 🔘 Button Action Summary Table

Button
Action Dependencies Validations
Name

All fields filled Unique Project Name, Valid

Generate
Generate Project (Project Name, Start Dates, Assigned Team and
Project
Date, etc.) Department

Active project
Create Ad-hoc Create Ad-hoc Unique Audit Title, Scope of
selected, auditor
Audit Audit Audit (min 100 characters)
assigned

External system
Integration success or
Integrate Integrate connected and
failure log
accessible

Reason for amendment

Save Save Project must be in
required, acknowledgment
Amendment Amendment “In Progress” status
of changes

Subject, body, and

Send Valid email
Send Intimation attachments (optional)
Intimation recipients
should be valid

Valid deadline (within

Send Request for RFI details and
Send Request reasonable range), RFI body
Information deadline required
cannot be empty

Send Subject, body, and

Send Valid email
Communicatio attachments (optional) must
Communication recipients
n be filled