clarification file added
This commit is contained in:
parent
2fd66a1c59
commit
0b77581503
471
RE_CRITICAL_FLOW_QUESTIONS_KICKOFF.md
Normal file
471
RE_CRITICAL_FLOW_QUESTIONS_KICKOFF.md
Normal file
@ -0,0 +1,471 @@
|
||||
# RE Workflow - CRITICAL Flow Questions for Kickoff
|
||||
**Must Be Answered Before Development Starts**
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 1: REQUEST SUBMISSION FLOW
|
||||
|
||||
### **Q1. What happens IMMEDIATELY after "Submit Request" button is clicked?**
|
||||
|
||||
**From SRS:** "Once submitted, the request enters the Approval Workflow and notifies the first approver."
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
- [ ] Does request go DIRECTLY to Level 1 approver, or is there a review/validation step?
|
||||
- [ ] Can initiator cancel/recall request after submission but before any approver acts?
|
||||
- [ ] Is request immediately visible to ALL approvers, or ONLY Level 1?
|
||||
- [ ] Can initiator edit request after submission? (Before any approvals)
|
||||
|
||||
**Why Critical:** Affects database state, notification triggers, and user expectations.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 2: APPROVAL REJECTION FLOW
|
||||
|
||||
### **Q2. When approver REJECTS - what EXACTLY happens to the request?**
|
||||
|
||||
**From SRS:** "Reject Request – Sends remarks to the initiator and marks as closed."
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
- [ ] **Option A:** Request permanently CLOSED (cannot be reopened)?
|
||||
- [ ] **Option B:** Request goes back to initiator as DRAFT (can modify and resubmit)?
|
||||
- [ ] **Option C:** Request goes back to PREVIOUS level for reconsideration?
|
||||
- [ ] **Option D:** Request CANCELLED (like it never existed)?
|
||||
|
||||
**If rejected at Level 3 (out of 5 levels):**
|
||||
- Do Level 4 and 5 approvers see it was rejected?
|
||||
- Or does it just disappear from their pending list?
|
||||
|
||||
**Why Critical:** Affects entire workflow state machine and database design.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 3: FINAL APPROVAL & CLOSURE SEQUENCE
|
||||
|
||||
### **Q3. After FINAL approver approves - what is the exact closure sequence?**
|
||||
|
||||
**From SRS:** "After final approval, the request returns to the Initiator with AI-generated conclusion remarks."
|
||||
|
||||
**CRITICAL SEQUENCE QUESTIONS:**
|
||||
|
||||
**Step 1:** Final approver clicks "Approve" → What happens?
|
||||
- [ ] Request status changes to "Approved" immediately?
|
||||
- [ ] Or status is "Pending Closure" until initiator acts?
|
||||
|
||||
**Step 2:** AI generates conclusion remarks → When?
|
||||
- [ ] Immediately after final approval?
|
||||
- [ ] Or when initiator opens the request?
|
||||
|
||||
**Step 3:** Request "returns to initiator" → How?
|
||||
- [ ] Initiator gets notification to "close" the request?
|
||||
- [ ] Or it just appears in their "Approved" list?
|
||||
|
||||
**Step 4:** Initiator must act → Required or optional?
|
||||
- [ ] **Option A:** Initiator MUST review and click "Close" (workflow not complete until then)?
|
||||
- [ ] **Option B:** Auto-closed, initiator can OPTIONALLY edit conclusion?
|
||||
|
||||
**Why Critical:** Affects workflow completion logic and user responsibilities.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 4: TAT CALCULATION ACROSS LEVELS
|
||||
|
||||
### **Q4. How does TAT work when request moves between levels?**
|
||||
|
||||
**From SRS:** "TAT starts only when a request reaches that approver's level."
|
||||
|
||||
**CRITICAL SCENARIO:**
|
||||
|
||||
```
|
||||
Request Flow:
|
||||
- Level 1: 2 days TAT → Takes 3 days (1 day overdue)
|
||||
- Level 2: 1 day TAT → Takes 1 day (on time)
|
||||
- Level 3: 2 days TAT → Takes 2 days (on time)
|
||||
```
|
||||
|
||||
**QUESTIONS:**
|
||||
- [ ] **Total TAT:** Is it 5 days (2+1+2) or 6 days (3+1+2 actual)?
|
||||
- [ ] **Reporting:** Does Level 1 delay affect overall TAT status?
|
||||
- [ ] **Visibility:** Does Level 2 approver see that Level 1 was late?
|
||||
- [ ] **Level 1 TAT breach:** Who gets notified? (Initiator, Manager, Admin?)
|
||||
|
||||
**Why Critical:** Affects TAT calculation logic, database schema, and reporting.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 5: WORK NOTES vs APPROVAL COMMENTS
|
||||
|
||||
### **Q5. What's the difference between Work Notes and Approval Comments?**
|
||||
|
||||
**From SRS:**
|
||||
- "Each action requires comments and remarks (mandatory)" - Approval Comments
|
||||
- "Participants communicate via the Work Notes (Chat View)" - Work Notes
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**Approval Comments (when clicking Approve/Reject):**
|
||||
- [ ] Visible to everyone or only certain roles?
|
||||
- [ ] Can be edited after posting?
|
||||
- [ ] Part of official audit trail?
|
||||
|
||||
**Work Notes (ongoing discussion):**
|
||||
- [ ] Can be added ANYTIME during workflow (before approvals)?
|
||||
- [ ] Visible to all participants immediately?
|
||||
- [ ] Are Work Notes considered when approver makes decision?
|
||||
|
||||
**Scenario:** Approver wants clarification before approving
|
||||
- Should they use Work Notes to ask questions?
|
||||
- Or use "Send Back" action (if it exists)?
|
||||
- Or reject with comment "need more info"?
|
||||
|
||||
**Why Critical:** Affects UI design and user behavior expectations.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 6: SPECTATOR ROLE & PERMISSIONS
|
||||
|
||||
### **Q6. What EXACTLY can spectators do vs not do?**
|
||||
|
||||
**From SRS:** "Spectators (view-only participants) who can comment but not approve."
|
||||
|
||||
**CRITICAL PERMISSION QUESTIONS:**
|
||||
|
||||
**Can Spectators:**
|
||||
- [ ] Add Work Notes / Comments? (**SRS says YES "can comment"**)
|
||||
- [ ] Upload documents/files?
|
||||
- [ ] @mention other users?
|
||||
- [ ] Add more spectators?
|
||||
- [ ] See approval comments from approvers?
|
||||
- [ ] See Activity log (all actions)?
|
||||
- [ ] Download documents?
|
||||
|
||||
**Can Spectators be added:**
|
||||
- [ ] Only during request creation (Step 4)?
|
||||
- [ ] Anytime during workflow (by initiator or approver)?
|
||||
- [ ] Even after request is closed?
|
||||
|
||||
**Why Critical:** Affects access control, UI rendering, and feature availability.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 7: ACTIVITY LOG vs WORK NOTES
|
||||
|
||||
### **Q7. Activity Tab vs Work Notes - what goes where?**
|
||||
|
||||
**From SRS:**
|
||||
- "Activity Tab" - Every event captured with timestamps
|
||||
- "Work Notes" - Chat view for collaboration
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**Activity Tab shows:**
|
||||
- [ ] System events ONLY (request created, approved, TAT breach)?
|
||||
- [ ] System events + Work Notes messages?
|
||||
- [ ] System events + Approval comments?
|
||||
- [ ] Everything (all-in-one timeline)?
|
||||
|
||||
**Work Notes shows:**
|
||||
- [ ] Only manual messages from users?
|
||||
- [ ] Messages + file uploads?
|
||||
- [ ] Messages + @mentions + reactions?
|
||||
|
||||
**Scenario:** User adds a comment via Work Notes
|
||||
- Does it appear in Activity Tab too?
|
||||
- Or only in Work Notes section?
|
||||
|
||||
**Why Critical:** Affects data modeling and UI tab content.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 8: DOCUMENT UPLOAD TIMING
|
||||
|
||||
### **Q8. When can documents be uploaded - only during creation or anytime?**
|
||||
|
||||
**From SRS:** "Step 5: Documents & Attachments" + "Work Notes supports file sharing"
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**During Request Creation (Step 5):**
|
||||
- [ ] Initiator uploads supporting documents
|
||||
- [ ] Are these the ONLY "official" documents?
|
||||
|
||||
**After Submission:**
|
||||
- [ ] Can initiator add more documents? (If yes, until when?)
|
||||
- [ ] Can approvers add documents? (E.g., approval memos, signatures?)
|
||||
- [ ] Can spectators add documents?
|
||||
|
||||
**Via Work Notes:**
|
||||
- [ ] Files attached in Work Notes - are they "official" documents?
|
||||
- [ ] Or just "discussion" attachments?
|
||||
- [ ] Do they appear in Documents Tab or only Work Notes?
|
||||
|
||||
**Why Critical:** Affects document versioning, storage structure, and permissions.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 9: OPEN REQUESTS vs CLOSED REQUESTS
|
||||
|
||||
### **Q9. What determines if request appears in "Open" vs "Closed" lists?**
|
||||
|
||||
**From SRS:** Side menu has "Open Requests" and "Closed Requests"
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**"Open Requests" shows:**
|
||||
- [ ] All In Progress requests (not yet fully approved)?
|
||||
- [ ] Only requests where I'm the ACTIVE approver?
|
||||
- [ ] Requests I initiated that are pending?
|
||||
- [ ] Requests I'm spectating that are in progress?
|
||||
|
||||
**"Closed Requests" shows:**
|
||||
- [ ] Approved + Rejected requests?
|
||||
- [ ] Only Approved requests?
|
||||
- [ ] Requests where I was involved (initiator/approver/spectator)?
|
||||
|
||||
**Scenario:** Level 1 approves, moves to Level 2
|
||||
- Does Level 1 still see it in "Open Requests"?
|
||||
- Or does it move to "Closed Requests" for Level 1?
|
||||
- Or moves to a "Completed Actions" section?
|
||||
|
||||
**Why Critical:** Affects navigation, filtering logic, and user workflow visibility.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 10: MY REQUESTS - STATUS CATEGORIES
|
||||
|
||||
### **Q10. In "My Requests" screen - what are ALL possible statuses?**
|
||||
|
||||
**From SRS:** "Categorized as Total, In Progress, Approved, Rejected, and Draft."
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**"In Progress" means:**
|
||||
- [ ] Submitted, waiting for approvals?
|
||||
- [ ] Or also includes "Pending Closure" (final approved, waiting for initiator to close)?
|
||||
|
||||
**"Approved" means:**
|
||||
- [ ] Final approval received + initiator closed it?
|
||||
- [ ] Or just final approval (even if not closed yet)?
|
||||
|
||||
**Missing Status?**
|
||||
- [ ] "Pending Closure" - Final approved, waiting for initiator action?
|
||||
- [ ] "Cancelled" - If initiator recalls request?
|
||||
|
||||
**Status Transitions:**
|
||||
```
|
||||
Draft → In Progress → Approved → Closed?
|
||||
↘ Cancelled
|
||||
↘ Rejected
|
||||
```
|
||||
|
||||
**Why Critical:** Affects status state machine and database enum values.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 11: POST-CLOSURE ACTIONS
|
||||
|
||||
### **Q11. After request is "Closed" - what actions are still possible?**
|
||||
|
||||
**From SRS:** "Closed requests remain accessible to all participants and spectators."
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**Can users still:**
|
||||
- [ ] Add Work Notes / Comments? (Continue discussion?)
|
||||
- [ ] Upload documents?
|
||||
- [ ] Add new spectators?
|
||||
- [ ] Edit conclusion remarks?
|
||||
- [ ] View all history (Activity + Work Notes)?
|
||||
- [ ] Download documents?
|
||||
|
||||
**Can Closed request be:**
|
||||
- [ ] Reopened (moved back to In Progress)?
|
||||
- [ ] Archived (moved to separate storage)?
|
||||
- [ ] Deleted (by initiator or admin)?
|
||||
|
||||
**Why Critical:** Affects immutability rules and audit compliance.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 12: PARALLEL WORKFLOWS
|
||||
|
||||
### **Q12. Can same approver have multiple roles in one workflow?**
|
||||
|
||||
**From SRS:** Up to 10 approval levels can be defined.
|
||||
|
||||
**CRITICAL SCENARIOS:**
|
||||
|
||||
**Scenario A:** Same person at multiple levels
|
||||
- Level 1: John Smith
|
||||
- Level 3: John Smith
|
||||
- Is this ALLOWED or BLOCKED?
|
||||
|
||||
**Scenario B:** Initiator as Approver
|
||||
- Initiator: John Smith
|
||||
- Level 2 Approver: John Smith
|
||||
- Should system warn: "You cannot approve your own request"?
|
||||
|
||||
**Scenario C:** Approver as Spectator
|
||||
- Level 2 Approver: John Smith
|
||||
- Also added as Spectator
|
||||
- Is this redundant or okay?
|
||||
|
||||
**Why Critical:** Affects validation rules and conflict detection.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 13: PRIORITY (EXPRESS vs STANDARD)
|
||||
|
||||
### **Q13. Does Priority affect anything OTHER than TAT calculation?**
|
||||
|
||||
**From SRS:** "Express (calendar days) vs Standard (working days)"
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**Does Priority affect:**
|
||||
- [ ] UI display (badge, color, sorting)?
|
||||
- [ ] Notification urgency (Express gets immediate, Standard batched)?
|
||||
- [ ] Approver assignment (Express can go to senior approvers only)?
|
||||
- [ ] Reminder frequency (Express reminded more often)?
|
||||
- [ ] Search/filter options?
|
||||
|
||||
**Can Priority be changed:**
|
||||
- [ ] By initiator before submission?
|
||||
- [ ] By approver during workflow (escalate to Express)?
|
||||
- [ ] Or fixed once set during creation?
|
||||
|
||||
**Why Critical:** Affects business rules and notification design.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 14: 6-STEP WIZARD NAVIGATION
|
||||
|
||||
### **Q14. In the 6-step wizard - can user go back/forward freely?**
|
||||
|
||||
**From SRS:** "The user proceeds through a 6-step wizard"
|
||||
|
||||
**CRITICAL QUESTIONS:**
|
||||
|
||||
**Navigation Rules:**
|
||||
- [ ] Must complete Step 1 before going to Step 2? (Sequential)
|
||||
- [ ] Or can jump to any step? (Free navigation)
|
||||
- [ ] Can go back to Step 2 from Step 5? (With data saved?)
|
||||
|
||||
**Data Persistence:**
|
||||
- [ ] Data saved only when clicking "Save as Draft"?
|
||||
- [ ] Or auto-saved when moving between steps?
|
||||
|
||||
**Mandatory Steps:**
|
||||
- [ ] Must complete ALL 6 steps before "Submit" button appears?
|
||||
- [ ] Or can skip optional steps (e.g., Documents, Spectators)?
|
||||
|
||||
**Scenario:** User fills Step 1-3, closes browser
|
||||
- Data lost or auto-saved as draft?
|
||||
|
||||
**Why Critical:** Affects wizard component logic and draft handling.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 🔴 SECTION 15: APPROVAL COMMENTS - MANDATORY RULES
|
||||
|
||||
### **Q15. Comments/Remarks mandatory for BOTH Approve AND Reject?**
|
||||
|
||||
**From SRS:** "Each action requires comments and remarks (mandatory)."
|
||||
|
||||
**CRITICAL CLARIFICATION:**
|
||||
|
||||
**Mandatory Comments for:**
|
||||
- [ ] **Approve:** YES - Must explain why approving
|
||||
- [ ] **Reject:** YES - Must explain why rejecting
|
||||
- [ ] Both require same min/max character limit?
|
||||
|
||||
**Comment Field:**
|
||||
- [ ] Plain text only?
|
||||
- [ ] Rich text (bold, bullets)?
|
||||
- [ ] File attachments allowed with comments?
|
||||
- [ ] Character limit: 500 mentioned for Reject, what about Approve?
|
||||
|
||||
**Scenario:** Approver tries to approve without comment
|
||||
- Block action with error?
|
||||
- Or just show warning (can proceed)?
|
||||
|
||||
**Why Critical:** Affects validation rules and UI behavior.
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 📋 SUMMARY: TOP 15 CRITICAL FLOW DECISIONS
|
||||
|
||||
### **Blockers (MUST decide before development):**
|
||||
1. ✅ **Rejection behavior** - Goes to draft, closed, or previous level?
|
||||
2. ✅ **Closure sequence** - Who closes? Initiator or auto-closed?
|
||||
3. ✅ **TAT across levels** - How to handle delays?
|
||||
4. ✅ **Request status state machine** - All possible statuses and transitions?
|
||||
5. ✅ **Post-closure actions** - Can users add comments after closing?
|
||||
|
||||
### **High Priority (Week 1):**
|
||||
6. ✅ **Spectator permissions** - Exactly what can they do?
|
||||
7. ✅ **Activity vs Work Notes** - What goes where?
|
||||
8. ✅ **Document upload timing** - Only at creation or anytime?
|
||||
9. ✅ **Open vs Closed lists** - Filter logic?
|
||||
10. ✅ **Duplicate roles** - Same person in multiple roles?
|
||||
|
||||
### **Medium Priority (Week 2):**
|
||||
11. ✅ **Priority impact** - Affects more than TAT?
|
||||
12. ✅ **Wizard navigation** - Sequential or free?
|
||||
13. ✅ **Comments mandatory** - For both approve and reject?
|
||||
14. ✅ **Work Notes vs Approval Comments** - Difference?
|
||||
15. ✅ **Submit flow** - Immediate to approver or validation?
|
||||
|
||||
---
|
||||
|
||||
## ✅ ACTION ITEMS FOR KICKOFF MEETING
|
||||
|
||||
**Bring this document to the meeting with stakeholders.**
|
||||
|
||||
**Agenda Item: Workflow Flow Decisions (45 minutes)**
|
||||
|
||||
1. **Rejection Flow** (10 mins) - Decide: Draft, Closed, or Back?
|
||||
2. **Closure Sequence** (10 mins) - Decide: Auto or Manual?
|
||||
3. **TAT Calculation** (10 mins) - Decide: How to handle delays?
|
||||
4. **Status State Machine** (10 mins) - Decide: All statuses and transitions?
|
||||
5. **Spectator Permissions** (5 mins) - Decide: What they can/cannot do?
|
||||
|
||||
**Expected Outcome:** Clear decisions on all 15 questions, documented and signed off.
|
||||
|
||||
---
|
||||
|
||||
**Document Owner:** Development Team Lead
|
||||
**Priority:** 🔴 CRITICAL - Affects core workflow logic
|
||||
**Status:** ⚠️ AWAITING DECISIONS
|
||||
**Impact:** Cannot design database schema or state machines without these answers
|
||||
|
||||
|
||||
509
RE_EXECUTIVE_SUMMARY_KICKOFF.md
Normal file
509
RE_EXECUTIVE_SUMMARY_KICKOFF.md
Normal file
@ -0,0 +1,509 @@
|
||||
# RE Workflow Management System - Executive Summary for Kickoff
|
||||
**Non-Templatized Approval Workflows**
|
||||
**Date:** October 17, 2025
|
||||
**Meeting Purpose:** Finalize Technical Approach & Resolve Conflicts Before Development
|
||||
|
||||
---
|
||||
|
||||
## 📊 Document Comparison Overview
|
||||
|
||||
We have reviewed two key documents for this project:
|
||||
|
||||
| Document | Focus | Date | Status |
|
||||
|----------|-------|------|--------|
|
||||
| **Streamlined Approvals SRS** | Detailed requirements for non-templatized workflows | Oct 13, 2025 | ✅ Complete |
|
||||
| **BPM Platform Proposal** | Technical approach for multiple RE projects | Earlier | ⚠️ Partial conflict |
|
||||
|
||||
---
|
||||
|
||||
## 🚨 CRITICAL: 3 Major Conflicts Requiring Immediate Decision
|
||||
|
||||
### **Conflict #1: Frontend Technology**
|
||||
|
||||
| Source | Technology | Pros | Cons |
|
||||
|--------|-----------|------|------|
|
||||
| **SRS** | React.js | Flexible, large community | Need to build routing, SSR manually |
|
||||
| **Proposal** | Next.js | Built-in SSR, routing, SEO, faster | Slightly steeper learning curve |
|
||||
|
||||
**✅ RECOMMENDATION: Next.js**
|
||||
- Better performance out of the box
|
||||
- Modern enterprise standard
|
||||
- Built-in features save development time
|
||||
|
||||
**👉 DECISION REQUIRED:** [ ] React.js [ ] Next.js
|
||||
|
||||
---
|
||||
|
||||
### **Conflict #2: Database**
|
||||
|
||||
| Source | Technology | Best For | Concern |
|
||||
|--------|-----------|----------|---------|
|
||||
| **SRS** | PostgreSQL | Structured data, ACID transactions | Need proper schema design |
|
||||
| **Proposal** | MongoDB | Flexible schema, rapid changes | Eventual consistency, complex queries harder |
|
||||
|
||||
**✅ RECOMMENDATION: PostgreSQL**
|
||||
- Approval workflows need ACID compliance
|
||||
- Multi-level hierarchy requires relational structure
|
||||
- TAT tracking and audit trails need data integrity
|
||||
- User roles are structured data
|
||||
|
||||
**👉 DECISION REQUIRED:** [ ] PostgreSQL [ ] MongoDB
|
||||
|
||||
---
|
||||
|
||||
### **Conflict #3: BPM Platform vs Custom Development**
|
||||
|
||||
| Approach | Description | Pros | Cons |
|
||||
|----------|-------------|------|------|
|
||||
| **BPM Platform** (Camunda/Newgen) | Use existing workflow engine | Pre-built features, visual designer | Licensing cost, learning curve, less UI flexibility |
|
||||
| **Custom Development** | Build from scratch | Full control, exact Figma match, no licensing | More dev time, need to build workflow engine |
|
||||
|
||||
**✅ RECOMMENDATION: Custom Development**
|
||||
- SRS requires "non-templatized" workflows (BPM is better for templates)
|
||||
- Highly customized UI requirements (Figma designs)
|
||||
- Dynamic approval levels (1-10) easier to build custom
|
||||
- No licensing costs
|
||||
|
||||
**👉 DECISION REQUIRED:** [ ] BPM Platform [ ] Custom
|
||||
|
||||
---
|
||||
|
||||
## ✅ What's CONFIRMED & Aligned
|
||||
|
||||
Both documents agree on:
|
||||
|
||||
| Component | Technology | Status |
|
||||
|-----------|-----------|--------|
|
||||
| **Backend** | Node.js | ✅ Confirmed |
|
||||
| **Authentication** | SSO with Active Directory | ✅ Confirmed |
|
||||
| **File Storage** | Cloud storage (GCS) | ✅ Confirmed |
|
||||
| **Security** | JWT, SSL, HTTPS | ✅ Confirmed |
|
||||
| **Infrastructure** | 1 VM, 4-Core, 16GB, Ubuntu 24.04 | ✅ Confirmed |
|
||||
| **Approval Pattern** | Multi-level, sequential | ✅ Confirmed |
|
||||
| **TAT Tracking** | Per-level with reminders | ✅ Confirmed |
|
||||
|
||||
---
|
||||
|
||||
## 📋 RECOMMENDED Technology Stack (Final)
|
||||
|
||||
### **✅ Frontend**
|
||||
```
|
||||
Framework: Next.js 14+ (App Router)
|
||||
UI Library: React 18+
|
||||
State Management: Redux Toolkit
|
||||
Styling: Tailwind CSS + Shadcn UI
|
||||
Forms: React Hook Form + Zod
|
||||
Rich Text Editor: Tiptap
|
||||
File Upload: React Dropzone
|
||||
HTTP Client: Axios
|
||||
```
|
||||
|
||||
### **✅ Backend**
|
||||
```
|
||||
Runtime: Node.js 20 LTS
|
||||
Framework: Express.js
|
||||
Language: TypeScript
|
||||
API Style: RESTful
|
||||
Authentication: JWT (JSON Web Tokens)
|
||||
ORM: Prisma (for PostgreSQL)
|
||||
Email: Nodemailer + SMTP
|
||||
Job Scheduler: Node-cron (for TAT reminders)
|
||||
Logging: Winston
|
||||
```
|
||||
|
||||
### **✅ Database**
|
||||
```
|
||||
Primary: PostgreSQL 15+
|
||||
Caching: Redis (optional)
|
||||
```
|
||||
|
||||
### **✅ Infrastructure**
|
||||
```
|
||||
Cloud: Google Cloud Platform (GCP)
|
||||
Compute: 1 VM - Ubuntu 24.04 LTS
|
||||
4-Core, 16GB RAM, 500GB SSD
|
||||
Storage: Google Cloud Storage (GCS)
|
||||
Web Server: Nginx (reverse proxy)
|
||||
Process Manager: PM2
|
||||
SSL: Let's Encrypt or GCP Managed
|
||||
```
|
||||
|
||||
### **✅ AI Integration**
|
||||
```
|
||||
Service: OpenAI GPT-4 (or Azure OpenAI)
|
||||
Purpose: Generate conclusion remarks
|
||||
```
|
||||
|
||||
### **✅ DevOps**
|
||||
```
|
||||
Repository: GitHub / GitLab
|
||||
CI/CD: GitHub Actions
|
||||
Monitoring: Google Cloud Monitoring + Sentry
|
||||
Testing: Jest + React Testing Library + Playwright
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔐 Critical Dependencies (BLOCKERS)
|
||||
|
||||
These MUST be provided before development can begin:
|
||||
|
||||
### **1. SSO Integration (CRITICAL)**
|
||||
- [ ] SSO endpoint URL
|
||||
- [ ] Integration documentation
|
||||
- [ ] Client ID and Client Secret
|
||||
- [ ] Test environment access
|
||||
- [ ] 10-15 test user accounts
|
||||
- [ ] Sample JWT token structure
|
||||
|
||||
**Without this:** ❌ Cannot implement login
|
||||
|
||||
---
|
||||
|
||||
### **2. Active Directory Access (CRITICAL)**
|
||||
- [ ] AD integration method (LDAP / Graph API / Custom API)
|
||||
- [ ] Service account credentials
|
||||
- [ ] AD schema documentation (available fields)
|
||||
- [ ] Sample AD query response
|
||||
|
||||
**Without this:** ❌ Cannot implement @tagging feature
|
||||
|
||||
---
|
||||
|
||||
### **3. Database (CRITICAL)**
|
||||
- [ ] Database server hostname and port
|
||||
- [ ] Database name, username, password
|
||||
- [ ] PostgreSQL version
|
||||
- [ ] Connection string
|
||||
|
||||
**Without this:** ❌ Cannot persist any data
|
||||
|
||||
---
|
||||
|
||||
### **4. GCP Infrastructure (CRITICAL)**
|
||||
- [ ] GCP project access (IAM permissions)
|
||||
- [ ] VM IP address / hostname
|
||||
- [ ] SSH access credentials
|
||||
- [ ] GCS bucket name and credentials
|
||||
|
||||
**Without this:** ❌ Cannot deploy application
|
||||
|
||||
---
|
||||
|
||||
### **5. Email Service (HIGH PRIORITY)**
|
||||
|
||||
**⚠️ CLARIFICATION NEEDED:**
|
||||
- SRS says: "Optional email integration"
|
||||
- Proposal assumes: Email is required
|
||||
|
||||
**👉 DECISION REQUIRED:** Is email mandatory or optional?
|
||||
|
||||
If **mandatory**, need:
|
||||
- [ ] SMTP host, port, credentials
|
||||
- [ ] Sender email address (e.g., `workflow-noreply@royalenfield.com`)
|
||||
- [ ] Daily sending limits
|
||||
- [ ] Email template designs (HTML)
|
||||
|
||||
**Without this:** ⚠️ Cannot send notifications
|
||||
|
||||
---
|
||||
|
||||
### **6. AI Service (MEDIUM PRIORITY)**
|
||||
- [ ] AI service selection (OpenAI / Azure / Gemini)
|
||||
- [ ] API credentials
|
||||
- [ ] Data privacy clearance
|
||||
|
||||
**Without this:** ⚠️ Cannot generate conclusion remarks (can build later)
|
||||
|
||||
---
|
||||
|
||||
### **7. Domain & SSL (HIGH PRIORITY)**
|
||||
- [ ] Domain name (e.g., `workflow.royalenfield.com`)
|
||||
- [ ] DNS configuration
|
||||
- [ ] SSL certificate
|
||||
|
||||
**Without this:** ⚠️ Cannot access via proper URL
|
||||
|
||||
---
|
||||
|
||||
### **8. Figma Access (HIGH PRIORITY)**
|
||||
- [ ] Figma developer handoff access
|
||||
- [ ] Brand assets (logos, colors, fonts)
|
||||
- [ ] Icon library
|
||||
|
||||
**Without this:** ⚠️ UI won't match designs
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Development Timeline (Estimated)
|
||||
|
||||
Assuming all dependencies are resolved:
|
||||
|
||||
| Phase | Duration | Activities |
|
||||
|-------|----------|-----------|
|
||||
| **Setup & Design** | 2 weeks | Environment setup, database schema, API design |
|
||||
| **Sprint 1-2** | 4 weeks | SSO, User management, Basic workflow creation |
|
||||
| **Sprint 3-4** | 4 weeks | Approval hierarchy, TAT tracking, Notifications |
|
||||
| **Sprint 5-6** | 4 weeks | Work Notes, Documents, Activity logs |
|
||||
| **Sprint 7** | 2 weeks | AI integration, Closure remarks |
|
||||
| **Sprint 8** | 2 weeks | Dashboard, Reports, Polish |
|
||||
| **Testing & UAT** | 3 weeks | QA testing, UAT, bug fixes |
|
||||
| **Deployment** | 1 week | Production deployment, monitoring setup |
|
||||
|
||||
**Total:** ~22 weeks (5.5 months)
|
||||
|
||||
**⚠️ This assumes:**
|
||||
- All dependencies provided in Week 1
|
||||
- No scope changes
|
||||
- Timely feedback from RE (within 3 days)
|
||||
- No major blockers
|
||||
|
||||
---
|
||||
|
||||
## 📅 Immediate Action Items
|
||||
|
||||
### **This Week (Week 0 - Pre-Development):**
|
||||
|
||||
**🔴 CRITICAL DECISIONS:**
|
||||
- [ ] **Decision:** React.js or Next.js?
|
||||
- [ ] **Decision:** PostgreSQL or MongoDB?
|
||||
- [ ] **Decision:** BPM Platform or Custom?
|
||||
- [ ] **Decision:** Is email mandatory?
|
||||
- [ ] **Decision:** Which AI service?
|
||||
|
||||
**🔴 CRITICAL ACCESS:**
|
||||
- [ ] SSO integration documentation
|
||||
- [ ] AD integration method
|
||||
- [ ] 10-15 test user accounts
|
||||
- [ ] Database credentials
|
||||
- [ ] GCP project access
|
||||
|
||||
**📋 SETUP:**
|
||||
- [ ] Create Git repository
|
||||
- [ ] Set up project management tool (Jira/Zoho)
|
||||
- [ ] Create communication channel (Teams/Slack)
|
||||
- [ ] Identify project coordinator from RE side
|
||||
|
||||
---
|
||||
|
||||
### **Week 1 (Kickstart):**
|
||||
- [ ] Finalize architecture document
|
||||
- [ ] Create database schema design
|
||||
- [ ] Design API endpoint specification
|
||||
- [ ] Set up development environment
|
||||
- [ ] Configure CI/CD pipeline
|
||||
- [ ] Begin Sprint 1 planning
|
||||
|
||||
---
|
||||
|
||||
## 📞 Required Stakeholders for Kickoff Meeting
|
||||
|
||||
**Must Attend:**
|
||||
- ✅ Product Owner (RE)
|
||||
- ✅ Project Sponsor (RE)
|
||||
- ✅ Tech Lead / CTO (RE)
|
||||
- ✅ IT Infrastructure Team (for SSO/AD)
|
||||
- ✅ Database Admin (for DB access)
|
||||
- ✅ Security/InfoSec representative
|
||||
- ✅ Development Team Lead (Softude)
|
||||
- ✅ Project Manager (Softude)
|
||||
|
||||
**Should Attend:**
|
||||
- ⚠️ UX/UI Designer
|
||||
- ⚠️ QA Lead
|
||||
- ⚠️ DevOps Lead
|
||||
- ⚠️ Business Analyst
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Meeting Agenda (Proposed)
|
||||
|
||||
**Duration:** 90 minutes
|
||||
|
||||
### **Part 1: Technology Decisions (30 mins)**
|
||||
1. Present conflicts (React vs Next.js, PostgreSQL vs MongoDB, BPM vs Custom)
|
||||
2. Discuss pros/cons
|
||||
3. **Make decisions** and document
|
||||
|
||||
### **Part 2: Critical Dependencies (30 mins)**
|
||||
1. Review list of required access/credentials
|
||||
2. Assign owners for each dependency
|
||||
3. Set deadlines for each deliverable
|
||||
|
||||
### **Part 3: Project Setup (20 mins)**
|
||||
1. Communication cadence (daily standups, weekly reviews)
|
||||
2. Project management tool
|
||||
3. Git repository setup
|
||||
4. UAT planning
|
||||
|
||||
### **Part 4: Q&A & Next Steps (10 mins)**
|
||||
- Address any concerns
|
||||
- Confirm next meeting date
|
||||
- Assign action items
|
||||
|
||||
---
|
||||
|
||||
## 📊 Success Criteria
|
||||
|
||||
**Development can begin when:**
|
||||
- ✅ All 3 technology conflicts resolved
|
||||
- ✅ SSO documentation received
|
||||
- ✅ Test user accounts provided
|
||||
- ✅ Database credentials received
|
||||
- ✅ Git repository created
|
||||
- ✅ Project coordinator assigned
|
||||
|
||||
**Project is successful when:**
|
||||
- ✅ All SRS requirements implemented
|
||||
- ✅ UAT sign-off received
|
||||
- ✅ Performance: <3 seconds response time
|
||||
- ✅ Security: All security measures implemented
|
||||
- ✅ 99% uptime achieved
|
||||
- ✅ Zero critical bugs in production (first 2 weeks)
|
||||
|
||||
---
|
||||
|
||||
## 🚨 Risk Mitigation
|
||||
|
||||
| Risk | Impact | Mitigation |
|
||||
|------|--------|-----------|
|
||||
| Dependencies not provided on time | 🔴 HIGH | Start with mock data, build in parallel |
|
||||
| SSO integration issues | 🔴 HIGH | Request early access, test thoroughly |
|
||||
| Scope creep | 🟡 MEDIUM | Strict change control process |
|
||||
| Resource unavailability | 🟡 MEDIUM | Cross-train team members |
|
||||
| Email service delays | 🟢 LOW | Make it optional for initial phase |
|
||||
| AI service issues | 🟢 LOW | Build with fallback to manual entry |
|
||||
|
||||
---
|
||||
|
||||
## 💰 Cost Considerations
|
||||
|
||||
**Infrastructure (GCP):**
|
||||
- VM: ~$100-150/month
|
||||
- GCS storage: ~$20-50/month
|
||||
- Database: ~$50-100/month (managed)
|
||||
- Total: ~$170-300/month
|
||||
|
||||
**AI Service (OpenAI GPT-4):**
|
||||
- Estimated: ~$50-200/month (depending on usage)
|
||||
- Alternative: Azure OpenAI (enterprise pricing)
|
||||
|
||||
**Email Service:**
|
||||
- If internal SMTP: $0
|
||||
- If SendGrid/SES: ~$10-50/month
|
||||
|
||||
**Licenses:**
|
||||
- Figma (if needed): Included in RE subscription
|
||||
- GitHub/GitLab: Standard plan sufficient
|
||||
- Monitoring tools: GCP free tier should cover initial needs
|
||||
|
||||
**Total Estimated Monthly Cost:** $230-550
|
||||
|
||||
---
|
||||
|
||||
## 📋 Checklist for Kickoff Meeting
|
||||
|
||||
**Before Meeting:**
|
||||
- [ ] Send this document to all stakeholders (48 hours before)
|
||||
- [ ] Request everyone to review and come prepared with decisions
|
||||
- [ ] Create shared decision log document
|
||||
- [ ] Prepare presentation slides (if needed)
|
||||
|
||||
**During Meeting:**
|
||||
- [ ] Record all decisions
|
||||
- [ ] Assign owners for each action item
|
||||
- [ ] Set deadlines for each deliverable
|
||||
- [ ] Get commitment from all parties
|
||||
|
||||
**After Meeting:**
|
||||
- [ ] Send meeting minutes within 24 hours
|
||||
- [ ] Update tracking sheet with action items
|
||||
- [ ] Follow up on overdue items weekly
|
||||
- [ ] Schedule next checkpoint meeting
|
||||
|
||||
---
|
||||
|
||||
## 📎 Appendix: Reference Documents
|
||||
|
||||
1. **streamlined_approvals.md** - System Requirements Specification (776 lines)
|
||||
2. **Royal Enfield Proposal 1.06.txt** - BPM Platform Proposal (650 lines)
|
||||
3. **Figma Hi-Fi Wireframe** - https://sway-dense-03017508.figma.site
|
||||
4. **RE_FULLSCOPE_AND PROJECT_STRUCTURE.md** - Full project scope
|
||||
5. **RE_Workflow_Complete_Project_Setup.md** - Complete setup guide
|
||||
6. **RE_Project_Kickoff_Requirements.md** - Detailed pre-development checklist
|
||||
7. **RE_Tech_Stack_Conflicts_And_Clarifications.md** - Technical deep-dive
|
||||
|
||||
---
|
||||
|
||||
## ✅ Sign-Off Required
|
||||
|
||||
**By signing below, all parties agree to:**
|
||||
- Technology stack decisions made
|
||||
- Dependencies will be provided as per timeline
|
||||
- Communication cadence will be followed
|
||||
- Change control process will be respected
|
||||
|
||||
| Name | Role | Signature | Date |
|
||||
|------|------|-----------|------|
|
||||
| | Product Owner (RE) | | |
|
||||
| | Tech Lead (RE) | | |
|
||||
| | Project Manager (Softude) | | |
|
||||
| | Development Lead (Softude) | | |
|
||||
|
||||
---
|
||||
|
||||
**Document Status:** ✅ READY FOR REVIEW
|
||||
**Priority:** 🔴 CRITICAL
|
||||
**Action Required:** Schedule kickoff meeting ASAP
|
||||
**Prepared By:** Development Team
|
||||
**Date:** October 17, 2025
|
||||
|
||||
---
|
||||
|
||||
## 📧 Proposed Email to Send
|
||||
|
||||
```
|
||||
Subject: URGENT: RE Workflow Management System - Kickoff Meeting Required
|
||||
|
||||
Hi Team,
|
||||
|
||||
We're ready to start development on the RE Workflow Management System
|
||||
(Non-Templatized Approval Workflows) but need to resolve 3 critical
|
||||
technology conflicts and obtain essential access credentials.
|
||||
|
||||
I've prepared a comprehensive Executive Summary document that covers:
|
||||
✅ Technology stack conflicts requiring decisions
|
||||
✅ Critical dependencies blocking development
|
||||
✅ Recommended approach
|
||||
✅ Timeline estimate (5.5 months)
|
||||
✅ Meeting agenda
|
||||
|
||||
Please review the attached document: RE_EXECUTIVE_SUMMARY_KICKOFF.md
|
||||
|
||||
Can we schedule a 90-minute kickoff meeting this week?
|
||||
|
||||
Proposed dates:
|
||||
- [Date 1]
|
||||
- [Date 2]
|
||||
- [Date 3]
|
||||
|
||||
Required Attendees:
|
||||
- Product Owner
|
||||
- Tech Lead/CTO
|
||||
- IT Infrastructure Team (SSO/AD)
|
||||
- Database Admin
|
||||
- Security/InfoSec
|
||||
- Development Team
|
||||
|
||||
Looking forward to getting this project started!
|
||||
|
||||
Best regards,
|
||||
[Your Name]
|
||||
Development Team Lead
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**END OF EXECUTIVE SUMMARY**
|
||||
|
||||
|
||||
433
RE_Extracted_From_Proposal_Key_Info.md
Normal file
433
RE_Extracted_From_Proposal_Key_Info.md
Normal file
@ -0,0 +1,433 @@
|
||||
# Key Information Extracted from BPM Proposal Document
|
||||
**Relevant to Streamlined Approvals Project**
|
||||
|
||||
---
|
||||
|
||||
## ✅ What We Learned from the Proposal
|
||||
|
||||
### 1️⃣ **Technology Stack Mentioned**
|
||||
|
||||
```
|
||||
Frontend: Next.js
|
||||
Backend: Node.js (with MongoDB compatibility mentioned)
|
||||
Database: MongoDB / PostgreSQL (both mentioned)
|
||||
Auth: Active Directory (AD) via SSO
|
||||
Email: SMTP integration for automated emails
|
||||
API Gateway: Node.js
|
||||
Web Server: Apache (mentioned in proposal)
|
||||
```
|
||||
|
||||
**⚠️ Conflicts with SRS:**
|
||||
- SRS says: React.js + PostgreSQL
|
||||
- Proposal says: Next.js + MongoDB
|
||||
|
||||
**✅ Decision needed before starting development!**
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ **SSO & Authentication Approach**
|
||||
|
||||
From the proposal (line 268):
|
||||
> "Design a secure login page, which allow user to redirect to AD, System user login through AD"
|
||||
|
||||
**What this tells us:**
|
||||
- ✅ SSO integration with Active Directory is confirmed
|
||||
- ✅ Users will be redirected to AD for authentication
|
||||
- ✅ No separate user/password management needed
|
||||
- ⚠️ We need AD integration documentation and test credentials
|
||||
|
||||
**Implementation Pattern:**
|
||||
```
|
||||
User → Workflow Portal → Redirect to AD SSO → Authenticate →
|
||||
Return JWT Token → Access Portal with Token
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ **Email Notification System**
|
||||
|
||||
The proposal mentions **extensive email automation**:
|
||||
|
||||
| Email Type | Trigger | Mentioned In |
|
||||
|-----------|---------|--------------|
|
||||
| Acknowledgement Email | After form submission | Line 83-87 |
|
||||
| Opportunity Email | When vacancy available | Line 98-107 |
|
||||
| Reminder Emails | At D+2, D+5 for pending tasks | Line 115-116 |
|
||||
| Approval Notification | When request needs action | Line 257-259 |
|
||||
| Status Update Emails | On approval/rejection | Throughout |
|
||||
|
||||
**Email Infrastructure Needed:**
|
||||
- SMTP server configuration
|
||||
- Email templates (HTML)
|
||||
- Automated cron jobs for reminders
|
||||
- Sender email address (e.g., `workflow-noreply@royalenfield.com`)
|
||||
|
||||
**⚠️ For Streamlined Approvals:**
|
||||
- SRS says "optional email integration"
|
||||
- Proposal assumes email is REQUIRED
|
||||
- **Decision needed:** Is email mandatory or optional?
|
||||
|
||||
---
|
||||
|
||||
### 4️⃣ **Active Directory Integration**
|
||||
|
||||
**For User Search & @Tagging:**
|
||||
|
||||
The proposal mentions:
|
||||
- User registration with role assignment (lines 270-282)
|
||||
- Multiple user roles managed in the system
|
||||
- Integration with AD for authentication
|
||||
|
||||
**What we need:**
|
||||
- AD LDAP endpoint or Microsoft Graph API access
|
||||
- Service account credentials for querying AD
|
||||
- User attributes available: Name, Email, Employee ID, Department, Designation, Manager
|
||||
- Sample AD user object structure
|
||||
|
||||
**Use Cases:**
|
||||
1. **@Tagging approvers** during workflow creation
|
||||
2. **@Mentioning users** in Work Notes
|
||||
3. **Adding spectators** to requests
|
||||
4. **User search** across organization
|
||||
|
||||
---
|
||||
|
||||
### 5️⃣ **Role-Based Access Control (RBAC)**
|
||||
|
||||
**Roles mentioned in proposal (for Dealer Onboarding):**
|
||||
- Admin ID
|
||||
- DD Lead (Dealer Development Lead)
|
||||
- IT Team
|
||||
- ZM DD (Zonal Manager - Dealer Development)
|
||||
- RBM (Regional Business Manager)
|
||||
- ZBH (Zonal Business Head)
|
||||
- NBH (National Business Head)
|
||||
|
||||
**For Streamlined Approvals (Non-Templatized):**
|
||||
- Initiator
|
||||
- Approver (multi-level, up to 10)
|
||||
- Final Approver
|
||||
- Spectator
|
||||
- Admin (implied but not explicitly defined in SRS)
|
||||
|
||||
**Questions:**
|
||||
- ❓ Is there a Super Admin role?
|
||||
- ❓ Can Admin view/modify any request?
|
||||
- ❓ How are roles assigned - from AD or application?
|
||||
|
||||
---
|
||||
|
||||
### 6️⃣ **File Upload & Document Management**
|
||||
|
||||
**From Proposal:**
|
||||
- File upload functionality required
|
||||
- Support for multiple file types
|
||||
- Document storage and retrieval
|
||||
- Document version management mentioned
|
||||
|
||||
**From SRS (Streamlined Approvals):**
|
||||
- Max file size: 10MB per file
|
||||
- Supported formats: PDF, Word, Excel, PPT, Images
|
||||
- Preview for PDF and images
|
||||
- Download for other formats
|
||||
- Google Docs/Sheets links allowed
|
||||
|
||||
**Storage Recommendation:**
|
||||
- Use **Google Cloud Storage (GCS)** for file storage
|
||||
- Store file metadata in PostgreSQL
|
||||
- Generate signed URLs for secure access
|
||||
- Implement file retention policy
|
||||
|
||||
---
|
||||
|
||||
### 7️⃣ **Approval Workflow Pattern**
|
||||
|
||||
**From Proposal (Dealer Resignation/Termination):**
|
||||
|
||||
Lines 203-209:
|
||||
```
|
||||
Approval workflow:
|
||||
- Level 1: Zonal Business Head (ZBH)
|
||||
- Level 2: Dealer Development Lead (DD Lead)
|
||||
- Level 3: National Business Head (NBH)
|
||||
|
||||
If rejected at any level → Request goes back to previous level
|
||||
Email notification sent to responsible person
|
||||
```
|
||||
|
||||
**This matches Streamlined Approvals approach:**
|
||||
- ✅ Multi-level approval hierarchy
|
||||
- ✅ Sequential approval (level by level)
|
||||
- ✅ Rejection sends back to previous level
|
||||
- ✅ Email notifications at each stage
|
||||
- ✅ TAT tracking per level
|
||||
|
||||
---
|
||||
|
||||
### 8️⃣ **Automated Reminders & TAT Management**
|
||||
|
||||
**From Proposal:**
|
||||
|
||||
Lines 257-259:
|
||||
```
|
||||
Automated Email Reminders:
|
||||
- Configure reminders for pending tasks
|
||||
- Mail templates configured
|
||||
- Cron jobs configured
|
||||
```
|
||||
|
||||
Lines 115-116:
|
||||
```
|
||||
Automate Notifications for Incomplete Responses:
|
||||
- Email reminders at D+2 and D+5 days
|
||||
```
|
||||
|
||||
**This aligns with SRS TAT tracking:**
|
||||
- ✅ Automated reminders at TAT thresholds (50%, 80%, 100%)
|
||||
- ✅ Color-coded TAT status (Green/Yellow/Red)
|
||||
- ✅ System-generated alerts
|
||||
- ✅ Cron jobs for scheduled reminders
|
||||
|
||||
---
|
||||
|
||||
### 9️⃣ **Security Measures**
|
||||
|
||||
**From Proposal (lines 465-474):**
|
||||
|
||||
| Security Feature | Description |
|
||||
|-----------------|-------------|
|
||||
| SSL Certificate | All APIs secured with wildcard SSL |
|
||||
| JWT Tokens | JWT and JWE for API security |
|
||||
| Rate Limiting | Minimize automated attack harm |
|
||||
| SQL Injection Protection | App secured from DB injection |
|
||||
| XSS Protection | Clickjacking, XSS, MIME-Sniffing protection |
|
||||
| Security Headers | All security headers enabled |
|
||||
| Session Management | Secure, built-in session manager |
|
||||
| Token Invalidation | JWT tokens invalidated after logout |
|
||||
|
||||
**All of these should be implemented in Streamlined Approvals!**
|
||||
|
||||
---
|
||||
|
||||
### 🔟 **Testing Approach**
|
||||
|
||||
**From Proposal (lines 475-485):**
|
||||
|
||||
```
|
||||
Testing Types:
|
||||
✅ Functionality Testing
|
||||
✅ Usability Testing
|
||||
✅ Compatibility Testing
|
||||
✅ Interface Testing
|
||||
✅ Performance Testing (Basic)
|
||||
✅ Security Testing (Basic)
|
||||
✅ UAT Support
|
||||
✅ 2 weeks post-launch monitoring
|
||||
```
|
||||
|
||||
**This should be our testing roadmap too!**
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣1️⃣ **Communication & Governance**
|
||||
|
||||
**From Proposal (lines 603-618):**
|
||||
|
||||
| Meeting | Frequency | Duration | Attendees |
|
||||
|---------|-----------|----------|-----------|
|
||||
| Daily Scrum | Daily | 10 mins | Dev Team, PM |
|
||||
| Weekly Review | Weekly | 30 mins | Team Heads, PM, Client |
|
||||
| Monthly Governance | Monthly | 60 mins | PM, Client, PO, SPOC |
|
||||
|
||||
**✅ This cadence should be followed for Streamlined Approvals project**
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣2️⃣ **Infrastructure Specifications**
|
||||
|
||||
**From SRS:**
|
||||
```
|
||||
Environment: QA / Testing
|
||||
VMs: 1
|
||||
CPU: 4-Core
|
||||
Memory: 16 GB
|
||||
Disk: 500 GB
|
||||
OS: Ubuntu 24.04 LTS
|
||||
Storage: Cloud (GCS)
|
||||
```
|
||||
|
||||
**Backup:**
|
||||
- Daily incremental backups
|
||||
- Weekly full backups
|
||||
- Restore time: < 2 hours
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣3️⃣ **Project Methodology**
|
||||
|
||||
**From Proposal: Waterfall Approach**
|
||||
|
||||
Phases:
|
||||
1. Scope and plan project
|
||||
2. Gather and document requirements
|
||||
3. Design application
|
||||
4. Develop application and perform unit tests
|
||||
5. Conduct system testing
|
||||
6. Perform UAT
|
||||
7. Fix application as appropriate
|
||||
8. Deploy application
|
||||
|
||||
**⚠️ Note:** Waterfall is mentioned, but Agile/Scrum might be better for:
|
||||
- Non-templatized workflows (requirements may evolve)
|
||||
- Faster feedback cycles
|
||||
- Incremental delivery
|
||||
|
||||
**Recommendation:** Hybrid approach
|
||||
- Waterfall for overall phases
|
||||
- Agile sprints within development phase
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣4️⃣ **Client Responsibilities**
|
||||
|
||||
**From Proposal (lines 554-569) - What RE Must Provide:**
|
||||
|
||||
✅ Designate a project coordinator
|
||||
✅ Provide business logic and rules
|
||||
✅ Timely responses (within 3 days for queries, demos, UAT)
|
||||
✅ Change control approval (within 7 days)
|
||||
✅ Provide hosting server
|
||||
✅ Provide software licenses (if any)
|
||||
✅ Make server available with required environment
|
||||
✅ Support coordination with third parties (e.g., SSO, AD, payment gateways)
|
||||
|
||||
**These are CRITICAL dependencies!**
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣5️⃣ **Assumptions from Proposal**
|
||||
|
||||
**Important assumptions (lines 533-543):**
|
||||
|
||||
1. ✅ RE will provide SAP APIs (if needed)
|
||||
2. ✅ RE will provide accurate information
|
||||
3. ✅ RE will approve and review on time
|
||||
4. ✅ RE will complete UAT before handover
|
||||
5. ✅ Development team will have full access to RE personnel and documentation
|
||||
6. ✅ RE will provide needed documentation
|
||||
7. ✅ Technical/organizational changes communicated 1 week in advance
|
||||
8. ⚠️ HA (High Availability) architecture assumed for business-critical apps
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣6️⃣ **Out of Scope (From Proposal)**
|
||||
|
||||
What is **NOT included** (lines 544-553):
|
||||
|
||||
❌ Any module not mentioned in scope
|
||||
❌ Third-party integrations not listed
|
||||
❌ On-premises system configuration
|
||||
❌ Data cleansing and validation
|
||||
❌ Purchase of 3rd party licenses
|
||||
❌ Data creation
|
||||
❌ Data migration to new application
|
||||
❌ Any requirement not in scope document
|
||||
|
||||
**For Streamlined Approvals:**
|
||||
This means:
|
||||
- ❌ SAP integration (not needed)
|
||||
- ❌ DMS integration (not needed)
|
||||
- ❌ Data migration from old systems (if any)
|
||||
- ❌ Integration with other RE systems (unless specified)
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Critical Takeaways for Streamlined Approvals
|
||||
|
||||
### ✅ What's Confirmed:
|
||||
1. **SSO/AD authentication** is required and proven approach exists
|
||||
2. **Email notifications** are expected (not optional)
|
||||
3. **Multi-level approval workflow** pattern is validated
|
||||
4. **Security measures** are well-defined
|
||||
5. **Testing approach** is comprehensive
|
||||
6. **Infrastructure specs** are clear (1 VM, Ubuntu 24.04, 4-Core, 16GB)
|
||||
7. **Communication cadence** is defined
|
||||
|
||||
### ⚠️ What Needs Clarification:
|
||||
1. **Frontend:** React.js (SRS) vs Next.js (Proposal) ← **MUST DECIDE**
|
||||
2. **Database:** PostgreSQL (SRS) vs MongoDB (Proposal) ← **MUST DECIDE**
|
||||
3. **BPM Platform:** Use Camunda/Newgen or build custom? ← **MUST DECIDE**
|
||||
4. **Email service:** Is it mandatory or optional? ← **MUST CLARIFY**
|
||||
5. **AI service:** Which provider for conclusion remarks? ← **MUST DECIDE**
|
||||
6. **Admin role:** What are admin privileges? ← **MUST DEFINE**
|
||||
|
||||
### 🚨 Blockers if Not Resolved:
|
||||
1. ❌ **No SSO documentation** → Cannot implement login
|
||||
2. ❌ **No AD access method** → Cannot implement @tagging
|
||||
3. ❌ **No test users** → Cannot test workflows
|
||||
4. ❌ **No database credentials** → Cannot persist data
|
||||
5. ❌ **No email SMTP config** → Cannot send notifications
|
||||
6. ❌ **Tech stack not finalized** → Cannot start development
|
||||
|
||||
---
|
||||
|
||||
## 📋 Action Items Summary
|
||||
|
||||
### **Week 1 (CRITICAL):**
|
||||
- [ ] Schedule kickoff meeting with RE stakeholders
|
||||
- [ ] Get decision on: React vs Next.js
|
||||
- [ ] Get decision on: PostgreSQL vs MongoDB
|
||||
- [ ] Get decision on: BPM platform vs Custom
|
||||
- [ ] Obtain SSO integration documentation
|
||||
- [ ] Obtain AD integration method
|
||||
- [ ] Get 10-15 test user accounts
|
||||
- [ ] Receive database connection credentials
|
||||
- [ ] Set up Git repository
|
||||
|
||||
### **Week 2 (HIGH PRIORITY):**
|
||||
- [ ] Confirm email service requirement (mandatory or optional?)
|
||||
- [ ] Obtain SMTP credentials if email is required
|
||||
- [ ] Select AI service provider (OpenAI/Azure/Gemini)
|
||||
- [ ] Get GCP project access and VM details
|
||||
- [ ] Obtain domain name and SSL certificate
|
||||
- [ ] Finalize role definitions (especially Admin role)
|
||||
- [ ] Set up development environment
|
||||
- [ ] Begin database schema design
|
||||
|
||||
### **Week 3 (MEDIUM PRIORITY):**
|
||||
- [ ] Create architecture document
|
||||
- [ ] Design API endpoints
|
||||
- [ ] Create email template designs
|
||||
- [ ] Set up CI/CD pipeline
|
||||
- [ ] Prepare test data and scenarios
|
||||
- [ ] Identify UAT participants
|
||||
- [ ] Begin sprint planning
|
||||
|
||||
---
|
||||
|
||||
## 📞 Who to Contact for What
|
||||
|
||||
| Dependency | Contact Role | Purpose |
|
||||
|-----------|--------------|---------|
|
||||
| SSO Integration | IT Infrastructure Team | Documentation + test environment |
|
||||
| AD Integration | Directory Services Team | LDAP access + service account |
|
||||
| Database | Database Admin | Credentials + provisioning |
|
||||
| Email SMTP | IT Operations | SMTP config + approval |
|
||||
| GCP Infrastructure | Cloud Admin | VM access + GCS bucket |
|
||||
| AI Service | Product Owner + Legal | Selection + data privacy |
|
||||
| Test Users | HR/IT | User accounts with roles |
|
||||
| Figma Designs | UX/UI Designer | Developer handoff access |
|
||||
| Domain/SSL | Network Admin | DNS + certificate |
|
||||
| Security Review | InfoSec Team | Security requirements |
|
||||
|
||||
---
|
||||
|
||||
**Document Created:** October 17, 2025
|
||||
**Source Documents:**
|
||||
- `streamlined_approvals.md` (SRS)
|
||||
- `Royal Enfield Proposal 1.06.txt` (BPM Proposal)
|
||||
|
||||
**Status:** ✅ Ready for Review
|
||||
**Next Step:** Present in kickoff meeting and get decisions on all conflicts
|
||||
|
||||
|
||||
734
RE_MISSING_CRITICAL_KICKOFF_POINTS.md
Normal file
734
RE_MISSING_CRITICAL_KICKOFF_POINTS.md
Normal file
@ -0,0 +1,734 @@
|
||||
# CRITICAL: Missing Points from Kickoff Requirements
|
||||
**RE Workflow Management System - Streamlined Approvals**
|
||||
**Date:** October 17, 2025
|
||||
**Status:** 🚨 MUST ADDRESS BEFORE DEVELOPMENT
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ CRITICAL MISSED POINTS
|
||||
|
||||
### **1. Working Days vs Calendar Days Calculation**
|
||||
|
||||
**FROM SRS (CRITICAL FOR TAT CALCULATION):**
|
||||
|
||||
```
|
||||
Priority Level:
|
||||
- Express (Urgent): Uses CALENDAR DAYS in TAT calculation
|
||||
- Standard (Default): Uses WORKING DAYS in TAT calculation
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q1.1:** What constitutes a "working day" at Royal Enfield?
|
||||
- Monday-Friday only?
|
||||
- Monday-Saturday (6-day work week)?
|
||||
- Specific company work schedule?
|
||||
|
||||
- [ ] **Q1.2:** Holiday calendar for working days calculation
|
||||
- Need complete list of RE public holidays for current + next year
|
||||
- Format: Excel/CSV with dates
|
||||
- National holidays + RE-specific holidays + Regional holidays?
|
||||
|
||||
- [ ] **Q1.3:** How to handle TAT calculation across holidays?
|
||||
- Example: 3 working days TAT set on Friday → Due date Monday or Tuesday?
|
||||
- If holiday falls mid-TAT period, extend automatically?
|
||||
|
||||
- [ ] **Q1.4:** Weekend definition
|
||||
- Saturday-Sunday?
|
||||
- Or different (e.g., Friday-Saturday in some regions)?
|
||||
|
||||
- [ ] **Q1.5:** TAT tracking during holidays
|
||||
- TAT timer pauses during holidays/weekends for "Standard" priority?
|
||||
- TAT continues running for "Express" priority (calendar days)?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] RE holiday calendar (current year + next year)
|
||||
- [ ] Work week definition (5-day or 6-day)
|
||||
- [ ] TAT calculation logic document
|
||||
- [ ] Holiday handling rules
|
||||
|
||||
---
|
||||
|
||||
### **2. Rich Text Editor Requirements**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"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"
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q2.1:** Rich text editor for which fields?
|
||||
- Request Description (mentioned)
|
||||
- Work Notes/Comments?
|
||||
- Approval/Rejection remarks?
|
||||
- Closure remarks?
|
||||
|
||||
- [ ] **Q2.2:** Specific formatting features required:
|
||||
- [ ] Bold, Italic, Underline
|
||||
- [ ] Bullet points and numbered lists
|
||||
- [ ] Tables (insert/edit)
|
||||
- [ ] Hyperlinks
|
||||
- [ ] Images inline (or only as attachments?)
|
||||
- [ ] Font size, color?
|
||||
- [ ] Code blocks?
|
||||
- [ ] Quotes/blockquotes?
|
||||
|
||||
- [ ] **Q2.3:** Copy-paste behavior
|
||||
- Paste from Word documents - preserve formatting?
|
||||
- Paste from Excel - preserve table structure?
|
||||
- Sanitize pasted content for security?
|
||||
|
||||
- [ ] **Q2.4:** Character limits
|
||||
- Request Description: Max characters?
|
||||
- Work Notes: 2000 characters mentioned
|
||||
- Approval remarks: 500 characters mentioned
|
||||
- Closure remarks: Any limit?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Approved rich text features list
|
||||
- [ ] Character limits for each field
|
||||
- [ ] Copy-paste behavior specifications
|
||||
|
||||
---
|
||||
|
||||
### **3. Dashboard Specifications**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"The Dashboard is an open element that is currently under discussion
|
||||
and will be finalized in later phases."
|
||||
```
|
||||
|
||||
**🚨 CRITICAL DECISION NEEDED:**
|
||||
- [ ] **Q3.1:** Should development proceed WITHOUT dashboard?
|
||||
- Skip dashboard entirely for Phase 1?
|
||||
- Build basic dashboard (show request counts only)?
|
||||
- Wait for dashboard requirements before starting?
|
||||
|
||||
- [ ] **Q3.2:** If basic dashboard is needed, what to show?
|
||||
- Total requests (by status)?
|
||||
- Pending approvals count?
|
||||
- Requests approaching TAT deadline?
|
||||
- Recent activity?
|
||||
- Quick actions/shortcuts?
|
||||
|
||||
- [ ] **Q3.3:** Dashboard finalization timeline
|
||||
- When will dashboard requirements be ready?
|
||||
- Can we start development in parallel?
|
||||
|
||||
**RECOMMENDATION:**
|
||||
Start with basic dashboard showing:
|
||||
- My Pending Approvals (count + list)
|
||||
- My Requests Summary (Draft, In Progress, Approved, Rejected)
|
||||
- Requests Approaching TAT Deadline
|
||||
- Recent Notifications
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Dashboard scope decision (Phase 1 or Phase 2?)
|
||||
- [ ] Basic dashboard requirements (if Phase 1)
|
||||
- [ ] Dashboard timeline (if Phase 2)
|
||||
|
||||
---
|
||||
|
||||
### **4. Draft Functionality Requirements**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"After verification, the user can either save the request as draft
|
||||
or click 'Submit Request.'"
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q4.1:** Draft retention period
|
||||
- How long are drafts kept? (30 days, 90 days, indefinitely?)
|
||||
- Auto-delete policy for old drafts?
|
||||
- Warning before auto-deletion?
|
||||
|
||||
- [ ] **Q4.2:** Draft editing permissions
|
||||
- Can only initiator edit their draft?
|
||||
- What if initiator is on leave - can manager access/edit?
|
||||
- Can drafts be shared with others for collaboration?
|
||||
|
||||
- [ ] **Q4.3:** Draft auto-save
|
||||
- Auto-save while user is creating request?
|
||||
- Save frequency (every 30 seconds, on field change)?
|
||||
- Show "Last saved at..." timestamp?
|
||||
|
||||
- [ ] **Q4.4:** Draft limits
|
||||
- Max number of drafts per user?
|
||||
- Storage limit for draft attachments?
|
||||
|
||||
- [ ] **Q4.5:** Draft to submitted conversion
|
||||
- Can submitted request be reverted to draft?
|
||||
- If rejected, can it be reopened as draft for editing?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Draft retention policy
|
||||
- [ ] Draft auto-save behavior
|
||||
- [ ] Draft limits and quotas
|
||||
|
||||
---
|
||||
|
||||
### **5. Google Docs/Sheets Integration**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"Users can associate Google Docs and Google Sheets links as part
|
||||
of the request for collaborative reference."
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q5.1:** Google Workspace integration
|
||||
- Is RE using Google Workspace / G Suite?
|
||||
- Or personal Google accounts allowed?
|
||||
- Or should we support both?
|
||||
|
||||
- [ ] **Q5.2:** Access validation
|
||||
- Should system validate that linked Google Doc is accessible to all participants?
|
||||
- Check permissions before allowing link?
|
||||
- Warning if doc is private/restricted?
|
||||
|
||||
- [ ] **Q5.3:** Link display
|
||||
- Show preview of Google Doc (embed)?
|
||||
- Or just show link with title?
|
||||
- Extract title automatically from link?
|
||||
|
||||
- [ ] **Q5.4:** Link editing
|
||||
- Can links be edited after adding?
|
||||
- Can links be removed?
|
||||
- Who can add/edit/remove links - any participant or only initiator?
|
||||
|
||||
- [ ] **Q5.5:** Other cloud storage support
|
||||
- Only Google Docs/Sheets or also:
|
||||
- Microsoft OneDrive/SharePoint?
|
||||
- Dropbox?
|
||||
- RE internal file shares?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Google Workspace details (if using)
|
||||
- [ ] Access validation requirements
|
||||
- [ ] Supported cloud storage platforms
|
||||
|
||||
---
|
||||
|
||||
### **6. Pilot Rollout Strategy**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"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."
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q6.1:** Pilot user selection
|
||||
- Which departments for pilot? (Name specific departments)
|
||||
- How many users in pilot? (10, 20, 50?)
|
||||
- User roles represented in pilot?
|
||||
|
||||
- [ ] **Q6.2:** Pilot duration
|
||||
- How long is pilot phase? (2 weeks, 1 month, 2 months?)
|
||||
- Success criteria for pilot?
|
||||
- Go/No-go decision process?
|
||||
|
||||
- [ ] **Q6.3:** Pilot environment
|
||||
- Separate pilot environment or use QA?
|
||||
- Pilot data - real or test data?
|
||||
- Pilot database separate or shared with production?
|
||||
|
||||
- [ ] **Q6.4:** Pilot to production data migration
|
||||
- Will pilot requests be migrated to production?
|
||||
- Or start fresh in production?
|
||||
|
||||
- [ ] **Q6.5:** Feedback collection during pilot
|
||||
- How to collect feedback? (Surveys, interviews, feedback form in app?)
|
||||
- Who analyzes feedback?
|
||||
- Timeline for incorporating feedback?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Pilot department list
|
||||
- [ ] Pilot user list (with roles)
|
||||
- [ ] Pilot timeline and success criteria
|
||||
- [ ] Feedback collection mechanism
|
||||
|
||||
---
|
||||
|
||||
### **7. Non-Functional Requirements - Missed Details**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
Performance: Average response time < 3 seconds for standard operations.
|
||||
Scalability: Should scale horizontally on GCP.
|
||||
Reliability: 99% uptime target.
|
||||
Backup & Recovery: Daily database backup and weekly full snapshot.
|
||||
Restore process must not exceed 2 hours.
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
|
||||
#### **Performance:**
|
||||
- [ ] **Q7.1:** What are "standard operations"?
|
||||
- Page load (Dashboard, My Requests)?
|
||||
- API calls (fetch request list)?
|
||||
- Document upload?
|
||||
- Search queries?
|
||||
|
||||
- [ ] **Q7.2:** Performance under load
|
||||
- <3 seconds for how many concurrent users? (1, 10, 100?)
|
||||
- What if system is under heavy load?
|
||||
- Graceful degradation strategy?
|
||||
|
||||
#### **Scalability:**
|
||||
- [ ] **Q7.3:** Horizontal scaling on GCP
|
||||
- Initial setup: 1 VM (as per SRS)
|
||||
- When to scale horizontally? (>100 users, >500 users?)
|
||||
- Load balancer setup required?
|
||||
- Auto-scaling configuration?
|
||||
|
||||
- [ ] **Q7.4:** Expected growth
|
||||
- Current user base size?
|
||||
- Expected growth in 6 months, 1 year?
|
||||
- Peak usage times (end of month, quarterly approvals)?
|
||||
|
||||
#### **Reliability:**
|
||||
- [ ] **Q7.5:** 99% uptime target
|
||||
- Allowed downtime: ~7.3 hours/month
|
||||
- Planned maintenance windows?
|
||||
- Preferred maintenance day/time? (Weekends, after hours?)
|
||||
|
||||
- [ ] **Q7.6:** High availability setup
|
||||
- Database replication required?
|
||||
- Failover mechanism needed?
|
||||
- Or acceptable to have brief downtime during recovery?
|
||||
|
||||
#### **Backup & Recovery:**
|
||||
- [ ] **Q7.7:** Backup verification
|
||||
- Who verifies backups are working?
|
||||
- Test restore frequency? (Monthly, quarterly?)
|
||||
|
||||
- [ ] **Q7.8:** Backup retention
|
||||
- Daily backups kept for how long? (7 days, 30 days?)
|
||||
- Weekly backups kept for how long? (90 days, 1 year?)
|
||||
|
||||
- [ ] **Q7.9:** Disaster recovery
|
||||
- Off-site backup required?
|
||||
- Geographic redundancy (multi-region)?
|
||||
- Recovery Point Objective (RPO): Max data loss acceptable?
|
||||
- Recovery Time Objective (RTO): Max downtime acceptable? (Currently says <2 hours)
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Performance benchmarks with specific user loads
|
||||
- [ ] Scaling strategy document
|
||||
- [ ] Backup verification and retention policy
|
||||
- [ ] Disaster recovery plan
|
||||
|
||||
---
|
||||
|
||||
### **8. RE IT Data Privacy Guidelines**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"Compliance: Follows RE IT data privacy guidelines."
|
||||
```
|
||||
|
||||
**🚨 CRITICAL QUESTION:**
|
||||
- [ ] **Q8.1:** What are RE IT data privacy guidelines?
|
||||
- **WHERE IS THE DOCUMENT?**
|
||||
- Who provides this?
|
||||
- Is it documented or need to be created?
|
||||
|
||||
- [ ] **Q8.2:** Specific compliance requirements
|
||||
- Data classification (Public, Internal, Confidential, Restricted)?
|
||||
- PII handling rules?
|
||||
- Data retention periods?
|
||||
- Data deletion/archival policy?
|
||||
- Geographic data residency (India only, Asia, Global)?
|
||||
|
||||
- [ ] **Q8.3:** Audit trail requirements
|
||||
- What actions must be logged?
|
||||
- Audit log retention period?
|
||||
- Who can access audit logs?
|
||||
- Format for audit reports?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] **RE IT Data Privacy Guidelines document (CRITICAL)**
|
||||
- [ ] Data classification matrix
|
||||
- [ ] Audit trail specifications
|
||||
- [ ] Data retention policy document
|
||||
|
||||
---
|
||||
|
||||
### **9. Template for Future Scope**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"Existing Template – (Future scope) Use a predefined structure."
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS FOR ARCHITECTURE:**
|
||||
- [ ] **Q9.1:** Architecture consideration for templates
|
||||
- Should current architecture support templates in future?
|
||||
- Database schema designed to accommodate templates later?
|
||||
- Or complete refactor needed for templates?
|
||||
|
||||
- [ ] **Q9.2:** Template timeline
|
||||
- When is template feature expected? (Phase 2, Phase 3?)
|
||||
- Any specific templates in mind?
|
||||
- Should we prepare for this in initial design?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Future roadmap with template timeline
|
||||
- [ ] Architecture review for template support
|
||||
|
||||
---
|
||||
|
||||
### **10. "Not in Scope" Clarification**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"Anything which comes beyond the scope defined above in terms of
|
||||
Width and depth"
|
||||
```
|
||||
|
||||
**🚨 EXPLICIT OUT OF SCOPE CONFIRMATION NEEDED:**
|
||||
|
||||
- [ ] **Q10.1:** Explicitly confirm what is OUT OF SCOPE:
|
||||
- [ ] Mobile app (web-only)
|
||||
- [ ] SAP integration
|
||||
- [ ] DMS integration
|
||||
- [ ] Reporting module (beyond basic)
|
||||
- [ ] Analytics dashboard
|
||||
- [ ] Workflow templates
|
||||
- [ ] Parallel approvals (only sequential supported)
|
||||
- [ ] Conditional routing (if-then-else in workflow)
|
||||
- [ ] Delegation (approver assigns to someone else)
|
||||
- [ ] Bulk actions (approve multiple requests at once)
|
||||
- [ ] Scheduled/Recurring workflows
|
||||
- [ ] API for external systems
|
||||
- [ ] Data import/export functionality
|
||||
- [ ] Multi-language support
|
||||
- [ ] Approval via email (approve by replying to email)
|
||||
- [ ] SMS notifications
|
||||
- [ ] Push notifications
|
||||
- [ ] Offline mode
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Signed "Out of Scope" list to prevent scope creep
|
||||
|
||||
---
|
||||
|
||||
## 🎯 NEW CRITICAL DEPENDENCIES IDENTIFIED
|
||||
|
||||
### **11. Holiday Calendar API/Service**
|
||||
|
||||
**CRITICAL FOR TAT CALCULATION:**
|
||||
- [ ] Does RE have a holiday calendar API/service?
|
||||
- [ ] If yes, API documentation and access?
|
||||
- [ ] If no, need to build holiday management module:
|
||||
- Admin UI to manage holidays
|
||||
- Regional holiday support
|
||||
- Holiday calendar import/export
|
||||
|
||||
**OPTIONS:**
|
||||
- **Option A:** RE provides holiday API (best)
|
||||
- **Option B:** Build simple holiday management (admin adds holidays manually)
|
||||
- **Option C:** Use third-party holiday API (Google Calendar API?)
|
||||
|
||||
**DECISION REQUIRED:** Which option?
|
||||
|
||||
---
|
||||
|
||||
### **12. Rich Text Editor Library**
|
||||
|
||||
**TECHNICAL DECISION:**
|
||||
- [ ] Which rich text editor to use?
|
||||
- **Tiptap** (modern, extensible, React-friendly)
|
||||
- **Quill** (stable, widely used)
|
||||
- **Draft.js** (by Facebook, powerful but complex)
|
||||
- **Slate** (very flexible, lower level)
|
||||
- **CKEditor** (feature-rich, commercial license for some features)
|
||||
|
||||
- [ ] Do we need custom toolbar?
|
||||
- [ ] Any specific RE branding in editor?
|
||||
|
||||
**RECOMMENDATION:** Tiptap (modern, good DX, extensible)
|
||||
|
||||
**DECISION REQUIRED:** Which editor library?
|
||||
|
||||
---
|
||||
|
||||
### **13. File Preview Library**
|
||||
|
||||
**FOR PDF AND IMAGE PREVIEW:**
|
||||
- [ ] PDF preview library decision:
|
||||
- **PDF.js** (Mozilla, open source, widely used)
|
||||
- **React-PDF** (wrapper for PDF.js)
|
||||
- **pdfobject** (simple embed)
|
||||
|
||||
- [ ] Image preview/lightbox:
|
||||
- **React Image Lightbox**
|
||||
- **PhotoSwipe**
|
||||
- **Fancybox**
|
||||
|
||||
**RECOMMENDATION:** React-PDF for PDFs, React Image Lightbox for images
|
||||
|
||||
**DECISION REQUIRED:** Which libraries?
|
||||
|
||||
---
|
||||
|
||||
### **14. Data Privacy for AI Service**
|
||||
|
||||
**CRITICAL FOR AI-GENERATED CONCLUSION:**
|
||||
|
||||
- [ ] **Q14.1:** Can workflow request data be sent to external AI service (OpenAI)?
|
||||
- Requests may contain confidential business information
|
||||
- Employee names, departments, approvers
|
||||
- Discussion content in Work Notes
|
||||
- **Data residency concerns?**
|
||||
|
||||
- [ ] **Q14.2:** If external AI NOT allowed:
|
||||
- Self-hosted LLM required? (Llama, Mistral)
|
||||
- Azure OpenAI (data stays in Azure, compliant)
|
||||
- Or skip AI feature entirely and make it manual?
|
||||
|
||||
- [ ] **Q14.3:** PII filtering before sending to AI
|
||||
- Remove employee names, IDs, emails?
|
||||
- Anonymize data before AI processing?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] **Legal/Compliance approval for AI service** (CRITICAL)
|
||||
- [ ] Data processing agreement with AI provider
|
||||
- [ ] PII filtering specifications
|
||||
|
||||
---
|
||||
|
||||
### **15. Notification Frequency**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"Auto-reminders are sent at configured thresholds (e.g., 80% TAT usage)."
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q15.1:** TAT reminder thresholds
|
||||
- Exactly at what % should reminders be sent?
|
||||
- Example: 50%, 75%, 90%, 100%, 110%?
|
||||
- How often after breach? (Daily, Every 6 hours?)
|
||||
|
||||
- [ ] **Q15.2:** Reminder throttling
|
||||
- Max reminders per day per user?
|
||||
- To prevent notification fatigue
|
||||
|
||||
- [ ] **Q15.3:** Escalation after repeated reminders
|
||||
- If approver ignores 3 reminders, escalate to manager?
|
||||
- Or just keep sending reminders?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] TAT reminder threshold configuration
|
||||
- [ ] Escalation rules document
|
||||
|
||||
---
|
||||
|
||||
### **16. Search and Filter Specifications**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"Includes search and filter options for status and priority to
|
||||
quickly locate specific requests."
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q16.1:** Search by what fields?
|
||||
- Request Title (full-text search)
|
||||
- Request ID (exact match)
|
||||
- Initiator name
|
||||
- Approver name
|
||||
- Department
|
||||
- Date range
|
||||
- Description content?
|
||||
|
||||
- [ ] **Q16.2:** Filter options needed:
|
||||
- Status (Draft, In Progress, Approved, Rejected)
|
||||
- Priority (Express, Standard)
|
||||
- Date range (created between X and Y)
|
||||
- Current approver level
|
||||
- TAT status (Within TAT, Approaching, Breached)
|
||||
- Department
|
||||
- Assigned to me (as approver or initiator)
|
||||
|
||||
- [ ] **Q16.3:** Sort options:
|
||||
- Date created (newest first, oldest first)
|
||||
- TAT remaining (urgent first)
|
||||
- Request ID
|
||||
- Approval level
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Search and filter specifications document
|
||||
- [ ] Approved list of searchable/filterable fields
|
||||
|
||||
---
|
||||
|
||||
### **17. Pagination and Data Loading**
|
||||
|
||||
**FROM SRS:**
|
||||
|
||||
```
|
||||
"Supports pagination and stable ID-based navigation to detail screens."
|
||||
```
|
||||
|
||||
**🚨 QUESTIONS MISSED:**
|
||||
- [ ] **Q17.1:** Pagination size
|
||||
- How many requests per page? (10, 25, 50, 100?)
|
||||
- User-configurable?
|
||||
|
||||
- [ ] **Q17.2:** Total expected data volume
|
||||
- Expected requests per month?
|
||||
- Expected growth over 1 year, 2 years?
|
||||
- This affects database indexing strategy
|
||||
|
||||
- [ ] **Q17.3:** Load more vs pagination
|
||||
- Traditional pagination (1, 2, 3... pages)?
|
||||
- Or "Load More" button (infinite scroll)?
|
||||
- Or both?
|
||||
|
||||
**REQUIRED DELIVERABLES:**
|
||||
- [ ] Pagination preferences
|
||||
- [ ] Expected data volume estimates
|
||||
|
||||
---
|
||||
|
||||
## 📊 SUMMARY: CRITICAL GAPS
|
||||
|
||||
### **🔴 MUST HAVE BEFORE DEVELOPMENT:**
|
||||
|
||||
1. ✅ Working days definition + Holiday calendar
|
||||
2. ✅ Rich text editor feature list
|
||||
3. ✅ Dashboard decision (skip or build basic?)
|
||||
4. ✅ Draft retention policy
|
||||
5. ✅ Google Docs/Sheets validation requirements
|
||||
6. ✅ **RE IT Data Privacy Guidelines document**
|
||||
7. ✅ Legal approval for AI service data usage
|
||||
8. ✅ TAT reminder threshold configuration
|
||||
9. ✅ Out of scope confirmation (signed)
|
||||
|
||||
### **🟡 HIGH PRIORITY (Week 1-2):**
|
||||
|
||||
1. ✅ Pilot rollout strategy and user list
|
||||
2. ✅ Performance benchmark specifications
|
||||
3. ✅ Backup verification and retention policy
|
||||
4. ✅ Search/filter field specifications
|
||||
5. ✅ Rich text editor library selection
|
||||
6. ✅ File preview library selection
|
||||
7. ✅ Pagination preferences
|
||||
8. ✅ Template future roadmap
|
||||
|
||||
### **🟢 MEDIUM PRIORITY (Week 2-3):**
|
||||
|
||||
1. ✅ Holiday calendar API (if available)
|
||||
2. ✅ Notification frequency and throttling
|
||||
3. ✅ Draft auto-save behavior
|
||||
4. ✅ Google Docs preview preferences
|
||||
5. ✅ Disaster recovery detailed plan
|
||||
|
||||
---
|
||||
|
||||
## ✅ ACTION ITEMS FOR KICKOFF MEETING
|
||||
|
||||
### **Add to Meeting Agenda:**
|
||||
|
||||
1. **Working Days & Holiday Calendar** (15 minutes)
|
||||
- Define working days
|
||||
- Provide holiday calendar
|
||||
- Confirm TAT calculation logic
|
||||
|
||||
2. **Dashboard Scope Decision** (10 minutes)
|
||||
- Skip entirely or build basic?
|
||||
- If basic, what to show?
|
||||
|
||||
3. **Rich Text Editor Requirements** (10 minutes)
|
||||
- Which fields need rich text?
|
||||
- Approved formatting features
|
||||
- Character limits
|
||||
|
||||
4. **Draft Functionality** (5 minutes)
|
||||
- Retention period
|
||||
- Auto-save behavior
|
||||
|
||||
5. **AI Service Legal Approval** (10 minutes)
|
||||
- Can we use external AI (OpenAI)?
|
||||
- If not, alternatives?
|
||||
- Legal sign-off needed
|
||||
|
||||
6. **RE IT Data Privacy Guidelines** (10 minutes)
|
||||
- WHERE IS THIS DOCUMENT?
|
||||
- Who provides it?
|
||||
- Critical for compliance
|
||||
|
||||
7. **Out of Scope Confirmation** (5 minutes)
|
||||
- Review and sign off on out-of-scope list
|
||||
- Prevent future scope creep
|
||||
|
||||
8. **Pilot Strategy** (10 minutes)
|
||||
- Which departments?
|
||||
- How many users?
|
||||
- Duration?
|
||||
|
||||
---
|
||||
|
||||
## 📧 URGENT REQUEST EMAIL TEMPLATE
|
||||
|
||||
```
|
||||
Subject: URGENT: Critical Information Needed Before Development Start
|
||||
|
||||
Hi [Product Owner / Stakeholder Name],
|
||||
|
||||
During our detailed analysis of the SRS document, we've identified several
|
||||
CRITICAL gaps that must be addressed before we can start development.
|
||||
|
||||
Most Critical (BLOCKERS):
|
||||
1. Working days definition + RE holiday calendar (for TAT calculation)
|
||||
2. RE IT Data Privacy Guidelines document (mentioned but not provided)
|
||||
3. Legal approval to use external AI service for conclusion remarks
|
||||
4. Dashboard scope decision (skip or build basic?)
|
||||
5. Out of scope confirmation (to prevent scope creep)
|
||||
|
||||
These are in addition to the previously identified dependencies (SSO, AD,
|
||||
Database access, etc.).
|
||||
|
||||
I've created a comprehensive document: RE_MISSING_CRITICAL_KICKOFF_POINTS.md
|
||||
|
||||
Can we schedule an urgent 60-minute call this week to address these gaps?
|
||||
|
||||
Without these clarifications, we cannot:
|
||||
- Design the database schema correctly (affects TAT calculation logic)
|
||||
- Select appropriate libraries (rich text editor, file preview)
|
||||
- Ensure legal compliance (AI service, data privacy)
|
||||
- Prevent scope creep (out of scope confirmation)
|
||||
|
||||
Please let me know your availability ASAP.
|
||||
|
||||
Thanks,
|
||||
[Your Name]
|
||||
Development Team Lead
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Document Owner:** Development Team Lead
|
||||
**Date:** October 17, 2025
|
||||
**Priority:** 🔴 CRITICAL
|
||||
**Status:** ⚠️ AWAITING RESPONSE
|
||||
|
||||
|
||||
651
RE_Tech_Stack_Conflicts_And_Clarifications.md
Normal file
651
RE_Tech_Stack_Conflicts_And_Clarifications.md
Normal file
@ -0,0 +1,651 @@
|
||||
# RE Workflow Management System - Technical Stack Conflicts & Clarifications
|
||||
**Date:** October 17, 2025
|
||||
**Purpose:** Resolve contradictions between documents and finalize technical approach
|
||||
|
||||
---
|
||||
|
||||
## 🚨 CRITICAL: Technology Stack Conflicts
|
||||
|
||||
### **Conflict #1: Frontend Framework**
|
||||
|
||||
| Document | Frontend Technology |
|
||||
|----------|-------------------|
|
||||
| **Streamlined Approvals SRS** (streamlined_approvals.md) | React.js |
|
||||
| **BPM Platform Proposal** (Royal Enfield Proposal 1.06) | Next.js |
|
||||
|
||||
**❓ Question to Resolve:**
|
||||
- Which frontend framework should be used?
|
||||
- **React.js** (Library, client-side rendering by default)
|
||||
- **Next.js** (React framework with SSR/SSG capabilities)
|
||||
|
||||
**Recommendation:** Next.js is better for:
|
||||
- SEO optimization
|
||||
- Server-side rendering for better performance
|
||||
- Built-in routing
|
||||
- Better initial load time
|
||||
- Modern approach for enterprise applications
|
||||
|
||||
**✅ Decision Required:** [ ] React.js OR [ ] Next.js
|
||||
|
||||
---
|
||||
|
||||
### **Conflict #2: Database**
|
||||
|
||||
| Document | Database |
|
||||
|----------|----------|
|
||||
| **Streamlined Approvals SRS** | PostgreSQL (PGSQL) |
|
||||
| **BPM Platform Proposal** | MongoDB |
|
||||
|
||||
**❓ Question to Resolve:**
|
||||
- Which database should be the primary data store?
|
||||
|
||||
**Comparison:**
|
||||
|
||||
| Feature | PostgreSQL | MongoDB |
|
||||
|---------|-----------|---------|
|
||||
| Type | Relational (SQL) | Document (NoSQL) |
|
||||
| Data Structure | Tables, rows, columns | Collections, documents (JSON) |
|
||||
| Schema | Fixed schema | Flexible schema |
|
||||
| ACID Compliance | ✅ Strong | ⚠️ Eventual consistency |
|
||||
| Best For | Structured data, complex queries, transactions | Flexible/evolving schema, rapid development |
|
||||
| Approval Workflows | ✅ Better for hierarchy & status tracking | ⚠️ Requires careful design |
|
||||
| Document Storage | ⚠️ Use separate storage (GCS) | ✅ Can store inline (up to 16MB) |
|
||||
|
||||
**Recommendation for Workflow System:** PostgreSQL
|
||||
- Approval workflows need strong ACID compliance
|
||||
- Complex multi-level approval hierarchy
|
||||
- TAT tracking and audit trail require relational integrity
|
||||
- User roles and permissions are structured data
|
||||
|
||||
**✅ Decision Required:** [ ] PostgreSQL OR [ ] MongoDB
|
||||
|
||||
---
|
||||
|
||||
### **Conflict #3: BPM Platform vs Custom Development**
|
||||
|
||||
**BPM Platform Proposal mentions:**
|
||||
- Camunda Zeebe (Open Source) OR
|
||||
- Newgen (SaaS)
|
||||
|
||||
**Streamlined Approvals SRS does NOT mention any BPM platform**
|
||||
|
||||
**❓ Question to Resolve:**
|
||||
Should we use a BPM (Business Process Management) platform or build custom?
|
||||
|
||||
**Option A: BPM Platform (Camunda/Newgen)**
|
||||
|
||||
**Pros:**
|
||||
- ✅ Built-in workflow engine
|
||||
- ✅ Visual workflow designer (BPMN)
|
||||
- ✅ Out-of-the-box features: task assignment, escalation, notifications
|
||||
- ✅ Easier to modify workflows without code changes
|
||||
- ✅ Audit trails and monitoring built-in
|
||||
|
||||
**Cons:**
|
||||
- ❌ Learning curve for team
|
||||
- ❌ Additional licensing cost (Newgen SaaS)
|
||||
- ❌ Dependency on third-party platform
|
||||
- ❌ May be overkill for non-templatized workflows
|
||||
- ❌ Limited UI customization
|
||||
|
||||
**Option B: Custom Development (React/Next.js + Node.js + PostgreSQL)**
|
||||
|
||||
**Pros:**
|
||||
- ✅ Full control over UI/UX (Figma designs can be followed exactly)
|
||||
- ✅ No licensing costs
|
||||
- ✅ Flexible for non-templatized workflows
|
||||
- ✅ Better integration with RE SSO and AD
|
||||
|
||||
**Cons:**
|
||||
- ❌ More development time
|
||||
- ❌ Need to build workflow engine from scratch
|
||||
- ❌ Maintenance overhead
|
||||
|
||||
**Recommendation for Non-Templatized System:** Custom Development
|
||||
- The SRS clearly states "Non-Templatized" workflows
|
||||
- Dynamic approval levels (up to 10)
|
||||
- Highly customized UI requirements (Figma)
|
||||
- BPM platforms are better for repetitive, templatized processes
|
||||
|
||||
**✅ Decision Required:** [ ] BPM Platform (Camunda/Newgen) OR [ ] Custom Development
|
||||
|
||||
---
|
||||
|
||||
## 📊 Proposed Unified Technology Stack
|
||||
|
||||
Based on both documents and best practices, here's the recommended stack:
|
||||
|
||||
### **Frontend**
|
||||
```
|
||||
Framework: Next.js 14+ (with App Router)
|
||||
UI Library: React 18+
|
||||
State Management: Redux Toolkit or Zustand
|
||||
Styling: Tailwind CSS + Shadcn UI (component library)
|
||||
Forms: React Hook Form + Zod (validation)
|
||||
HTTP Client: Axios or Fetch API
|
||||
Rich Text: Tiptap or Quill (for description/comments)
|
||||
File Upload: React Dropzone
|
||||
Date/Time: Day.js or date-fns
|
||||
Notifications: React Hot Toast or Sonner
|
||||
```
|
||||
|
||||
### **Backend**
|
||||
```
|
||||
Runtime: Node.js 20 LTS
|
||||
Framework: Express.js or Fastify
|
||||
Language: TypeScript (strongly recommended)
|
||||
API Style: RESTful APIs
|
||||
Authentication: JWT (JSON Web Tokens)
|
||||
Validation: Joi or Zod
|
||||
ORM: Prisma or TypeORM (for PostgreSQL)
|
||||
File Storage: Google Cloud Storage (GCS)
|
||||
Email Service: Nodemailer + SMTP or SendGrid
|
||||
Scheduler: Node-cron or Bull Queue (for TAT reminders)
|
||||
Logging: Winston or Pino
|
||||
```
|
||||
|
||||
### **Database**
|
||||
```
|
||||
Primary DB: PostgreSQL 15+ (Managed instance on GCP)
|
||||
Caching: Redis (optional, for session management)
|
||||
```
|
||||
|
||||
### **Infrastructure**
|
||||
```
|
||||
Cloud: Google Cloud Platform (GCP)
|
||||
Compute: VM (Ubuntu 24.04 LTS) - 4 Core, 16GB RAM, 500GB
|
||||
OR Alternative: Cloud Run / App Engine (for auto-scaling)
|
||||
Storage: Google Cloud Storage (GCS)
|
||||
SSL: Let's Encrypt or GCP Managed Certificate
|
||||
Web Server: Nginx (reverse proxy)
|
||||
Process Manager: PM2 (for Node.js)
|
||||
```
|
||||
|
||||
### **DevOps & CI/CD**
|
||||
```
|
||||
Repository: GitHub / GitLab
|
||||
CI/CD: GitHub Actions or GitLab CI
|
||||
Containerization: Docker (optional)
|
||||
Monitoring: Google Cloud Monitoring + Sentry (error tracking)
|
||||
Logging: Google Cloud Logging
|
||||
```
|
||||
|
||||
### **AI Integration**
|
||||
```
|
||||
For Conclusion Remarks:
|
||||
- OpenAI GPT-4 API (recommended)
|
||||
- OR Azure OpenAI Service (for data residency)
|
||||
- OR Google Gemini API
|
||||
```
|
||||
|
||||
### **Testing**
|
||||
```
|
||||
Unit Testing: Jest + React Testing Library
|
||||
E2E Testing: Playwright or Cypress
|
||||
API Testing: Supertest
|
||||
Load Testing: k6 or Artillery (basic)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔐 Authentication & Authorization Flow (From Proposal)
|
||||
|
||||
### **SSO Integration Approach**
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ User │
|
||||
└──────┬──────┘
|
||||
│
|
||||
│ 1. Access Application
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ RE Workflow Portal │
|
||||
│ (Next.js Frontend) │
|
||||
└──────┬──────────────────────┘
|
||||
│
|
||||
│ 2. Redirect to SSO
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ RE SSO Bridge │
|
||||
│ (Active Directory) │
|
||||
└──────┬──────────────────────┘
|
||||
│
|
||||
│ 3. Return JWT Token
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ Backend API │
|
||||
│ (Node.js + Express) │
|
||||
│ │
|
||||
│ - Validate JWT │
|
||||
│ - Fetch user from AD │
|
||||
│ - Create session │
|
||||
│ - Return user profile │
|
||||
└─────────────────────────────┘
|
||||
```
|
||||
|
||||
**Implementation Steps:**
|
||||
1. User clicks "Login" → Redirects to RE SSO endpoint
|
||||
2. SSO authenticates against Active Directory
|
||||
3. SSO returns JWT token with user claims
|
||||
4. Frontend stores JWT in httpOnly cookie (secure)
|
||||
5. Every API call includes JWT in Authorization header
|
||||
6. Backend validates JWT signature
|
||||
7. Backend fetches additional user info from AD if needed
|
||||
8. Session expires based on RE IT policy
|
||||
|
||||
---
|
||||
|
||||
## 📧 Email Notification System (From Proposal)
|
||||
|
||||
### **Email Templates Required:**
|
||||
|
||||
From the proposal, these email notifications are needed:
|
||||
|
||||
1. **Acknowledgement Email** - After request submission
|
||||
2. **Approval Assignment Email** - When request reaches an approver
|
||||
3. **TAT Reminder Email** - At 50%, 80%, 100% TAT usage
|
||||
4. **Approval/Rejection Notification** - To initiator
|
||||
5. **@Mention Notification** - When tagged in Work Notes
|
||||
6. **Request Closure Email** - After final approval
|
||||
7. **Spectator Added Email** - When added to request
|
||||
|
||||
**SMTP Configuration Required:**
|
||||
```javascript
|
||||
{
|
||||
host: "smtp.royalenfield.com",
|
||||
port: 587, // or 465 for SSL
|
||||
secure: false, // true for 465
|
||||
auth: {
|
||||
user: "workflow-noreply@royalenfield.com",
|
||||
pass: "***********"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**❓ Questions:**
|
||||
- [ ] Is SMTP server already available?
|
||||
- [ ] Should we use internal SMTP or third-party (SendGrid/AWS SES)?
|
||||
- [ ] What is daily email sending limit?
|
||||
- [ ] Who designs HTML email templates?
|
||||
- [ ] Sender email address: `workflow-noreply@royalenfield.com`?
|
||||
|
||||
---
|
||||
|
||||
## 🔗 System Integrations
|
||||
|
||||
### **Mentioned in Proposal (For Other Projects):**
|
||||
|
||||
1. **SAP Integration** - For budgeting and invoicing (Claim Management)
|
||||
2. **DMS (Document Management System)** - For document storage
|
||||
3. **Active Directory (AD)** - For user search and @tagging
|
||||
|
||||
### **For Streamlined Approvals Project:**
|
||||
|
||||
**Required Integrations:**
|
||||
1. ✅ **RE SSO Bridge** - Authentication (CRITICAL)
|
||||
2. ✅ **Active Directory (AD)** - User search for @tagging (CRITICAL)
|
||||
3. ⚠️ **Email Service** - SMTP for notifications (HIGH PRIORITY)
|
||||
4. ⚠️ **AI Service (OpenAI/Azure)** - Conclusion remarks (MEDIUM PRIORITY)
|
||||
|
||||
**NOT Required (For Now):**
|
||||
- ❌ SAP Integration (not in streamlined approvals scope)
|
||||
- ❌ DMS Integration (we'll use GCS for document storage)
|
||||
|
||||
---
|
||||
|
||||
## 📋 Updated Pre-Development Questions
|
||||
|
||||
### **1. Technology Stack Finalization**
|
||||
|
||||
- [ ] **Q1:** Confirm frontend framework: React.js or Next.js?
|
||||
- **Proposal says:** Next.js
|
||||
- **SRS says:** React.js
|
||||
- **Recommendation:** Next.js
|
||||
|
||||
- [ ] **Q2:** Confirm database: PostgreSQL or MongoDB?
|
||||
- **Proposal says:** MongoDB
|
||||
- **SRS says:** PostgreSQL
|
||||
- **Recommendation:** PostgreSQL (better for workflow systems)
|
||||
|
||||
- [ ] **Q3:** BPM Platform or Custom Development?
|
||||
- **Proposal mentions:** Camunda Zeebe / Newgen
|
||||
- **SRS implies:** Custom (no mention of BPM)
|
||||
- **Recommendation:** Custom (for non-templatized workflows)
|
||||
|
||||
- [ ] **Q4:** Should we use TypeScript or JavaScript?
|
||||
- **Recommendation:** TypeScript (better for large projects)
|
||||
|
||||
---
|
||||
|
||||
### **2. Email Service Confirmation**
|
||||
|
||||
- [ ] **Q5:** Email notifications are confirmed, right?
|
||||
- SRS says "optional email integration"
|
||||
- Proposal shows multiple email templates
|
||||
- **Need confirmation:** Is email required or optional?
|
||||
|
||||
- [ ] **Q6:** If email is required:
|
||||
- SMTP host, port, credentials?
|
||||
- Sender email address?
|
||||
- Daily sending limits?
|
||||
- Email template designs (HTML)?
|
||||
|
||||
---
|
||||
|
||||
### **3. Active Directory Integration**
|
||||
|
||||
From the proposal, AD integration is mentioned multiple times.
|
||||
|
||||
- [ ] **Q7:** How to access AD for user search/@tagging?
|
||||
- LDAP connection?
|
||||
- Microsoft Graph API?
|
||||
- Custom REST API built by RE IT?
|
||||
|
||||
- [ ] **Q8:** What AD attributes are available?
|
||||
- Name, Email, Employee ID, Department, Designation, Manager?
|
||||
- Sample AD user object structure needed
|
||||
|
||||
- [ ] **Q9:** Service account credentials for AD queries?
|
||||
|
||||
---
|
||||
|
||||
### **4. SSO Integration Details**
|
||||
|
||||
From proposal: "Design a secure login page, which allow user to redirect to AD, System user login through AD"
|
||||
|
||||
- [ ] **Q10:** SSO endpoint URL and protocol?
|
||||
- OAuth 2.0 / SAML / Custom?
|
||||
|
||||
- [ ] **Q11:** Test SSO credentials for development?
|
||||
- Need 10-15 test users with different roles
|
||||
|
||||
- [ ] **Q12:** What user claims are returned in JWT token?
|
||||
- Example token payload needed
|
||||
|
||||
---
|
||||
|
||||
### **5. File Storage & Document Management**
|
||||
|
||||
SRS mentions: Max 10MB per file, supports PDF, Word, Excel, PPT, images
|
||||
|
||||
- [ ] **Q13:** Use Google Cloud Storage (GCS) for file uploads?
|
||||
- GCS bucket name?
|
||||
- Access credentials (Service Account JSON)?
|
||||
- Bucket configuration (public/private)?
|
||||
|
||||
- [ ] **Q14:** Total storage limit per request?
|
||||
- Individual file: 10MB
|
||||
- Total per request: 100MB? 500MB?
|
||||
|
||||
- [ ] **Q15:** File retention policy?
|
||||
- How long should documents be kept after request closure?
|
||||
|
||||
---
|
||||
|
||||
### **6. AI Service for Conclusion Remarks**
|
||||
|
||||
SRS mentions: "AI-generated conclusion remarks"
|
||||
|
||||
- [ ] **Q16:** Which AI service?
|
||||
- OpenAI GPT-4?
|
||||
- Azure OpenAI Service?
|
||||
- Google Gemini?
|
||||
- Self-hosted LLM?
|
||||
|
||||
- [ ] **Q17:** API credentials for AI service?
|
||||
|
||||
- [ ] **Q18:** Data privacy clearance?
|
||||
- Can request data be sent to external AI service?
|
||||
- Does it contain PII or sensitive information?
|
||||
|
||||
- [ ] **Q19:** Fallback if AI fails?
|
||||
- Manual remark entry by initiator?
|
||||
|
||||
---
|
||||
|
||||
### **7. Infrastructure Setup**
|
||||
|
||||
From SRS: 1 VM, 4-Core, 16GB RAM, 500GB, Ubuntu 24.04 LTS
|
||||
|
||||
- [ ] **Q20:** Is this VM already provisioned?
|
||||
- VM IP address / hostname?
|
||||
- SSH access credentials?
|
||||
|
||||
- [ ] **Q21:** Domain name for application?
|
||||
- Example: `workflow.royalenfield.com`
|
||||
- DNS configuration status?
|
||||
|
||||
- [ ] **Q22:** SSL certificate?
|
||||
- RE-provided certificate?
|
||||
- Or use Let's Encrypt?
|
||||
|
||||
- [ ] **Q23:** Should we use VM or serverless?
|
||||
- **Current spec:** 1 VM
|
||||
- **Alternative:** GCP Cloud Run (auto-scaling, pay-per-use)
|
||||
- **Recommendation:** Start with VM, move to Cloud Run if needed
|
||||
|
||||
---
|
||||
|
||||
### **8. Role-Based Access Control**
|
||||
|
||||
From proposal, multiple roles are mentioned (for other projects):
|
||||
- Admin, DD Lead, IT Team, ZM DD, RBM, ZBH, NBH, etc.
|
||||
|
||||
For Streamlined Approvals:
|
||||
- Initiator, Approver, Final Approver, Spectator, Admin
|
||||
|
||||
- [ ] **Q24:** Role list for Streamlined Approvals?
|
||||
- Is there an Admin role with super privileges?
|
||||
- What can Admin do that others cannot?
|
||||
|
||||
- [ ] **Q25:** User role assignment?
|
||||
- Managed in AD or in our application?
|
||||
- Can users have multiple roles?
|
||||
|
||||
---
|
||||
|
||||
### **9. Performance & Load Requirements**
|
||||
|
||||
SRS mentions: "Average response time < 3 seconds"
|
||||
|
||||
- [ ] **Q26:** Expected concurrent users?
|
||||
- 10 users? 100 users? 500 users?
|
||||
|
||||
- [ ] **Q27:** Expected request volume?
|
||||
- How many workflow requests per day/month?
|
||||
|
||||
- [ ] **Q28:** Peak usage times?
|
||||
- Should we plan for load spikes?
|
||||
|
||||
---
|
||||
|
||||
### **10. Testing & UAT**
|
||||
|
||||
From proposal: Functionality, Usability, Compatibility, Interface, Performance, Security testing
|
||||
|
||||
- [ ] **Q29:** QA team availability?
|
||||
- Dedicated QA resources?
|
||||
- QA contact person?
|
||||
|
||||
- [ ] **Q30:** UAT participants?
|
||||
- Need 5-10 end users for UAT
|
||||
- Names and availability?
|
||||
|
||||
- [ ] **Q31:** Test data creation?
|
||||
- Can we create dummy workflow requests?
|
||||
- Sample documents for upload testing?
|
||||
|
||||
---
|
||||
|
||||
### **11. Deployment & Go-Live**
|
||||
|
||||
From proposal: Waterfall methodology with phased delivery
|
||||
|
||||
- [ ] **Q32:** Deployment approach?
|
||||
- Phased rollout (pilot → org-wide)?
|
||||
- Or big-bang deployment?
|
||||
|
||||
- [ ] **Q33:** Pilot user group?
|
||||
- Which departments will pilot the system?
|
||||
- How many users in pilot?
|
||||
|
||||
- [ ] **Q34:** Target go-live date?
|
||||
- When should production be ready?
|
||||
|
||||
- [ ] **Q35:** Deployment window?
|
||||
- Business hours or after hours?
|
||||
- Weekend deployment preferred?
|
||||
|
||||
---
|
||||
|
||||
### **12. Communication & Governance**
|
||||
|
||||
From proposal:
|
||||
- Daily Scrum (10 mins)
|
||||
- Weekly Review (30 mins)
|
||||
- Monthly Governance (60 mins)
|
||||
|
||||
- [ ] **Q36:** Are these meeting frequencies acceptable?
|
||||
|
||||
- [ ] **Q37:** Communication channels?
|
||||
- Microsoft Teams / Slack / Email?
|
||||
- Dedicated project channel?
|
||||
|
||||
- [ ] **Q38:** Project management tool?
|
||||
- Proposal mentions: ZOHO PMS
|
||||
- Alternatives: Jira, Azure DevOps, Trello?
|
||||
|
||||
---
|
||||
|
||||
### **13. Security & Compliance**
|
||||
|
||||
From proposal - Security Measures:
|
||||
- JWT tokens
|
||||
- SSL certificates
|
||||
- API rate limiting
|
||||
- SQL injection protection
|
||||
- XSS protection
|
||||
- Session management
|
||||
|
||||
- [ ] **Q39:** Security audit requirements?
|
||||
- Penetration testing needed?
|
||||
- VAPT before go-live?
|
||||
|
||||
- [ ] **Q40:** Compliance standards?
|
||||
- GDPR, ISO 27001, SOC 2?
|
||||
|
||||
- [ ] **Q41:** Data retention policy?
|
||||
- How long should audit logs be kept?
|
||||
- Document retention period?
|
||||
|
||||
- [ ] **Q42:** Security contact person?
|
||||
- RE InfoSec team contact?
|
||||
|
||||
---
|
||||
|
||||
### **14. Support & Maintenance**
|
||||
|
||||
From proposal: Annual Maintenance and Support Services
|
||||
|
||||
- [ ] **Q43:** Is AMS (Annual Maintenance Support) in scope?
|
||||
- Or only initial development?
|
||||
|
||||
- [ ] **Q44:** Support SLA requirements?
|
||||
- Response time for critical issues?
|
||||
- Resolution time expectations?
|
||||
|
||||
- [ ] **Q45:** Warranty period?
|
||||
- How long is bug-fix warranty after go-live?
|
||||
- Proposal mentions: 2 weeks post-launch monitoring
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Recommended Technology Decision Matrix
|
||||
|
||||
| Decision Point | Option 1 | Option 2 | Recommendation | Reason |
|
||||
|---------------|----------|----------|----------------|---------|
|
||||
| Frontend | React.js | **Next.js** | ✅ Next.js | SSR, better performance, modern |
|
||||
| Backend | Express.js | **Fastify** | ✅ Express.js | More mature, larger community |
|
||||
| Database | **PostgreSQL** | MongoDB | ✅ PostgreSQL | Better for workflows, ACID compliance |
|
||||
| Language | JavaScript | **TypeScript** | ✅ TypeScript | Type safety, better for large projects |
|
||||
| ORM | Prisma | TypeORM | ✅ Prisma | Better DX, type-safe queries |
|
||||
| State Management | Redux | **Zustand** | ✅ Redux Toolkit | Industry standard, good for complex state |
|
||||
| Styling | Tailwind | **Tailwind + Shadcn** | ✅ Tailwind + Shadcn | Fast development, consistent UI |
|
||||
| Email | Internal SMTP | **SendGrid** | ⚠️ Need decision | Depends on RE IT policy |
|
||||
| AI Service | **OpenAI** | Azure OpenAI | ⚠️ Need decision | Depends on data privacy requirements |
|
||||
| Hosting | VM | Cloud Run | ✅ VM (initially) | As per SRS spec, can migrate later |
|
||||
| BPM Platform | Camunda | **Custom** | ✅ Custom | Better fit for non-templatized workflows |
|
||||
|
||||
---
|
||||
|
||||
## 📝 Next Steps
|
||||
|
||||
### **Immediate Actions (This Week):**
|
||||
|
||||
1. **Schedule Technical Kickoff Meeting** with RE stakeholders
|
||||
- Present this document
|
||||
- Get decisions on all conflicts
|
||||
- Finalize technology stack
|
||||
|
||||
2. **Create Shared Decision Log**
|
||||
- Document all technology decisions
|
||||
- Get sign-off from Product Owner and Tech Lead
|
||||
|
||||
3. **Request Critical Access**
|
||||
- SSO integration documentation
|
||||
- AD integration access method
|
||||
- Test user accounts (10-15 users)
|
||||
- Database credentials
|
||||
- GCP project access
|
||||
|
||||
4. **Set Up Development Environment**
|
||||
- Git repository creation
|
||||
- Local development setup guide
|
||||
- CI/CD pipeline planning
|
||||
|
||||
### **Week 2 Actions:**
|
||||
|
||||
1. **Finalize Architecture Document**
|
||||
- System architecture diagram
|
||||
- Database schema design
|
||||
- API endpoint specification
|
||||
- Security architecture
|
||||
|
||||
2. **Begin Sprint Planning**
|
||||
- Break down SRS into user stories
|
||||
- Estimate effort (story points)
|
||||
- Create sprint plan
|
||||
|
||||
---
|
||||
|
||||
## 📞 Key Stakeholders Needed for Decisions
|
||||
|
||||
| Decision Area | Stakeholder | Contact Needed |
|
||||
|--------------|-------------|----------------|
|
||||
| Technology Stack | CTO / Tech Lead | Email / Meeting |
|
||||
| SSO Integration | IT Infrastructure Team | Documentation + Credentials |
|
||||
| Email Service | IT Operations | SMTP config / approval |
|
||||
| Database Choice | Database Admin | Provisioning + credentials |
|
||||
| AI Service | Product Owner + Legal | Data privacy clearance |
|
||||
| Security | InfoSec Team | Security requirements doc |
|
||||
| Budget | Finance / Project Sponsor | AI API costs, cloud costs |
|
||||
|
||||
---
|
||||
|
||||
**Document Status:** ⚠️ DRAFT - Awaiting Stakeholder Review
|
||||
**Priority:** 🔴 CRITICAL - Blocks Development
|
||||
**Owner:** Development Team Lead
|
||||
**Review Date:** [To be scheduled]
|
||||
|
||||
---
|
||||
|
||||
## 📎 Appendix: Document References
|
||||
|
||||
1. **streamlined_approvals.md** - System Requirements Specification (SRS)
|
||||
2. **Royal Enfield Proposal 1.06.txt** - BPM Platform Approach Proposal
|
||||
3. **Figma Wireframe** - https://sway-dense-03017508.figma.site
|
||||
4. **RE_FULLSCOPE_AND PROJECT_STRUCTURE.md** - Overall project scope
|
||||
5. **RE_Workflow_Complete_Project_Setup.md** - Complete setup guide
|
||||
|
||||
|
||||
547
streamline_questions.md
Normal file
547
streamline_questions.md
Normal file
@ -0,0 +1,547 @@
|
||||
# RE Workflow Management - Clarification Questions
|
||||
**Non-Templatized Approval Workflows**
|
||||
|
||||
---
|
||||
|
||||
## 1. @Mention Behavior in Work Notes
|
||||
|
||||
**Q1.** If someone @mentions a user who is NOT a participant in Work Notes, what happens?
|
||||
- Option A: Auto-add them as a Spectator?
|
||||
- Option B: Send notification but don't add them?
|
||||
- Option C: Show error and prevent the mention?
|
||||
- Option D: Require explicit approval to add?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 2. Sequential vs Parallel Notification & Visibility
|
||||
|
||||
**Q2.1** When a request is submitted, who receives notifications?
|
||||
- Option A: Only the first approver (sequential)
|
||||
- Option B: All approvers and spectators (simultaneous)
|
||||
|
||||
**Q2.2** Can Approver Level 2 see the request before Level 1 approves it?
|
||||
- Option A: No - it appears only when it reaches their level
|
||||
- Option B: Yes - but marked as "Waiting for Level 1" and action buttons disabled
|
||||
|
||||
**Q2.3** What appears in "Open Requests" for different approvers?
|
||||
- For Level 1 Approver: Shows as "Action Required"
|
||||
- For Level 2 Approver (before Level 1 acts):
|
||||
- Option A: Request doesn't appear at all
|
||||
- Option B: Shows as "Waiting for previous level"
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 3. Request Creation - Alert & Notification System
|
||||
|
||||
### **Q3.1 - Initiator Notifications After Submission**
|
||||
|
||||
When initiator submits a request, what notifications/alerts do they receive?
|
||||
|
||||
- [ ] **Immediate confirmation:**
|
||||
- In-app notification: "Your request #12345 has been submitted successfully"
|
||||
- Email confirmation with request summary and tracking link?
|
||||
- Both?
|
||||
|
||||
- [ ] **Request submitted to whom:**
|
||||
- "Your request has been sent to [Approver Name] for Level 1 approval"?
|
||||
- Show approver name and expected TAT?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q3.2 - First Approver Notification**
|
||||
|
||||
When request is submitted, what does the FIRST approver receive?
|
||||
|
||||
**Notification Content:**
|
||||
- [ ] "New approval request #12345 from [Initiator Name]"
|
||||
- [ ] Include request title?
|
||||
- [ ] Include priority (Express/Standard)?
|
||||
- [ ] Include TAT deadline date/time?
|
||||
- [ ] Direct link to approve/view request?
|
||||
|
||||
**Notification Channels:**
|
||||
- [ ] In-app notification (bell icon)?
|
||||
- [ ] Email notification?
|
||||
- [ ] Both?
|
||||
|
||||
**Notification Timing:**
|
||||
- [ ] Immediate (within seconds of submission)?
|
||||
- [ ] Batched (every 15 mins, every hour)?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q3.3 - Spectator Notifications After Submission**
|
||||
|
||||
When request is submitted, what do SPECTATORS receive?
|
||||
|
||||
**Notification Content:**
|
||||
- [ ] "You've been added as a spectator to request #12345"?
|
||||
- [ ] Include request summary and purpose?
|
||||
- [ ] Link to view request?
|
||||
|
||||
**Notification Channels:**
|
||||
- [ ] In-app notification?
|
||||
- [ ] Email notification?
|
||||
- [ ] Both?
|
||||
|
||||
**Can spectators opt-out of notifications:**
|
||||
- [ ] Yes - they can mute specific requests?
|
||||
- [ ] No - mandatory notifications?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q3.4 - Draft Auto-Save Notifications**
|
||||
|
||||
When user is creating a request (before submission):
|
||||
|
||||
- [ ] **Auto-save behavior:**
|
||||
- Auto-save every 30 seconds?
|
||||
- Auto-save on field change (debounced)?
|
||||
- Manual save only?
|
||||
|
||||
- [ ] **Auto-save notification:**
|
||||
- Show "Saved as draft" toast message?
|
||||
- Show "Last saved at 10:45 AM" timestamp?
|
||||
- Silent save (no notification)?
|
||||
|
||||
- [ ] **Draft recovery:**
|
||||
- If user closes browser, show "You have an unsaved draft" on next login?
|
||||
- Auto-recover draft?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 4. Approval Process - Notification & Alert Flow
|
||||
|
||||
### **Q4.1 - Approver Action Required Reminders**
|
||||
|
||||
When a request is pending at an approver's level:
|
||||
|
||||
**Initial Notification:**
|
||||
- [ ] Sent immediately when request reaches their level?
|
||||
- [ ] Include TAT deadline?
|
||||
|
||||
**Reminder Schedule (if no action taken):**
|
||||
- [ ] Reminder at 50% TAT elapsed?
|
||||
- [ ] Reminder at 75% TAT elapsed?
|
||||
- [ ] Reminder at 90% TAT elapsed?
|
||||
- [ ] Reminder at 100% TAT (deadline reached)?
|
||||
- [ ] Reminder at 110% TAT (breached)?
|
||||
|
||||
**Reminder Frequency After Breach:**
|
||||
- [ ] Daily reminder after TAT breach?
|
||||
- [ ] Every 12 hours?
|
||||
- [ ] No more reminders after initial breach notification?
|
||||
|
||||
**Escalation After Multiple Reminders:**
|
||||
- [ ] After 3 reminders with no action, notify approver's manager?
|
||||
- [ ] Auto-escalate to next level after X hours of inactivity?
|
||||
- [ ] No auto-escalation, just keep reminding?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q4.2 - TAT Approaching/Breached Visual Indicators**
|
||||
|
||||
For approvers viewing their pending requests:
|
||||
|
||||
**Visual Indicators:**
|
||||
- [ ] Color-coded TAT bar:
|
||||
- Green: Within 50% TAT
|
||||
- Yellow: 50-90% TAT elapsed
|
||||
- Orange: 90-100% TAT elapsed
|
||||
- Red: TAT breached
|
||||
|
||||
- [ ] TAT countdown timer:
|
||||
- "2 hours 30 minutes remaining"
|
||||
- "Due in 2 days"
|
||||
- "Overdue by 5 hours" (if breached)
|
||||
|
||||
- [ ] Badge on request card:
|
||||
- "URGENT" badge if approaching deadline?
|
||||
- "OVERDUE" badge if breached?
|
||||
|
||||
**Sorting Priority:**
|
||||
- [ ] Auto-sort pending requests by TAT urgency (most urgent first)?
|
||||
- [ ] Separate "Overdue" section at top?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q4.3 - Approval Action Confirmation**
|
||||
|
||||
When approver clicks "Approve" button:
|
||||
|
||||
**Confirmation Required:**
|
||||
- [ ] Show confirmation popup before approving?
|
||||
- "Are you sure you want to approve request #12345?"
|
||||
- "This action cannot be undone" (or can it?)
|
||||
|
||||
- [ ] Or immediate approval (no confirmation)?
|
||||
|
||||
**Mandatory Comments:**
|
||||
- [ ] Must approver enter comments when approving?
|
||||
- [ ] Or comments optional on approval (mandatory only on rejection)?
|
||||
|
||||
**After Approval Action:**
|
||||
- [ ] Show success message: "Request approved successfully"?
|
||||
- [ ] Redirect to next pending request?
|
||||
- [ ] Stay on same request to see updated status?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q4.4 - Who Gets Notified When Level 1 Approves?**
|
||||
|
||||
When Level 1 approver APPROVES the request:
|
||||
|
||||
**Notifications Sent To:**
|
||||
- [ ] **Initiator:**
|
||||
- "Your request #12345 has been approved by [Approver 1 Name]"?
|
||||
- Include approver's comments?
|
||||
- Notify that it's moving to Level 2?
|
||||
|
||||
- [ ] **Level 2 Approver:**
|
||||
- "New approval request #12345 is now awaiting your action"?
|
||||
- Include Level 1 approval comments?
|
||||
- Include updated TAT for their level?
|
||||
|
||||
- [ ] **Spectators:**
|
||||
- "Request #12345 approved by Level 1, now at Level 2"?
|
||||
- Or silent update (no notification)?
|
||||
|
||||
- [ ] **Previous Approvers (Level 1):**
|
||||
- Confirmation notification: "Your approval for #12345 has been recorded"?
|
||||
- Or no notification after action taken?
|
||||
|
||||
**Notification Channels:**
|
||||
- [ ] In-app notification?
|
||||
- [ ] Email notification?
|
||||
- [ ] Both?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q4.5 - Who Gets Notified When Approver REJECTS?**
|
||||
|
||||
When ANY approver REJECTS the request:
|
||||
|
||||
**Notifications Sent To:**
|
||||
- [ ] **Initiator:**
|
||||
- "Your request #12345 has been rejected by [Approver Name]"?
|
||||
- Include rejection reason/comments (mandatory)?
|
||||
- Include what actions initiator can take (resubmit, modify, close)?
|
||||
|
||||
- [ ] **All Spectators:**
|
||||
- "Request #12345 has been rejected"?
|
||||
- Include rejection reason?
|
||||
|
||||
- [ ] **Previous Approvers:**
|
||||
- Notify that request was rejected downstream?
|
||||
- Or no notification (workflow ended)?
|
||||
|
||||
- [ ] **Subsequent Approvers (Level 3, 4...):**
|
||||
- Remove request from their pending list?
|
||||
- Notify that request was rejected before reaching them?
|
||||
|
||||
**Rejection Behavior:**
|
||||
- [ ] Request immediately closed (cannot be reopened)?
|
||||
- [ ] Request goes back to initiator as "Draft" for modification?
|
||||
- [ ] Request goes back to previous approver level?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q4.6 - Final Approval & Closure Notifications**
|
||||
|
||||
When FINAL approver approves (last level in hierarchy):
|
||||
|
||||
**Notifications Sent To:**
|
||||
- [ ] **Initiator:**
|
||||
- "Your request #12345 has been fully approved!"?
|
||||
- Include AI-generated conclusion summary?
|
||||
- Prompt to add closure remarks?
|
||||
|
||||
- [ ] **All Previous Approvers:**
|
||||
- "Request #12345 has completed all approvals"?
|
||||
- Or no notification?
|
||||
|
||||
- [ ] **All Spectators:**
|
||||
- "Request #12345 has been fully approved and closed"?
|
||||
|
||||
**Closure Workflow:**
|
||||
- [ ] Request automatically marked as "Approved" (closed)?
|
||||
- [ ] Request returns to initiator for final closure remarks?
|
||||
- [ ] Initiator must explicitly mark as "Closed" after reviewing?
|
||||
|
||||
**Conclusion Remark:**
|
||||
- [ ] AI-generated conclusion sent immediately to initiator?
|
||||
- [ ] Generated when initiator opens closure screen?
|
||||
- [ ] Initiator can edit/regenerate AI conclusion?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 5. Approval Process - Mid-Workflow Actions
|
||||
|
||||
### **Q5.1 - Adding Approver Mid-Workflow**
|
||||
|
||||
If an approver wants to add another approver at their level or before their level:
|
||||
|
||||
**Behavior:**
|
||||
- [ ] **Insert Before Current Level:**
|
||||
- New approver added between Level 1 and Level 2?
|
||||
- Request goes back to new approver?
|
||||
- Or new approver acts in parallel?
|
||||
|
||||
- [ ] **Add at Current Level (Parallel):**
|
||||
- Both must approve before moving to next level?
|
||||
- Or either can approve?
|
||||
|
||||
- [ ] **Add After Current Level:**
|
||||
- New approver added as Level 3 (shifting existing levels)?
|
||||
|
||||
**Notifications:**
|
||||
- [ ] Notify new approver immediately?
|
||||
- [ ] Notify initiator that approval hierarchy changed?
|
||||
- [ ] Notify all spectators?
|
||||
|
||||
**TAT Impact:**
|
||||
- [ ] Does adding new approver extend total TAT?
|
||||
- [ ] Or new approver shares existing level TAT?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q5.2 - Request Stuck at Approver (TAT Breached)**
|
||||
|
||||
When request TAT is breached at an approver level:
|
||||
|
||||
**Auto-Actions:**
|
||||
- [ ] **Auto-escalate to approver's manager:**
|
||||
- Notify manager to follow up?
|
||||
- Manager can approve on behalf?
|
||||
- Or manager can only remind?
|
||||
|
||||
- [ ] **Auto-reassign to alternate approver:**
|
||||
- If primary approver is inactive/on leave?
|
||||
- Based on delegation rules?
|
||||
|
||||
- [ ] **No auto-action:**
|
||||
- Just send repeated reminders?
|
||||
- Manual escalation required?
|
||||
|
||||
**Visibility:**
|
||||
- [ ] Show "OVERDUE" badge to all participants?
|
||||
- [ ] Send escalation notification to initiator?
|
||||
- [ ] Notify admin/system owner?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q5.3 - Approver on Leave/Unavailable**
|
||||
|
||||
If assigned approver is on leave when request reaches them:
|
||||
|
||||
**System Behavior:**
|
||||
- [ ] **Check leave calendar:**
|
||||
- System checks if approver is on leave?
|
||||
- Auto-skip to delegate if on leave?
|
||||
|
||||
- [ ] **Delegation mechanism:**
|
||||
- Does approver pre-configure delegate before going on leave?
|
||||
- Auto-delegate to manager if no delegate configured?
|
||||
- Or request stays pending until approver returns?
|
||||
|
||||
- [ ] **No delegation:**
|
||||
- Request stays pending (TAT keeps running)?
|
||||
- Show warning: "Approver is currently on leave"?
|
||||
|
||||
**Notifications:**
|
||||
- [ ] Notify delegate when request is auto-delegated?
|
||||
- [ ] Notify initiator about delay due to leave?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 6. Notification Preferences & Settings
|
||||
|
||||
### **Q6.1 - User Notification Preferences**
|
||||
|
||||
Can users customize which notifications they receive?
|
||||
|
||||
**Customization Options:**
|
||||
- [ ] **Turn off email notifications:**
|
||||
- Receive only in-app notifications?
|
||||
- Turn off entirely (not recommended)?
|
||||
|
||||
- [ ] **Notification frequency:**
|
||||
- Immediate (real-time)?
|
||||
- Digest (once per day summary)?
|
||||
- Custom frequency?
|
||||
|
||||
- [ ] **Notification types:**
|
||||
- Opt-out of spectator notifications?
|
||||
- Only notify for urgent requests?
|
||||
- Only notify for requests where I'm approver (not spectator)?
|
||||
|
||||
**Default Settings:**
|
||||
- [ ] All notifications ON by default?
|
||||
- [ ] User can change in profile settings?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q6.2 - Notification Delivery Failure Handling**
|
||||
|
||||
If notification fails to deliver (email bounces, user not found):
|
||||
|
||||
**System Behavior:**
|
||||
- [ ] Retry delivery (how many times)?
|
||||
- [ ] Log failed notification?
|
||||
- [ ] Alert admin/system owner?
|
||||
- [ ] Show warning in UI: "Email notification failed to send"?
|
||||
|
||||
**Fallback:**
|
||||
- [ ] If email fails, ensure in-app notification works?
|
||||
- [ ] SMS notification as fallback (if configured)?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 7. Bulk Operations & Multiple Requests
|
||||
|
||||
### **Q7.1 - Approver with Multiple Pending Requests**
|
||||
|
||||
If an approver has 10+ requests pending:
|
||||
|
||||
**Bulk Actions:**
|
||||
- [ ] **Can approver approve multiple requests at once:**
|
||||
- Select 5 requests → Click "Approve All"?
|
||||
- Or must approve each individually?
|
||||
|
||||
- [ ] **Bulk comments:**
|
||||
- Single comment applied to all selected requests?
|
||||
- Or individual comments required?
|
||||
|
||||
**Sorting/Filtering:**
|
||||
- [ ] Sort pending requests by TAT urgency?
|
||||
- [ ] Filter by priority (Express first)?
|
||||
- [ ] Group by initiator/department?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q7.2 - Notification Batching**
|
||||
|
||||
If many actions happen in short time (e.g., 5 requests submitted to same approver in 5 minutes):
|
||||
|
||||
**Notification Behavior:**
|
||||
- [ ] **Send individual notifications:**
|
||||
- 5 separate emails/notifications?
|
||||
|
||||
- [ ] **Batch notifications:**
|
||||
- Single notification: "You have 5 new approval requests"?
|
||||
- Batching window: 15 minutes?
|
||||
|
||||
- [ ] **Smart batching:**
|
||||
- If >3 notifications in 10 mins, batch them?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## 8. Edge Cases & Error Scenarios
|
||||
|
||||
### **Q8.1 - Request Submitted with No Approvers**
|
||||
|
||||
If user tries to submit request without defining any approvers:
|
||||
|
||||
**System Behavior:**
|
||||
- [ ] Block submission with error: "At least one approver required"?
|
||||
- [ ] Allow submission (self-approved workflow)?
|
||||
- [ ] Auto-assign default approver (manager)?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q8.2 - Approver Approves Then Tries to Undo**
|
||||
|
||||
If approver accidentally approves and wants to undo:
|
||||
|
||||
**Undo Mechanism:**
|
||||
- [ ] **Grace period for undo:**
|
||||
- Allow undo within 5 minutes?
|
||||
- Show "Undo Approval" button for 5 mins?
|
||||
|
||||
- [ ] **No undo:**
|
||||
- Once approved, cannot undo?
|
||||
- Must contact admin/system owner?
|
||||
|
||||
- [ ] **Undo conditions:**
|
||||
- Can only undo if next level hasn't acted yet?
|
||||
- Cannot undo if workflow moved forward?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
### **Q8.3 - Notification System Down**
|
||||
|
||||
If notification service (email/in-app) is temporarily down:
|
||||
|
||||
**System Behavior:**
|
||||
- [ ] Queue notifications for retry?
|
||||
- [ ] Log missed notifications?
|
||||
- [ ] Show banner: "Notifications are temporarily unavailable"?
|
||||
- [ ] Send catch-up notifications when service restores?
|
||||
|
||||
**Decision:** _______________________
|
||||
|
||||
---
|
||||
|
||||
## Summary: Decisions Required
|
||||
|
||||
This document contains **30+ clarification questions** specifically about:
|
||||
- Request creation alerts (Q3.1 - Q3.4)
|
||||
- Approval process notifications (Q4.1 - Q4.6)
|
||||
- Mid-workflow actions (Q5.1 - Q5.3)
|
||||
- Notification preferences (Q6.1 - Q6.2)
|
||||
- Bulk operations (Q7.1 - Q7.2)
|
||||
- Edge cases (Q8.1 - Q8.3)
|
||||
|
||||
**Next Steps:**
|
||||
1. Review each question with stakeholders
|
||||
2. Make decisions and document
|
||||
3. Update technical specifications accordingly
|
||||
4. Design notification architecture based on decisions
|
||||
|
||||
---
|
||||
|
||||
**Document Owner:** Development Team
|
||||
**Status:** ⚠️ AWAITING STAKEHOLDER DECISIONS
|
||||
**Priority:** 🔴 HIGH - Affects core user experience and system behavior
|
||||
Loading…
Reference in New Issue
Block a user