34 KiB
RE Workflow Management – Not Templatized System Requirements Specifications 13 - Oct- 2025 Version 1. 0 Contents 1 System Overview & Problem Statement 2 Use case examples 3 Intended Audience 4 HiFi Wireframe,Goals and Expected Outcomes 5 Definitions and Acronyms 6 Flow of Application 6.1 High-Level Flow 7 System Features & Requirements 7.1 SSO Login 7.2 Dashboard 7.3 Side Navigation Menu 7.4 Create New Request – Template Selection 7.5 Create New Request – Basic Information 7.6 Create New Request – Approval Workflow 7.7 Create New Request – Participants & Access 7.8 Create New Request – Documents & Attachments 7.9 Create New Request – Review & Submit 7.10 Notifications 7.11 My Requests............................................................................................................. 7.12 Request Detail View 7.13 Request Detail view - Workflow 7.14 Request Detail view - Document 7.15 Request Detail view – Activity 7.16 Add Work Note 7.17 Add Approver & Spectator 7.18 Approve / Reject Request (Popup Window) 7.19 Closure Remark 8 Client Feedback Log (Post-Review Updates) 9 Non-Functional Requirements 10 Technology Matrix 11 Infra requirements & System Hygiene 12 Not in scope 1 System Overview & Problem Statement The Workflow Management System – Non-Templatized is a strategic digital initiative aimed at bringing structure, traceability, and efficiency to approval-based processes within Royal Enfield (RE).
Currently, most approvals and related communications are handled through emails , which often results in:
Unstructured and fragmented approval chains Loss of critical information due to scattered email threads Lack of visibility on approval status and ownership No defined Turnaround Time (TAT) , leading to delays and open-ended tasks These challenges collectively reduce process transparency , accountability , and decision efficiency across teams.
The proposed Workflow Management System – Non-Templatized will address these issues by providing a centralized, intuitive platform where:
Users can create requests , Define custom approval hierarchies , Set and monitor TATs , and Track real-time progress and final outcomes. All workflows will be captured, organized, and closed within a single system of record — ensuring clarity, control, and compliance throughout the process.
A thoughtfully designed User Interface (UI) will further enhance usability, adoption, and productivity , ensuring smooth navigation and a clean experience across departments.
2 Use case examples The following are some illustrative use cases for the Workflow Management System – Non- Templatized. These examples represent common approval scenarios within the organization, though additional use cases may be added over time as business needs evolve:
Approval for a new office location – involving multiple stakeholders such as facilities, finance, and leadership teams. Approval of unbudgeted incentives – requiring justification and review from HR and finance departments. Sponsorship or participation in an event – covering approvals from marketing, branding, and finance. Purchase of material from a new vendor – requiring validation, procurement, and financial approvals. These examples demonstrate the system’s flexibility to handle a wide range of approval workflows across departments.
3 Intended Audience The Workflow Management System – Non-Templatized will be accessible to all Royal Enfield (RE) employees who have valid SSO (Single Sign-On) credentials.
Initially, the system will be introduced in a pilot environment for selected users and departments. Based on feedback and performance, it will later be rolled out organization-wide.
The system will involve the following user roles :
Initiator – The user who creates and submits a workflow request. Participants – Individuals involved in the workflow at different stages or approval levels. Final Approver – The ultimate authority responsible for approving or rejecting the workflow request. Consultation – A user or subject matter expert whom the Final Approver may consult before making a final decision. Spectators – Users who are invited to view the workflow for information or transparency purposes, similar to how individuals are copied (CC’d) on email communications. This defined role structure ensures clarity, accountability, and collaboration throughout the workflow lifecycle.
4 HiFi Wireframe,Goals and Expected Outcomes Hi-Fi Wireframe: https://sway-dense-03017508.figma.site
The Workflow Management System – Non-Templatized is designed with a user-centric approach, supported by a high-fidelity (Hi-Fi) wireframe that visually represents the layout, navigation flow, and user interactions.
Through the implementation of this system, Royal Enfield (RE) aims to achieve the following measurable goals :
Centralization: Consolidate all approval workflows and related communications within a single unified platform. Transparency: Provide real-time visibility into each workflow’s stage, status, and assigned approvers. Accountability: Define clear ownership at every stage and maintain a complete audit trail of all user actions. Efficiency: Reduce approval cycle times by implementing TAT-based tracking , automated reminders , and smart notifications. Traceability: Maintain structured and retrievable records of all approvals to support easy reference, audit, and reporting. Scalability: Enable flexible configuration of non-templatized workflows that can adapt to various departmental and business needs. User Experience: Deliver a clean, intuitive, and responsive interface that enhances usability and encourages regular adoption. 5 Definitions and Acronyms Term Definition Workflow A sequence of tasks, approvals, or activities linked to a business process. Non- Templatized A flexible structure where each workflow can be created dynamically without a fixed format. Admin System user with full privileges. 6 Flow of Application This section describes the end-to-end flow of the Workflow Management – Non-Templatized application. It outlines how users interact with the system, how approvals move through different stages, and how data transitions between modules until final closure.
6.1 High-Level Flow Login (SSO Integration) o Users access the system via the RE SSO Bridge using their organizational credentials. o Upon successful authentication, users are redirected to the Dashboard. Dashboard & Navigation o The Dashboard provides a summary of pending, approved, and rejected requests. o The left Side Menu gives access to My Requests , Open Requests , Closed Requests , and Raise New Request. Creating a New Request o User clicks “Raise New Request” and chooses between: ▪ Custom Request – Create a flexible, non-templatized workflow. ▪ Existing Template – (Future scope) Use a predefined structure. o The user proceeds through a 6 - step wizard : ▪ Template Selection ▪ Basic Information ▪ Approval Workflow ▪ Participants & Access ▪ Documents & Attachments ▪ Review & Submit Defining Approval Workflow o The user configures approval levels dynamically , assigning approvers via @ tagging. o Each approver level has a defined TAT (in hours or days). o System calculates the total TAT by summing all levels. o TAT starts only when a request reaches that approver’s level. Adding Participants o User can add Spectators (view-only participants) who can comment but not approve. o Spectators receive notifications and see the request in read-only mode. Uploading Documents o User attaches supporting files (PDF, Word, Excel, PPT, or images) or links Google Docs/Sheets. o PDFs and images are previewable , while other formats can be downloaded. Submitting the Request o The user reviews all information in the Review & Submit step. o Once submitted, the request enters the Approval Workflow and notifies the first approver. Approval Process o Approvers receive a notification and can: ▪ Approve Request – Moves to the next level or closes if final approver. ▪ Reject Request – Sends remarks to the initiator and marks as closed. o Each action requires comments and remarks (mandatory). o TAT tracking is visible with color-coded status (Green = Within TAT, Yellow = Approaching Deadline, Red = Breached). o Auto-reminders are sent at configured thresholds (e.g., 80% TAT usage). Work Notes & Collaboration o Participants communicate via the Work Notes (Chat View). o Supports @mentions, file sharing, and reactions. o All discussions are stored chronologically and linked to the request. Activity Tracking o Every event — creation, comment, document upload, approval, rejection, or TAT alert — is captured in the Activity Tab with timestamps. Request Closure & Conclusion o After final approval, the request returns to the Initiator with AI-generated conclusion remarks. o The initiator reviews, optionally edits, and marks the request as closed. o The Conclusion Remark summarizing the workflow becomes part of the final record and appears under: ▪ My Requests (Approved) ▪ Open Requests ▪ Closed Requests Post-Closure Access & Sharing o Closed requests remain accessible to all participants and spectators. o Requests can be shared internally via Add Spectator ; download permissions apply only to Work Note attachments. o All actions and comments remain viewable for audit purposes. 7 System Features & Requirements Here, we describe the system features along with their respective Width and Depth to provide complete visibility of each requirement.
The Width defines the functional coverage of a feature — outlining what the feature does, its boundaries, use cases, and user interactions. It answers the question: “What scenarios and actions are covered by this feature?”
The Depth captures the operational and behavioral details — describing how the feature behaves through its logic, workflow, system responses, and edge-case handling. It answers the question: “How does the system execute and respond in these scenarios?”
7.1 SSO Login The system will integrate with the existing RE SSO Bridge to enable secure, seamless login for all authorized Royal Enfield employees. This ensures unified authentication, eliminating the need for separate credentials and maintaining compliance with RE’s security standards.
Width:
Integrates with the existing RE SSO Bridge for secure authentication. Allows access only to authorized Royal Enfield employees. Automatically retrieves user details ( name, employee ID, department ). Depth:
Uses token-based authentication and HTTPS for secure sessions. Handles session timeout and re-authentication per RE’s IT security policy. Dependency
SSO implementation guide and sample users are required. 7.2 Dashboard The Dashboard is an open element that is currently under discussion and will be finalized in later phases. It is expected to serve as a central view for users to monitor workflow status, pending approvals, and key metrics once its structure and content are defined.
7.3 Side Navigation Menu The Side Menu provides users with quick and consistent navigation across the application. It includes the following primary sections:
Dashboard: Overview of workflow activities, key metrics, and pending actions. My Requests: Displays all workflow requests created by the logged-in user. Open Requests: Lists all active or in-progress workflows requiring action. These may include requests initiated by or assigned to the logged-in user. Closed Requests: Shows all completed or approved workflows for reference. These may include requests created by or processed by the logged-in user. Raise New Request: Allows users to initiate and submit a new workflow request. Width:
Offers persistent navigation to Dashboard , My Requests , Open Requests , Closed Requests , and Raise New Request. Ensures consistent access throughout the system. Depth:
Implements active route highlighting and role-based visibility. Includes search, sort, and filter capabilities. Supports pagination and stable ID-based navigation to detail screens. 7.4 Create New Request – Template Selection This screen appears when the user clicks “Raise New Request.” It introduces a wizard-style navigation that guides users through the request creation process in sequential steps.
Custom Request (Non Templatized): Allows users to create a fully flexible workflow tailored to unique business needs.
To initiate the request flow, users must select “Custom Request.” The system then progresses step by step to capture all required details, ensuring clarity and completeness before submission.
Width:
Enables users to choose Custom Request (non-templatized) Displays wizard navigation with progress indicator. Depth:
In the current version, only Custom Request is enabled. Enforces mandatory selection before proceeding. Saves the chosen configuration as part of the workflow metadata. Activates after completion of wizard 7.5 Create New Request – Basic Information In this step, users outline the what, why, and how soon of their request, creating clarity for all participants involved in the approval process.
Users are required to enter:
Request Title: A short and descriptive title that summarizes the purpose of the request (e.g., Approval for new office location ). Detailed Description: A comprehensive explanation outlining the need, background, and expected outcome of the request. Priority Level: Selection between two options — o Express (Urgent): Includes calendar days in the TAT for faster processing. o Standard (Default): Includes working days in the TAT for regular processing. This step ensures that each request is well-defined, prioritized appropriately, and easily understood by all participants in the approval flow.
Width:
Captures core request details : o Request Title o Detailed Description o Priority Level – Express or Standard Depth:
Express: Uses calendar days in TAT calculation. Standard: Uses working days (default). Supports rich text formatting and pasted tables for better clarity. Support comprehensive email like formatting features , including table insertion, links, and text formatting such as bold and italics • 7.6 Create New Request – Approval Workflow In this step, users define the approval hierarchy and assign approvers for each level. The number of approvers is dynamically configurable based on the workflow’s complexity, with a maximum of ten levels supported.
Each approver’s Turnaround Time (TAT) must be defined individually in hours or days , depending on the urgency and scope of the request. The system automatically calculates the overall TAT by summing the TAT values of all approval levels.
An important behavior to note: the TAT timer for each participant starts only when the request reaches that level. Any delay at a previous level impacts only that approver’s TAT and does not affect subsequent ones.
Approvers can be tagged using the “@” symbol for easy identification, and each level’s configuration is summarized in real time under the Approval Flow Summary and TAT Summary sections for complete visibility. All the taggable users must be available in Active Directory (AD).
Width:
Allows defining a multi-level approval hierarchy with dynamic levels (up to 10). Each level includes a TAT (in hours or days). Approvers can be added using @ tagging. Depth:
System computes overall TAT by summing all levels. TAT timer starts only when a level becomes active — delays are isolated per level. Displays real-time Approval Flow Summary and TAT Summary for transparency. 7.7 Create New Request – Participants & Access The system allows adding Spectators — users who can view the workflow, add comments, and stay informed , but cannot approve or modify the request. Spectators can be added using the “@” tag , ensuring relevant stakeholders remain in the loop throughout the approval process.
Width:
Allows adding Spectators who can view and comment but cannot approve. Ensures visibility is restricted to participants and spectators only. Depth:
@ tagging used to add spectators easily. Spectators can add comments but have no edit or approval privileges. All changes are logged in the audit trail. 7.8 Create New Request – Documents & Attachments In this step, users can upload supporting documents and reference materials required for the workflow request. The system supports file formats such as PDF, Word, Excel, PowerPoint, and images , with a maximum upload size of 10 MB per file.
Users can drag and drop files directly into the upload area or use the Browse Files option to attach them.
PDF and image files can be previewed directly within the system. Other formats such as Word, Excel, or PowerPoint must be downloaded to view. Additionally, users can associate Google Docs and Google Sheets links as part of the request for collaborative reference. This feature ensures that all relevant documents are easily accessible and centralized for smoother review and approval.
Width:
Supports uploads of PDF, Word, Excel, PowerPoint, and image files (up to 10 MB each ). Allows linking of Google Docs and Google Sheets. Depth:
Provides inline preview for PDFs and images. Other formats must be downloaded to view. Stores file metadata (name, size, uploader, timestamp) for traceability. 7.9 Create New Request – Review & Submit This is the final step before the request enters the approval cycle. Users can review all captured details and ensure the accuracy of every input. The screen provides a structured summary of:
Request Overview: Displays key attributes such as Request Type, Priority, Workflow Type, and Request Title. Basic Information: Shows the request description and priority level entered earlier. Approval Workflow: Summarizes approval hierarchy, approvers, and defined TAT for each level. Participants & Access Control: Lists spectators, permissions, and comment settings. After verification, the user can either save the request as draft or click “Submit Request.” Once submitted, the workflow is activated, and notifications are automatically triggered to all assigned approvers and spectators.
This final step ensures each request is validated, structured, and complete before moving into execution.
Width:
Displays a complete summary of all entered details before submission: o Request Overview o Basic Information o Approval Workflow o Participants & Access Provides options to Save as Draft or Submit Request. Depth:
Performs final validation of all required fields. Computes total TAT and confirms approver hierarchy. Upon submission, sends notifications to approvers and spectators. 7.10 Notifications The system provides real-time notifications to keep users informed about workflow activities and pending actions. Notifications appear through a bell icon in the application header with a visible count of unread alerts.
Users receive updates such as:
Approval Reminders: Alerts when a request requires action or when its SLA/TAT is about to expire. Comments and Mentions: Notifications when someone adds a comment or tags the user in a workflow discussion. Each notification includes the request ID, message, and timestamp , allowing users to respond quickly and maintain timely workflow progress.
Width:
Centralized bell icon for all system alerts with unread count. Covers events like: o Approval assignments o SLA/TAT warnings o Comments or mentions o Status updates and closures Depth:
Delivers real-time in-app alerts (optional email integration). Each alert includes request ID, event type, user, and timestamp. Supports click navigation , read/unread states , and auto-cleanup of old alerts. Highlights high-priority or SLA-related notifications distinctly. 7.11 My Requests............................................................................................................. This screen allows users to view, track, and manage all workflow requests they have created within the system. It provides a consolidated view of request status, type, and progress for easy monitoring.
Width:
Displays all workflow requests submitted by the logged-in user , categorized as Total, In Progress, Approved, Rejected, and Draft. Each record shows critical details like Request Title, Priority (Express/Standard), Template Type, ID, Submission Date, and Current Level. Includes search and filter options for status and priority to quickly locate specific requests. Depth:
Each request card provides real-time tracking of the current approver , workflow level , and estimated completion date. Supports click navigation to open the detailed workflow view. Uses color-coded indicators for status identification (e.g., green for Approved, red for Rejected, yellow for Pending). Data refreshes upon page load when new requests are created or status updates occur, ensuring users always see the latest information. 7.12 Request Detail View This screen allows users to view, review, and act on individual workflow requests. It consolidates all key information — request details, approver actions, documents, and activity logs — into a single, interactive view for efficient decision-making.
Width:
Displays comprehensive request details , including title, description, initiator info, department, and contact details. Shows priority , TAT progress bar , and remaining time until the TAT expires. Provides a tab-based layout for: o Overview (request details and status) o Workflow (approval hierarchy and progress) o Documents (uploaded files) o Activity (comments and action log) Includes Quick Actions for approvers: Add Work Note, Add Approver, Add Spectator, Approve Request, and Reject Request. Lists Spectators with view-only access. Depth:
TAT progress bar dynamically updates based on elapsed and remaining time, color-coded for urgency (e.g., red for nearing expiry). Each action (approval, rejection, addition of approver/spectator) is logged in chronology within the activity tab for full traceability. Approvers can add comments or attachments before taking a decision. When the request reaches its final approver , the system allows closure and triggers an AI- generated conclusion remark summarizing the discussion (as per feedback notes). Page refresh updates data to reflect new comments, document uploads, or action changes. 7.13 Request Detail view - Workflow This screen provides a stage-by-stage view of the approval hierarchy within a specific workflow. It helps users and approvers track progress, review comments, and monitor TAT (Turnaround Time) performance at each approval level.
Width:
Displays each approver level , showing their name, designation, and TAT allocation. Shows real-time progress of approvals — Completed, Pending, Waiting, or Approaching Deadline. Includes TAT tracking with both elapsed and remaining time indicators. Highlights whether each step was completed within or beyond TAT. Lists approver comments for visibility and decision traceability. Auto-sends system-generated reminders when TAT thresholds are reached (e.g., 50% or 100% usage). Depth:
The system tracks individual TAT usage per approver level , ensuring delays are isolated to that stage only. TAT bars dynamically update color (e.g., green for Within TAT , yellow for Approaching Deadline , red for Breached ). Automatically sends TAT reminders based on configured thresholds — manual reminders are disabled as per design notes. Supports chronological logging of every action and comment, visible in the activity trail. Approvers can add notes, attach files, or escalate to higher levels if TAT expires without action. The final approver’s action closes the workflow , triggering summary notifications and AI- generated closure remarks. 7.14 Request Detail view - Document This tab provides a centralized space to view, manage, and access all documents attached to the workflow request. It ensures that approvers and spectators have visibility into all supporting materials necessary for informed decision-making.
Width:
Displays a list of uploaded documents associated with the request, showing: o File name , size , type/category , uploader , and timestamp. Supports standard file types such as PDF, Word, Excel, PowerPoint, and images. Allows users to preview or download files directly from the list. PDF and image files can be previewed inline ; other file types must be downloaded. Shows Quick Actions (e.g., Add Work Note, Add Approver, Add Spectator ) on the side panel for easy context switching. Depth:
Ensures document version integrity — if the same file name is uploaded again, the latest version is timestamped and saved separately. Records audit entries whenever a file is uploaded, deleted, or viewed. Provides metadata-based filtering (by file type, uploader, or date). Allows association of Google Docs and Google Sheets links for live collaboration. Refreshes file list upon page load or when a new document is uploaded , ensuring users always view the most updated set of attachments. 7.15 Request Detail view – Activity The Activity Tab serves as a chronological timeline that records every action, event, and update associated with a workflow request. It provides complete transparency for users to trace approvals, comments, document uploads, and system-generated notifications.
Width:
Displays a real-time activity timeline , including events such as: o Request creation o Approvals and rejections o Comments and notes added o Document uploads or deletions o System-generated TAT warnings or reminders Each activity entry shows: o Event type , description , timestamp , and initiator name. Differentiates between user actions (e.g., “Document Added”) and system events (e.g., “TAT Warning Sent”). Depth:
Activities are displayed in reverse chronological order , with the latest updates at the top. Color-coded event icons visually represent action types (e.g., green for approval, red for warnings). Automatically logs system-generated events such as TAT breach alerts or reminder dispatches. Records file uploads with metadata (file name, uploader, timestamp) for audit traceability. Ensures immutable logging — entries cannot be modified or deleted once created. Data refreshes upon page load , ensuring users always view the most updated timeline. 7.16 Add Work Note The Work Notes section enables participants to communicate and collaborate directly within a workflow request , ensuring that all discussions, clarifications, and shared files remain tied to the request record. This eliminates dependency on external email threads and improves traceability.
Width:
Displays a chronological chat-style conversation between workflow participants. Supports @mentions to tag users for feedback or updates. Allows file sharing within messages — uploaded files appear as inline attachments with download options. Each message displays the sender’s name, role, timestamp, and message content. Offers reaction options Includes a message composer at the bottom with: o Text box for entering messages (max 2000 characters). Automatically differentiates roles using colored badges (e.g., Initiator, Approver, Spectator ). Depth:
Messages are displayed in reverse chronological order , preserving a clear dialogue history. @mentions trigger system notifications to the tagged users. Each message is time-stamped, immutable, and stored as part of the request’s permanent record. Inline attachments are linked to the Documents Tab for centralized access. Priority tags (e.g., P – Priority ) appear inline when approvers mark messages as urgent. The chat interface automatically refreshes upon page load to reflect the latest messages and reactions. Chat data remains available throughout the workflow lifecycle and is archived upon closure. If there is a query at any level, user will mention it here and ask additional details. 7.17 Add Approver & Spectator This feature allows users to add new participants —either as Approvers or Spectators —to an ongoing workflow request. It provides flexibility for dynamically updating the workflow hierarchy or visibility list during the approval process.
Width:
Displays a modal popup titled “Add Approver” or “Add Spectator,” depending on the selected action. Provides a single input field for email address entry using the @ mention convention. Allows users to search and add participants by email or username. Includes two action buttons: Confirm (Add) and Cancel. Approvers: Gain the ability to review, approve, or reject the request. Spectators: Gain view-only access with the ability to comment and receive notifications. Both participant types receive automated notifications upon being added. Depth:
The Approver is inserted into the approval hierarchy in the defined sequence; the Spectator is added to the visibility list. All additions are recorded in the activity timeline for audit and transparency. Notifications are sent automatically to the newly added users via the system’s alert service. Approver TAT begins only when their stage becomes active in the workflow. The popup closes automatically upon successful addition, refreshing the request view to reflect the change. 7.18 Approve / Reject Request (Popup Window) This feature enables approvers to write their decision on a workflow request by either approving or rejecting it. It ensures that each decision is properly documented with remarks, creating a transparent and traceable approval trail.
Width:
Displays a modal window titled “Approve Request” or “Reject Request.” Shows key request information: o Request ID o Request Title o Action Type ( Approve or Reject ). Includes a mandatory Comments & Remarks field (up to 500 characters) for justifying the decision. Contains two buttons: o Approve Request / Reject Request — confirms and submits the decision. o Cancel — closes the modal without any action. Shows a contextual message: o Approval Confirmation for approval flow. o Rejection Guidelines encouraging constructive feedback. Depth:
Comments are mandatory for both approval and rejection to ensure context for future reference. Upon approval: o The system forwards the request to the next approver in the hierarchy or closes it if this is the final level. o If the final approver needs to consult with someone, he can use work note to specify that user, conclude and put the final closing remarks o Status updates automatically across all linked screens. Upon rejection: o The system sends a notification to the initiator along with rejection remarks. o The request is marked as “Rejected” and closed for further approval. All actions are logged in the Activity Tab with timestamps and user details. The popup automatically closes upon successful submission , refreshing the view to display the updated status. 7.19 Closure Remark This stage marks the final closure of a workflow request after all approvals are completed. Once the final approver submits their decision, the request automatically returns to the Initiator with an AI-generated Conclusion Remark summarizing the entire workflow journey.
The Initiator reviews, optionally edits, and marks the request as closed , completing the lifecycle.
Width:
Becomes available after the final approver’s action is recorded. Displays an AI-generated Conclusion Remark summarizing: o Discussion highlights and decision points o Key approval or rejection reasons o Notable attachments or supporting references Allows the Initiator to review and, if required, edit or enhance the remark before final closure. Once confirmed, the request status changes to “Closed” , and the final remark becomes part of the permanent workflow record. The Conclusion Remark is visible under: o My Requests (Approved) o Open Requests o Closed Requests If no remark exists, a placeholder message is displayed: “No conclusion remarks added yet. This section will highlight the main points or core conclusions of the request.” Depth:
The AI engine compiles the initial remark using inputs from Work Notes, Approver Comments, and Activity Logs. The remark generation occurs immediately after the final approval action is completed. The Initiator can make final edits or confirmations before closing the request. Once marked as closed, the remark becomes read-only for all other participants and spectators. The finalized conclusion is stored with workflow metadata for audit, compliance, and reporting. Closed requests retain full visibility of their conclusion remarks for traceability and knowledge retention. 8 Client Feedback Log (Post-Review Updates) This section tracks all client-driven changes, clarifications, or design validations received after initial wireframe or SRS review. Each point is linked to the relevant feature section for traceability.
Client Request / Feedback Response / Action Taken (Rohit) Linked
Feature Section 1 Remove the TAT modification option for approvers, allowing only during initiation. Accepted – TAT edit will be available only at request initiation, not at approval stages. Approval Workflow 2 Display Conclusion Remarks in My Requests for approved requests, consistent with Open and Closed Requests. Agreed – Will be implemented during development. To align with design limitation noted in section 6.20. My Requests, Conclusion Remark 3 Need to see how conclusion workflow works ; final approver should have ability to enter conclusion. Confirmed – After final approval, request returns to initiator with AI- generated comments for review/edit before closure. Conclusion Remark 4 Add restrictive view for sharing approved requests with non- participants. Accepted – To be managed via Work Notes option with permission control. Work Notes 5 Clarify sharing and download permissions for requests. Approved – Requests can be shared internally using Add Spectator. Download option will be enabled for Work Notes attachments only. Add Participant, Work Notes 9 Non-Functional Requirements Category Requirement Performance Average response time < 3 seconds for standard operations. Scalability Should scale horizontally on GCP. Security JWT tokens, encrypted passwords, HTTPS enforced. Usability Intuitive UI, consistent icons, and simple navigation. Reliability 99% uptime target. Backup & Recovery Daily database backup and weekly full snapshot. Compliance Follows RE IT data privacy guidelines. 10 Technology Matrix Component Specification Database PGSQL (Managed or local instance) Application Stack Node.js (Backend) + React.js (Frontend) Authentication RE SSO Bridge 11 Infra requirements & System Hygiene Component Specification Environment QA / Testing
of Virtual Machines (VMs) 1
CPU Configuration 4 - Core Memory (RAM) 16 GB Disk Size 500 GB Operating System Ubuntu 24.04 LTS Storage Type Cloud Backup and Recovery
Daily incremental and weekly full backups. Restore process must not exceed 2 hours. 12 Not in scope Anything which comes beyond the scope defined above in terms of Width and depth