I’ve received the complete HRMS SRS and delivery package. What would you like me to produce from it—for example, a polished DOCX/PDF, a requirements review and gap analysis, or a developer-ready implementation plan?

নিচের নথিটি Development Kickoff-এর ভিত্তি হিসেবে ব্যবহার করা যাবে। এতে প্রথমে build-blocking gap, তারপর recommended technical decisions, architecture, sprint plan, testing এবং release criteria দেওয়া হয়েছে।

:::writing{variant="document" id="48317"}

HRMS Requirements Review, Gap Analysis এবং Developer-ready Implementation Plan

ডকুমেন্ট সংস্করণ: 1.0
প্রযোজ্য পরিধি: HRMS Web App, Mobile App এবং Backend Platform
প্রধান লক্ষ্য: Development শুরুর আগে অস্পষ্টতা, business-rule gap, security risk এবং architecture risk শনাক্ত করা এবং একটি বাস্তবায়নযোগ্য delivery plan নির্ধারণ করা।

Part A: Requirements Review and Gap Analysis

1. Executive assessment

বর্তমান SRS একটি শক্তিশালী product foundation তৈরি করেছে। এতে প্রয়োজনীয় module, user role, screen flow, core entity, high-level API, backlog এবং release plan অন্তর্ভুক্ত আছে।

তবে এটি এখনো সরাসরি coding শুরু করার মতো সম্পূর্ণ developer-ready নয়। প্রধান ঘাটতিগুলো হলো:

1. MVP scope-এর কিছু অংশ পরস্পরবিরোধী।
2. Multi-company বা tenant isolation স্পষ্টভাবে সংজ্ঞায়িত নয়।
3. Role এবং permission model যথেষ্ট granular নয়।
4. Attendance ও leave calculation-এর গুরুত্বপূর্ণ business rule অনুপস্থিত।
5. Approval workflow-এর state এবং escalation rule নির্ধারিত নয়।
6. বর্তমান ER model কিছু গুরুত্বপূর্ণ relationship সঠিকভাবে উপস্থাপন করছে না।
7. API specification এখনো পূর্ণ contract নয়।
8. Security, availability এবং performance requirements পরিমাপযোগ্য নয়।
9. Mobile GPS attendance-এর privacy এবং fraud-control requirement অসম্পূর্ণ।
10. Testing, deployment, migration এবং production monitoring-এর acceptance criteria নেই।

সামগ্রিক সিদ্ধান্ত

Development শুরু করা যাবে, তবে প্রথমে একটি Sprint 0 বা Foundation Sprint সম্পন্ন করা প্রয়োজন। এই sprint-এ scope, data model, permission matrix, workflow state এবং technical architecture lock করতে হবে।

2. Priority classification

3. P0 build-blocking gaps

GAP-01: MVP scope-এ পরস্পরবিরোধিতা

SRS-এর এক অংশে recruitment, onboarding, payroll এবং performance management-কে Phase 2 বলা হয়েছে। আবার required web sections-এ এগুলোকে আবশ্যিক screen হিসেবে দেখানো হয়েছে।

Employee self-service-এর মধ্যে payslip access রয়েছে, কিন্তু payroll MVP-এর বাইরে। একইভাবে reports export এক জায়গায় MVP scope-এর অংশ, অন্য জায়গায় future iteration বলা হয়েছে।

ঝুঁকি

• UI team এবং backend team ভিন্ন scope ধরে কাজ করতে পারে।
• MVP estimate এবং delivery date ভুল হতে পারে।
• অসম্পূর্ণ menu বা dead-end screen তৈরি হতে পারে।

Recommended decision

MVP-তে শুধুমাত্র নিচের module সক্রিয় থাকবে:

• Authentication এবং access control
• Organization setup
• Employee management
• Attendance
• Attendance correction
• Leave management
• Employee self-service
• Notifications
• Announcements
• Basic reports
• Documents-এর সীমিত read/upload capability
• Web এবং mobile core workflows

নিচের module-এর menu, API এবং database functionality Phase 2 feature flag-এর পেছনে থাকবে:

• Recruitment
• Onboarding
• Payroll
• Performance management
• Asset management

Payslip screen MVP-তে প্রদর্শিত হবে না, যদি না external payroll system থেকে payslip upload করার একটি স্পষ্ট requirement যোগ করা হয়।

Report export-এর ক্ষেত্রে MVP baseline হবে:

• CSV/XLSX export: MVP
• PDF export: optional বা Phase 1.1

GAP-02: Tenant বা company isolation model অনির্ধারিত

SRS-এ Company entity আছে, কিন্তু system single-company deployment হবে নাকি SaaS multi-tenant platform হবে তা বলা হয়নি।

ঝুঁকি

এক organization-এর employee, attendance বা payroll data অন্য organization-এর user-এর কাছে প্রকাশিত হওয়ার সম্ভাবনা তৈরি হবে।

Recommended decision

Platform-কে শুরু থেকেই multi-tenant capable হিসেবে design করতে হবে, এমনকি প্রথম deployment-এ একটি company থাকলেও।

প্রত্যেক business table-এ সরাসরি বা নির্ভরযোগ্য relational path-এর মাধ্যমে company_id থাকতে হবে।

প্রয়োজনীয় নিয়ম:

• Company context authenticated token থেকে নির্ধারিত হবে।
• Client request থেকে পাঠানো companyId বিশ্বাস করা যাবে না।
• প্রতিটি query server-side tenant scope প্রয়োগ করবে।
• Super Admin-এর cross-company access আলাদা privileged permission হবে।
• Unique constraint company scope অনুযায়ী হবে।

উদাহরণ:

text
UNIQUE(company_id, employee_code)
UNIQUE(company_id, email)
UNIQUE(company_id, department_name)

GAP-03: Role এবং permission model অপর্যাপ্ত

বর্তমান Role.permission_set string-based field production-grade RBAC-এর জন্য যথেষ্ট নয়।

Manager কোন employee দেখতে পারবেন, branch admin কোন branch পরিচালনা করবেন এবং payroll user কোন salary data দেখতে পারবেন—এগুলোর data scope নির্ধারিত হয়নি।

Recommended model

নিচের entity প্রয়োজন:

• roles
• permissions
• role_permissions
• user_role_assignments
• role_scope_assignments

Permission format হতে পারে:

text
employee.read
employee.create
employee.update
attendance.read.team
attendance.correct
leave.approve
leave.override
document.read.salary
payroll.finalize
settings.manage
audit.read

Permission-এর সঙ্গে scope যুক্ত থাকতে হবে:

• Own
• Direct reports
• Reporting hierarchy
• Department
• Branch
• Company
• Global

শুধু UI menu লুকানো authorization নয়। প্রতিটি API endpoint এবং data query-তে server-side authorization প্রয়োজন।

GAP-04: User এবং Employee relationship ভুলভাবে কঠোর

বর্তমান ER diagram-এ USER ||--|| EMPLOYEE বাধ্যতামূলক one-to-one relationship দেখানো হয়েছে।

কিন্তু বাস্তবে:

• Employee record account invitation-এর আগে তৈরি হতে পারে।
• Super Admin user employee নাও হতে পারেন।
• Recruiter বা external payroll user employee নাও হতে পারেন।
• Terminated employee record থাকবে, কিন্তু user account disabled হতে পারে।

Recommended relationship

text
User 0..1 ---- 0..1 Employee

আরও ভালো model:

• users: authentication identity
• employees: HR identity
• user_employee_links: প্রয়োজন হলে explicit mapping
• employment_records: employment lifecycle
• user_sessions: active sessions
• external_identities: Google/Microsoft SSO mapping

GAP-05: Approval workflow সংজ্ঞায়িত নয়

Leave এবং attendance correction-এর জন্য multi-level approval বলা হয়েছে, কিন্তু নিচের নিয়মগুলো নেই:

• Approver কীভাবে নির্ধারিত হবে?
• Manager অনুপস্থিত থাকলে কী হবে?
• একই employee-এর জন্য একাধিক approver থাকলে sequence কী?
• HR override করলে original approver-এর status কী হবে?
• Request withdraw বা cancel করা যাবে কি?
• Approval deadline বা escalation থাকবে কি?
• Approver নিজের request approve করতে পারবেন কি?

Recommended workflow model

Shared approval engine ব্যবহার করা উচিত:

• approval_definitions
• approval_definition_steps
• approval_instances
• approval_instance_steps
• approval_actions

প্রাথমিক MVP rule:

1. Employee request submit করবেন।
2. প্রথম approver হবেন active primary manager।
3. Policy অনুযায়ী HR second-level approver হতে পারবেন।
4. Approver নিজের request approve করতে পারবেন না।
5. Pending request employee withdraw করতে পারবেন।
6. Approved leave শুরু হওয়ার আগে cancellation request করা যাবে।
7. HR override-এর জন্য আলাদা permission এবং mandatory reason প্রয়োজন।
8. প্রতিটি action audit log-এ থাকবে।

GAP-06: Attendance calculation rules অসম্পূর্ণ

বর্তমান requirements সাধারণ day shift-এর জন্য যথেষ্ট, কিন্তু production attendance system-এর জন্য নিচের rule অনুপস্থিত:

• Overnight shift
• Split shift
• Break in এবং break out
• Multiple check-in attempt
• Missing check-out
• Weekend work
• Holiday work
• Shift change
• Grace period calculation
• Overtime approval
• Employee timezone বনাম branch timezone
• Device clock manipulation
• Duplicate mobile submission
• Offline submission
• Remote employee location policy

Recommended baseline

Attendance data দুই স্তরে রাখতে হবে:

Raw attendance events

text
attendance_events
- check_in
- check_out
- break_start
- break_end
- manual_adjustment

Calculated daily record

text
attendance_days
- work_date
- first_check_in
- last_check_out
- worked_minutes
- late_minutes
- early_exit_minutes
- overtime_minutes
- status
- calculation_version

গুরুত্বপূর্ণ নিয়ম:

• Server timestamp হবে authoritative timestamp।
• Client timestamp আলাদাভাবে diagnostic field হিসেবে রাখা যাবে।
• প্রতিটি mobile action-এ idempotency key ব্যবহার করতে হবে।
• Overnight shift-এর work_date shift start date অনুযায়ী নির্ধারণ করতে হবে।
• Missing punch record incomplete status পাবে।
• Overtime payroll-এ পাঠানোর আগে approved হতে হবে।
• GPS-এর সঙ্গে accuracy radius সংরক্ষণ করতে হবে।
• Location unavailable হলে policy অনুযায়ী block, warning বা exception flow চালু হবে।

GAP-07: Leave balance engine-এর accounting model অনুপস্থিত

শুধু LeaveBalance table ব্যবহার করলে accrual, carry-forward, adjustment, cancellation এবং historical reconciliation কঠিন হবে।

Recommended model

Leave balance একটি immutable ledger থেকে গণনা করতে হবে।

text
leave_ledger
- opening_balance
- accrual
- approved_leave
- cancellation_reversal
- expiry
- manual_adjustment
- carry_forward

প্রয়োজনীয় business rules:

• Accrual monthly, annual বা joining anniversary ভিত্তিক হতে পারে।
• Mid-year joining-এর জন্য proration rule প্রয়োজন।
• Probation period-এ leave eligibility নির্ধারণ করতে হবে।
• Negative balance allowed কি না নির্ধারণ করতে হবে।
• Unpaid leave balance ছাড়াই apply করা যাবে।
• Half-day-এর পাশাপাশি hourly বা quarter-day support প্রয়োজন কি না নির্ধারণ করতে হবে।
• Holiday ও weekend leave duration-এ count হবে কি না policy-driven হতে হবে।
• Approved leave cancel হলে ledger reversal তৈরি হবে।
• Termination-এর সময় unused leave handling policy প্রয়োজন।
• Leave balance backdated edit করলে recalculation এবং audit প্রয়োজন।

GAP-08: Measurable non-functional requirements নেই

“Quickly”, “minimal delay” এবং “responsive” testable acceptance criteria নয়।

Recommended initial NFR baseline

এই সংখ্যাগুলো capacity test-এর পরে সংশোধন করা যাবে:

• সাধারণ read API-এর p95 response time: সর্বোচ্চ 500 ms
• সাধারণ write API-এর p95 response time: সর্বোচ্চ 800 ms
• Clock-in/out end-to-end response: সর্বোচ্চ 2 seconds
• Dashboard initial load: সর্বোচ্চ 3 seconds under normal load
• Monthly production availability target: 99.9%
• Recovery Point Objective: সর্বোচ্চ 15 minutes
• Recovery Time Objective: সর্বোচ্চ 2 hours
• Critical actions-এর audit persistence: transaction-এর অংশ
• Large report export: asynchronous job
• File upload size এবং allowed type explicit configuration
• Tenant isolation test: mandatory release gate
• Accessibility target: WCAG 2.1 AA baseline
• Date/time storage: UTC timestamp এবং separate local work date

4. P1 high-priority gaps

4.1 Employee lifecycle

বর্তমান status list আছে, কিন্তু lifecycle transition rule নেই।

প্রস্তাবিত state:

text
draft
invited
probation
active
notice
resigned
terminated
archived

Account status এবং employment status আলাদা রাখতে হবে।

উদাহরণ:

• Employee notice status-এ থেকেও login করতে পারবেন।
• Employee terminated হলে policy অনুযায়ী account disable হবে।
• Rehire করলে পুরোনো employee record overwrite না করে নতুন employment record তৈরি করতে হবে।
• Department, designation, salary band এবং manager পরিবর্তন effective-dated history হিসেবে রাখতে হবে।

প্রয়োজনীয় additional tables:

• employment_records
• employee_assignments
• employee_manager_history
• employee_status_history

4.2 Employee code generation

Unique employee ID generation উল্লেখ করা হয়েছে, কিন্তু format বা concurrency rule নেই।

Recommended configuration:

text
Prefix: EMP
Sequence: 000001
Scope: Company বা Branch
Example: EMP-000123

Database sequence বা transactional counter ব্যবহার করতে হবে। Application-side “last number + 1” ব্যবহার করা যাবে না।

4.3 Organization structure history

Employee transfer হলে পুরোনো attendance ও reports কোন branch/department-এ গণনা হবে তা নির্ধারিত নয়।

Recommended rule:

• Current profile বর্তমান assignment দেখাবে।
• Historical report event date-এর effective assignment ব্যবহার করবে।
• Transfer history কখনো overwrite করা যাবে না।

4.4 Leave request day breakdown

শুধু start date এবং end date রাখলে half-day, holiday exclusion এবং mixed-duration leave support করা কঠিন।

প্রয়োজন:

text
leave_requests
leave_request_days

leave_request_days-এ থাকতে পারে:

• leave_date
• duration
• deducted_units
• holiday_flag
• weekend_flag
• policy_result

4.5 Holiday calendar assignment

Holiday শুধু company-level entity হিসেবে যথেষ্ট নয়।

প্রয়োজন:

• Holiday calendar
• Calendar entries
• Branch assignment
• Employee group assignment
• Optional holiday selection
• Regional holiday override

4.6 Shift assignment

Shift entity আছে, কিন্তু employee-এর shift history নেই।

প্রয়োজন:

• shift_assignments
• effective_from
• effective_to
• assignment_type
• rotation_pattern

Shift পরিবর্তন historical attendance recalculation করবে কি না, সেটিও rule হিসেবে নির্ধারণ করতে হবে।

4.7 GPS attendance privacy ও abuse control

GPS attendance-এর জন্য প্রয়োজন:

• Employee consent notice
• Location permission handling
• Location retention period
• Geofence radius
• Accuracy threshold
• Mock-location detection policy
• Location capture failure behavior
• HR access restriction
• Location export restriction
• Audit trail

Location data প্রয়োজনের অতিরিক্ত সময় সংরক্ষণ করা উচিত নয়।

4.8 Notification delivery model

বর্তমানে notification entity আছে, কিন্তু channel delivery tracking নেই।

Recommended model:

• notifications: user-facing message
• notification_deliveries: push/email/in-app channel result
• device_tokens: mobile push registration
• notification_preferences
• notification_templates

Delivery status:

text
queued
sent
delivered
failed
read

Domain event এবং transactional outbox pattern ব্যবহার করলে database commit হওয়ার আগে notification চলে যাওয়ার ঝুঁকি কমবে।

4.9 Documents এবং file security

Employee document upload-এর জন্য নিচের requirement প্রয়োজন:

• Allowed file type
• Maximum size
• Virus বা malware scan
• File category
• Expiry date
• Document owner
• Visibility scope
• Version
• Retention policy
• Signed download URL
• Download audit
• Sensitive document classification

ফাইল সরাসরি public URL দিয়ে serve করা যাবে না।

4.10 Audit log specification

Audit log শুধু “record sensitive changes” বললে যথেষ্ট নয়।

প্রতিটি log-এ থাকতে হবে:

• Actor user
• Company
• Action
• Resource type
• Resource ID
• Before value
• After value
• Request ID
• IP address
• Device বা user agent
• Timestamp
• Override reason
• Impersonation context

Password, token এবং অত্যন্ত sensitive value audit payload-এ রাখা যাবে না।

Audit log সাধারণ admin user পরিবর্তন বা delete করতে পারবেন না।

4.11 Reporting definitions

“Present”, “Absent”, “Late” এবং “Headcount” metric-এর calculation definition প্রয়োজন।

উদাহরণ:

• Headcount কি selected date-এর active employment count?
• Approved leave কি absent count থেকে বাদ যাবে?
• Missing check-out কি present নাকি exception?
• Holiday-তে clock-in করলে present নাকি holiday-work?
• Department report current department নাকি historical assignment ব্যবহার করবে?

প্রতিটি report-এর data dictionary তৈরি করতে হবে।

4.12 API specification gap

বর্তমান API section endpoint inventory হিসেবে ভালো, কিন্তু developer contract হিসেবে অসম্পূর্ণ।

নিচের বিষয়গুলো প্রতিটি endpoint-এ প্রয়োজন:

• Authorization permission
• Request schema
• Response schema
• Validation rules
• Business error codes
• Pagination behavior
• Sorting behavior
• Idempotency rule
• Audit behavior
• Rate limit
• State transition
• Example success response
• Example error response

5. ER model corrections

5.1 Designation tenant ownership

DESIGNATION table-এ company_id প্রয়োজন।

5.2 Role normalization

permission_set string বাদ দিয়ে normalized permission tables ব্যবহার করতে হবে।

5.3 Attendance work date

ATTENDANCE_RECORD-এ explicit work_date প্রয়োজন।

5.4 Payslip component relationship

একটি payslip-এ অনেক salary component এবং একই component অনেক payslip-এ থাকতে পারে।

সঠিক model:

text
payslips
payslip_line_items
salary_components

5.5 Employee document schema

প্রয়োজনীয় field:

text
file_asset_id
document_type
document_number
issued_on
expires_on
visibility
verification_status
version

5.6 Manager relationship

শুধু manager_employee_id current manager দেখাতে পারে, history নয়। Historical reporting-এর জন্য আলাদা manager assignment table প্রয়োজন।

5.7 Notification schema

Employee-এর সঙ্গে direct notification relationship যথেষ্ট নয়। User account এবং device delivery relationship প্রয়োজন।

5.8 Candidate conversion

Candidate থেকে employee conversion-এর ক্ষেত্রে duplicate email, previous application এবং offer acceptance state define করতে হবে।

5.9 Soft delete

Soft delete ব্যবহার করা হলেও unique constraint এবং restore behavior স্পষ্ট হতে হবে। Audit-critical data physical delete করা উচিত নয়।

6. Security gaps

নিচের security controls requirement-এ যুক্ত করা প্রয়োজন:

1. Password complexity এবং password reuse policy
2. Login rate limiting
3. Temporary account lockout
4. MFA recovery codes
5. Session revocation
6. Device/session listing
7. Refresh-token rotation
8. SSO identity linking rules
9. CSRF protection যেখানে cookie-based auth ব্যবহৃত হবে
10. File upload scanning
11. Field-level masking
12. Encryption key management
13. Secret rotation
14. Database backup encryption
15. PII logging prevention
16. Dependency vulnerability scanning
17. Static application security testing
18. Dynamic security testing
19. Privileged action re-authentication
20. Production support impersonation audit

Payroll বা bank information যোগ হলে আরও শক্ত field-level encryption এবং access segregation প্রয়োজন হবে।

7. Mobile-specific gaps

Mobile MVP-এর জন্য নিচের সিদ্ধান্ত প্রয়োজন:

• Minimum supported Android এবং iOS policy
• App update policy
• Rooted বা jailbroken device handling
• Push token refresh
• Lost device session revocation
• Biometric failure fallback
• Background location ব্যবহার হবে কি না
• Offline clock-in অনুমোদিত কি না
• Poor network-এ duplicate request handling
• Cached data encryption
• Screenshot restriction sensitive screen-এ প্রয়োজন কি না
• Deep-link authorization
• Mobile crash reporting
• Clock-in button-এর loading এবং retry behavior

Recommended MVP decision

Offline clock-in MVP-তে অনুমোদন না করাই নিরাপদ। Network না থাকলে app user-কে correction request workflow দেখাবে।

Static policy এবং profile data encrypted local cache-এ রাখা যেতে পারে।

8. Phase 2 module gaps

Payroll

Payroll module বর্তমানে high-level। Development শুরুর আগে country-specific specification প্রয়োজন:

• Tax rule
• Social contribution
• Proration
• Arrear
• Bonus
• Loan
• Reimbursement
• Final settlement
• Retroactive adjustment
• Payroll lock
• Bank file format
• Accounting journal
• Payslip approval
• Payroll reversal

Payroll compliance specification ছাড়া payroll engine build শুরু করা উচিত নয়।

Recruitment

প্রয়োজন:

• Candidate consent
• Duplicate candidate handling
• Resume parsing policy
• Interview timezone
• Feedback visibility
• Offer approval
• Rejection retention
• Candidate data deletion

Performance

প্রয়োজন:

• Rating scale
• Calibration
• Review visibility
• Goal weight
• Review reopening
• Reviewer anonymity
• Final rating approval

Part B: Recommended Product and Technical Decisions

9. MVP scope baseline

Included

• Company, branch, department, designation
• User authentication
• Google/Microsoft SSO
• Optional role-based MFA
• RBAC এবং scoped authorization
• Employee creation, update এবং lifecycle
• Manager hierarchy
• Shift এবং holiday configuration
• Web/mobile attendance
• Attendance correction
• Leave policy, balance এবং request
• Manager approval
• Notifications এবং announcements
• Basic employee documents
• HR, manager এবং employee dashboard
• Attendance, leave এবং headcount reports
• CSV/XLSX export
• Audit logs
• Mobile biometric unlock

Excluded

• Payroll calculation
• Recruitment
• Performance review
• Advanced onboarding
• Asset management
• Offline attendance
• Biometric attendance machine integration
• Custom workflow builder
• Multi-country tax localization

10. Recommended architecture

MVP-এর জন্য microservice architecture-এর পরিবর্তে modular monolith ব্যবহার করা সবচেয়ে বাস্তবসম্মত।

এতে module boundary পরিষ্কার থাকবে, কিন্তু deployment ও debugging তুলনামূলক সহজ হবে।

Recommended technology baseline

• Web: Next.js এবং TypeScript
• Mobile: React Native এবং TypeScript
• Backend: NestJS এবং TypeScript
• Database: PostgreSQL
• Cache এবং distributed lock: Redis
• Background jobs: Redis-backed queue
• File storage: S3-compatible object storage
• API documentation: OpenAPI
• Authentication: OIDC-compatible identity provider অথবা secure internal auth service
• Containerization: Docker
• Infrastructure: Infrastructure as Code
• Monitoring: Centralized logs, metrics, traces এবং alerting

একই language ecosystem ব্যবহারের ফলে shared type, validation schema এবং developer context switching কমবে।

Backend domain modules

text
identity
authorization
organization
employees
attendance
leave
approvals
notifications
announcements
documents
reports
audit
settings

Shared platform components

text
API gateway or application API layer
background worker
event/outbox processor
file service
notification adapters
audit service
report export worker

11. Suggested repository structure

text
/apps
  /web
  /mobile
  /api
  /worker

/packages
  /api-client
  /contracts
  /ui-web
  /ui-mobile
  /validation
  /permissions
  /date-time
  /testing

/infrastructure
  /docker
  /terraform-or-equivalent
  /monitoring

/docs
  /adr
  /api
  /data-dictionary
  /runbooks

API request/response DTO mobile বা web source code থেকে আলাদাভাবে shared contract package-এ রাখা উচিত।

Part C: Developer-ready Data Model

12. Core schema groups

Identity এবং access

• companies
• users
• external_identities
• user_sessions
• mfa_methods
• roles
• permissions
• role_permissions
• user_role_assignments
• role_scope_assignments

Organization

• branches
• departments
• designations
• holiday_calendars
• holidays
• holiday_calendar_assignments

Employee

• employees
• employment_records
• employee_assignments
• employee_manager_assignments
• employee_contacts
• employee_emergency_contacts
• employee_documents
• file_assets

Attendance

• shifts
• shift_assignments
• attendance_events
• attendance_days
• attendance_correction_requests
• attendance_correction_actions
• overtime_requests

Leave

• leave_types
• leave_policies
• leave_policy_assignments
• leave_ledger
• leave_requests
• leave_request_days

Shared workflow

• approval_definitions
• approval_definition_steps
• approval_instances
• approval_instance_steps
• approval_actions

Communication

• announcements
• announcement_audiences
• notifications
• notification_deliveries
• notification_preferences
• device_tokens

Governance

• audit_logs
• system_settings
• report_export_jobs
• idempotency_records
• outbox_events

13. Database implementation rules

1. সব primary key UUID হবে।
2. সব business table-এ company_id থাকবে।
3. সব mutable table-এ created_at, updated_at, created_by এবং updated_by থাকবে।
4. প্রয়োজনীয় table-এ deleted_at থাকবে।
5. Money field-এর জন্য floating point ব্যবহার করা যাবে না।
6. Timestamp UTC-তে সংরক্ষিত হবে।
7. Attendance এবং leave-এর জন্য local date আলাদাভাবে সংরক্ষণ করতে হবে।
8. গুরুত্বপূর্ণ update-এর জন্য optimistic version field ব্যবহার করা হবে।
9. Database constraint business validation-এর শেষ নিরাপত্তা স্তর হবে।
10. Migration production deployment-এর আগে staging-এ পরীক্ষা করতে হবে।
11. Audit-critical table physical delete করা যাবে না।
12. Payroll future module-এর জন্য decimal precision আগেই standardize করতে হবে।

Part D: API Implementation Standard

14. API baseline

Base path:

text
/api/v1

Authentication

text
Authorization: Bearer <token>

Required headers

text
X-Request-Id
Idempotency-Key
Accept-Language

Idempotency-Key শুধু duplicate-sensitive write operation-এ বাধ্যতামূলক হবে।

Date and time

• Timestamp: ISO 8601 with timezone
• Server storage: UTC
• Business date: YYYY-MM-DD
• Client timezone: informational
• Company/branch timezone: policy source

15. Important API corrections

Employee self check-in endpoint-এ client থেকে employeeId নেওয়া উচিত নয়।

Recommended endpoint:

text
POST /api/v1/me/attendance/check-in
POST /api/v1/me/attendance/check-out

Authorized admin manual adjustment-এর জন্য আলাদা endpoint:

text
POST /api/v1/employees/{employeeId}/attendance-adjustments

Leave approval endpoint action-oriented হতে পারে:

text
POST /api/v1/leave-requests/{id}/actions/approve
POST /api/v1/leave-requests/{id}/actions/reject
POST /api/v1/leave-requests/{id}/actions/withdraw
POST /api/v1/leave-requests/{id}/actions/cancel

একই pattern attendance correction-এর ক্ষেত্রেও ব্যবহার করা উচিত।

16. Error contract

Error response-এ machine-readable code থাকা প্রয়োজন:

json
{
  "success": false,
  "code": "LEAVE_INSUFFICIENT_BALANCE",
  "message": "Available leave balance is insufficient.",
  "errors": [],
  "requestId": "uuid"
}

Recommended business codes:

text
AUTH_INVALID_CREDENTIALS
AUTH_MFA_REQUIRED
AUTH_SESSION_EXPIRED
ACCESS_SCOPE_DENIED
EMPLOYEE_CODE_CONFLICT
ATTENDANCE_ALREADY_CHECKED_IN
ATTENDANCE_NO_OPEN_SESSION
ATTENDANCE_OUTSIDE_GEOFENCE
LEAVE_INSUFFICIENT_BALANCE
LEAVE_OVERLAPPING_REQUEST
LEAVE_POLICY_NOT_ASSIGNED
APPROVAL_ALREADY_COMPLETED
RESOURCE_VERSION_CONFLICT

17. Pagination and filtering

List API-তে standard format ব্যবহার করতে হবে:

text
page
limit
sort
search
filter[field]

Maximum limit server-side enforce করতে হবে।

Large dataset-এর জন্য ভবিষ্যতে cursor pagination ব্যবহার করা যেতে পারে, তবে MVP admin table-এর জন্য consistent offset pagination যথেষ্ট।

18. API concurrency rules

একই leave request দুই approver একই সময়ে approve করলে double action ঠেকাতে:

• Database transaction
• Row locking অথবা optimistic version
• State transition validation

ব্যবহার করতে হবে।

Client stale resource update করলে 409 RESOURCE_VERSION_CONFLICT return করা উচিত।

Part E: State Machines

19. Leave request state

text
draft
submitted
pending_approval
approved
rejected
withdrawn
cancellation_pending
cancelled

Allowed transition ছাড়া direct status update নিষিদ্ধ থাকবে।

20. Attendance correction state

text
submitted
pending_approval
approved
rejected
withdrawn

Approved correction raw event delete করবে না। Adjustment event এবং recalculated attendance day তৈরি করবে।

21. Employee account state

text
invited
active
locked
disabled

Employment status আলাদা হবে:

text
draft
probation
active
notice
resigned
terminated

22. Attendance day state

text
not_scheduled
present
late
absent
on_leave
holiday
weekend
incomplete
corrected

Late, present এবং overtime আলাদা dimensions হিসেবেও রাখা যেতে পারে; একটি single status-এর ওপর সব reporting নির্ভর করা উচিত নয়।

Part F: Developer-ready Delivery Plan

23. Delivery approach

Recommended plan:

• Sprint length: 2 weeks
• Foundation Sprint: 1–2 weeks
• Feature sprints: 6
• Stabilization এবং pilot: 1 sprint
• মোট সম্ভাব্য সময়: 14–16 weeks

Web, backend এবং mobile development parallel চলবে।

24. Sprint 0 — Foundation এবং requirement lock

Product এবং UX

• Final MVP scope lock
• Role-permission matrix
• Attendance rule matrix
• Leave policy matrix
• Approval workflow diagram
• Report metric definition
• Screen-level acceptance criteria
• Mobile navigation prototype

Architecture

• Architecture Decision Records
• Repository setup
• Module boundaries
• Database schema version 1
• API conventions
• Error code registry
• Tenant isolation strategy
• Authentication strategy
• File storage strategy

DevOps

• Development, staging এবং production environment
• CI pipeline
• Automated test pipeline
• Migration pipeline
• Secret management
• Logging এবং error monitoring
• Seed data strategy

Sprint exit criteria

• No unresolved P0 requirement
• Approved schema
• Approved permission matrix
• OpenAPI skeleton generated
• CI/CD passes
• Web, mobile এবং API shell deployable
• Development seed accounts available

25. Sprint 1 — Authentication, organization এবং access control

Backend

• Company context
• User management
• Login
• Refresh-token rotation
• Logout
• Forgot/reset password
• SSO integration foundation
• MFA foundation
• RBAC
• Scoped authorization
• Session management
• Audit foundation

Web

• Login
• Password reset
• Application shell
• Sidebar
• Top navigation
• Permission-aware routes
• Company settings shell

Mobile

• Login
• Secure token storage
• Biometric unlock
• Session expiry handling
• Base navigation

QA

• Authentication test
• Session revocation test
• Permission boundary test
• Tenant isolation test

Exit criteria

এক role অন্য role-এর restricted API বা screen access করতে পারবে না।

26. Sprint 2 — Organization এবং employee management

Backend

• Branch
• Department
• Designation
• Employee create/update
• Employee code generation
• Employee assignment history
• Manager assignment
• Emergency contact
• Employee status transition
• Employee search এবং filters

Web

• Employee directory
• Employee create form
• Employee profile
• Job details
• Organization settings
• Manager assignment

Mobile

• My profile
• Personal information view
• Approved editable field update

QA

• Duplicate employee validation
• Scope-based manager access
• Transfer history
• Termination login behavior
• Employee code concurrency

27. Sprint 3 — Attendance core

Backend

• Shift configuration
• Shift assignment
• Check-in
• Check-out
• Raw attendance event
• Daily attendance calculation
• Timezone handling
• Overnight shift support
• Idempotency
• Geofence configuration
• Attendance history

Web

• Attendance monitor
• Daily attendance table
• Filter
• Exceptions
• Employee attendance history

Mobile

• Home attendance card
• Clock-in/out
• GPS permission
• Location result
• Attendance history
• Network failure handling

QA

• Duplicate tap
• Device time manipulation
• Overnight shift
• Missing checkout
• Outside geofence
• Invalid accuracy
• Two devices
• Concurrent request

28. Sprint 4 — Attendance correction এবং notifications

Backend

• Correction request
• Approval workflow integration
• Manager scope
• Correction adjustment event
• Attendance recalculation
• In-app notification
• Email/push queue
• Outbox event

Web

• Correction request list
• Request detail
• Approve/reject
• Audit history
• Notification center

Mobile

• Correction request submission
• Manager approval
• Push deep link
• Read/unread notification

QA

• Approval race condition
• Unauthorized approval
• Notification deduplication
• Recalculation accuracy
• Audit completeness

29. Sprint 5 — Leave management

Backend

• Leave type
• Leave policy
• Policy assignment
• Leave ledger
• Accrual job
• Leave request
• Leave request days
• Balance validation
• Overlap validation
• Holiday/weekend calculation
• Approval workflow
• Cancellation এবং reversal

Web

• Leave policy settings
• Leave request list
• Pending approval
• Team leave calendar
• Leave balance report

Mobile

• Apply leave
• Balance preview
• Leave history
• Request withdrawal
• Manager approve/reject

QA

• Insufficient balance
• Half-day
• Holiday exclusion
• Weekend exclusion
• Overlapping request
• Cancellation
• Ledger reconciliation
• Backdated request
• Manager delegation

30. Sprint 6 — Dashboards, announcements, documents এবং reports

Backend

• Headcount report
• Attendance summary
• Leave summary
• Report filters
• Async export
• Announcement targeting
• Document upload
• Signed download
• File access audit

Web

• HR dashboard
• Manager dashboard
• Employee dashboard
• Reports
• Announcement publishing
• Document management
• Export status

Mobile

• Dashboard summary
• Announcements
• Documents
• Notification preferences

QA

• Metric reconciliation
• Data scope
• Export permission
• Large export
• Expired signed URL
• Restricted document access

31. Sprint 7 — Stabilization, UAT এবং pilot

Engineering

• Performance optimization
• Database index review
• Security remediation
• Accessibility fixes
• Mobile crash fixes
• Observability improvement
• Backup restore test
• Feature flag review
• Data migration rehearsal

QA

• Full regression
• Cross-browser testing
• Mobile device testing
• Load testing
• Security testing
• UAT execution
• Disaster recovery test
• Production smoke test plan

Exit criteria

• No open critical defect
• No open high-severity security issue
• UAT sign-off
• Backup restore verified
• Rollback plan verified
• Production support runbook approved
• Pilot organization configured

Part G: Team Workstreams

32. Backend team

Backend team-এর primary ownership:

• Domain model
• Database migration
• API
• Business rules
• Authorization
• Audit
• Background jobs
• Notification event
• Reporting query
• Integration contract

প্রতিটি business rule-এর unit test থাকতে হবে।

33. Web team

Web team-এর primary ownership:

• Admin এবং manager workflows
• Responsive desktop/tablet UI
• Table, filter এবং bulk action
• Role-based navigation
• Error এবং empty state
• Accessibility
• API integration
• Export workflow

34. Mobile team

Mobile team-এর primary ownership:

• Secure authentication
• Biometric unlock
• Attendance
• GPS permission
• Leave
• Notifications
• Manager quick approvals
• Secure local cache
• Deep links
• App lifecycle handling

35. QA team

QA team Sprint 1-এর পরে নয়, Sprint 0 থেকেই যুক্ত থাকবে।

QA deliverables:

• Requirement traceability matrix
• Test scenario
• API test collection
• Role-permission test matrix
• Timezone test dataset
• Attendance edge-case suite
• Leave calculation suite
• Regression suite
• UAT script
• Release sign-off checklist

36. DevOps ownership

• Environment provisioning
• CI/CD
• Secrets
• Monitoring
• Database backup
• Restore drill
• Deployment strategy
• Migration safety
• Vulnerability scanning
• Log retention
• Incident response runbook

Part H: Testing Strategy

37. Test layers

Unit tests

প্রধানত:

• Leave calculation
• Attendance calculation
• Permission evaluation
• Employee status transition
• Approval transition
• Payroll-independent date calculation

Integration tests

• Database transaction
• Redis
• File storage
• Notification queue
• SSO
• Email/push adapter

Contract tests

OpenAPI contract-এর বিপরীতে web এবং mobile API client পরীক্ষা করতে হবে।

End-to-end tests

Critical journeys:

1. Admin creates employee
2. Employee activates account
3. Employee checks in and out
4. Employee submits correction
5. Manager approves correction
6. Employee applies for leave
7. Manager approves leave
8. Leave balance updates
9. HR views report
10. Employee receives notification

38. Mandatory edge-case tests

• Two users with same email in different tenant
• Unauthorized cross-tenant employee ID
• Overnight shift
• Daylight-saving transition where applicable
• Duplicate check-in request
• Check-out without check-in
• Manager changed during pending approval
• Employee terminated with active session
• Leave policy changed after request submission
• Concurrent approval
• Cancelled leave balance reversal
• Backdated assignment
• Exporting data outside user scope
• Expired file URL
• Push notification sent twice
• Database migration rollback

Part I: Definition of Ready এবং Definition of Done

39. Definition of Ready

কোনো story development-এ নেওয়ার আগে থাকতে হবে:

• Actor
• Objective
• Preconditions
• Business rules
• Permission
• Data scope
• Validation
• State transition
• Error behavior
• UI design
• API contract
• Acceptance criteria
• Analytics বা audit requirement
• Test scenario

40. Definition of Done

কোনো feature complete ধরা হবে যখন:

• Code review complete
• Unit test pass
• Integration test pass
• API documentation updated
• Database migration reviewed
• Authorization test complete
• Audit behavior verified
• Error এবং empty state implemented
• Monitoring added
• Sensitive logging checked
• Accessibility checked
• QA accepted
• Product accepted
• Rollback path documented

Part J: DevOps and Release Plan

41. Environment

কমপক্ষে:

• Local
• Development
• Staging
• Production

Staging environment production configuration-এর যতটা সম্ভব কাছাকাছি হওয়া উচিত।

42. Deployment requirements

• Automated build
• Automated test
• Migration validation
• Security scan
• Container image versioning
• Health check
• Readiness check
• Rollback support
• Feature flag
• Deployment audit

Production migration backward-compatible হওয়া উচিত।

43. Monitoring requirements

Technical metrics

• API latency
• Error rate
• Database connection
• Queue delay
• Failed job
• Push/email delivery failure
• Storage error
• Login failure
• CPU এবং memory
• Mobile crash-free session

Business metrics

• Successful check-in rate
• Duplicate attendance attempt
• Attendance correction rate
• Leave request completion
• Approval turnaround
• Notification delivery
• Report export completion

Part K: Major Risk Register

Part L: First 10 Working Days Action Plan

Day 1–2

• Final MVP scope sign-off
• User role list
• Permission matrix
• Data-scope matrix
• Open P0 decision resolution

Day 3–4

• Attendance policy workshop
• Leave policy workshop
• Approval workflow lock
• State machine approval
• Report definition lock

Day 5–6

• ER model version 2
• Database naming convention
• API convention
• Error code registry
• Authentication architecture

Day 7–8

• Repository setup
• CI/CD setup
• Environment setup
• Application shell
• Database migration foundation
• OpenAPI skeleton

Day 9–10

• Seed data
• Demo tenant
• Test roles
• Login vertical slice
• Tenant isolation test
• Sprint 1 planning
• Architecture readiness review

Part M: Development Start Gate

পূর্ণ feature development শুরু করার আগে নিচের সব item “Yes” হতে হবে:

• MVP scope signed off
• Tenant strategy approved
• Permission matrix approved
• Attendance policy approved
• Leave policy approved
• Approval model approved
• ER model version 2 approved
• API conventions approved
• Security baseline approved
• NFR target approved
• CI/CD operational
• Staging environment operational
• Seed data available
• Definition of Ready adopted
• QA traceability matrix started

Final recommendation

বর্তমান SRS বাতিল বা পুনরায় শুরু করার প্রয়োজন নেই। এটিকে Product Requirements Baseline হিসেবে রেখে উপরের gap resolution এবং technical decision-গুলো একটি supplementary specification হিসেবে অনুমোদন করা উচিত।

Development-এর সবচেয়ে নিরাপদ ও দ্রুত পথ হবে:

1. প্রথমে Sprint 0 সম্পন্ন করা।
2. Multi-tenant modular monolith architecture গ্রহণ করা।
3. Permission, attendance এবং leave engine-কে core domain হিসেবে অগ্রাধিকার দেওয়া।
4. Raw attendance event এবং leave ledger immutable রাখা।
5. Phase 2 module MVP codebase-এ আংশিকভাবে build না করা।
6. OpenAPI contract এবং automated permission test-কে release gate করা।
7. Sprint 7 শেষে limited pilot organization দিয়ে production rollout শুরু করা।

এই approach অনুসরণ করলে HRMS MVP তুলনামূলক কম rework, পরিষ্কার module boundary এবং ভবিষ্যৎ payroll, recruitment ও performance expansion-এর উপযোগী foundation নিয়ে তৈরি হবে। :::

পরবর্তী যৌক্তিক ধাপ হলো এই পরিকল্পনাকে Jira-ready epics, stories, subtasks এবং পূর্ণ OpenAPI 3.0 contract-এ ভেঙে development board প্রস্তুত করা।