Explain about requirements management and roadmaps.

Requirements Management
Requirements Management is the process of collecting, organizing, tracking, and
controlling requirements throughout the software life cycle so the system delivers what
users actually need.
What it means
• A requirement is a capability the system must provide or a condition it must satisfy.
• Requirements Management ensures:
o Everyone agrees on what to build
o Changes are handled in a controlled way
o Requirements stay correct from start to delivery
Why it is important
• Many projects fail due to:
o Incomplete requirements
o Changing requirements
o Lack of user involvement
• Fixing requirement errors late is very costly
Key activities
• Elicitation – gather needs from users and stakeholders
• Analysis – understand and refine requirements
• Documentation – write requirements clearly
• Validation – confirm requirements are correct
• Change control – manage updates without chaos
Example
For an online exam system:
• Requirement: “Students must be able to submit exams online”
• Managed by:
o Documenting it
o Tracing it to design and testing
o Updating it if rules change

Roadmaps (Requirements Roadmap)

A roadmap shows the journey from user problems to the final software solution, clearly
separating what the problem is from how the solution is built.
What a roadmap is
A roadmap connects:
• Problem domain → user needs
• Solution domain → system features and software requirements
Problem domain
Focuses on why the system is needed:
• Stakeholder needs
• Business problems
• “Must-have” vs “nice-to-have”
 • What users want, in their language
Example:
• “Students find manual exam evaluation slow”
Solution domain
Focuses on how the system solves the problem:
• System features
• Software requirements
• Technical details
Example:
• Feature: “Automatic exam evaluation”
• Requirement: “System shall evaluate MCQs instantly”
Why separating problem and solution matters
• Prevents jumping to wrong solutions
• Helps evaluate design choices
• Makes changes easier to manage
One-line takeaway
Requirements Management controls “what to build”, while the Roadmap explains “why
and how we build it”.
Explain about the traditional model (Waterfall model), including its phases and a
diagram.
Traditional Model – Waterfall Model
The Waterfall model is a traditional software development model where work flows step by
step in a fixed order, and each phase must be completed before moving to the next—like
water flowing down a waterfall.
What the Waterfall Model is
• Linear and sequential approach
• No overlapping of phases
• Very little scope for change once a phase is finished
• Best when requirements are clear and stable

Phases of the Waterfall Model

1. Requirements Analysis
• Collect all user and system requirements
• Document what the system should do
• Output: Requirements Specification (SRS)
2. System Design
• Convert requirements into system architecture
• Decide database, hardware, software design
• Output: Design documents
3. Implementation (Coding)
• Developers write code based on design
• Each module is developed separately
• Output: Working code
4. Testing
• Check if the software works correctly
• Find and fix bugs
• Ensure it meets requirements
5. Deployment
• Software is delivered to users
• Installed in the real environment
6. Maintenance
• Fix bugs after release
• Handle small updates and changes

Key Characteristics
• Simple and easy to understand
• Clear milestones and documentation
• Progress is easy to track

Advantages
• Easy to manage
• Suitable for small projects
• Works well when requirements don’t change

Disadvantages
• Changes are difficult and costly
 • Testing happens late
• Real users see the product very late

One-line takeaway
Waterfall is a linear, document-driven model best suited for projects with fixed and
well-understood requirements.
Explain about the iterative approach with an example, including its phases and a
diagram.
Iterative Approach (Iterative Model)
Final idea first:
The iterative approach builds software in small repeated cycles, where each cycle delivers
a working version of the system and improves it step by step using feedback.

What the Iterative Approach is

• Development happens in iterations (loops)
• Each iteration adds new functionality
• Feedback is used to improve the next version
• Requirements can evolve over time

Phases in Each Iteration

Each iteration follows these phases:
1. Planning
• Select a small set of requirements
• Decide goals for this iteration
2. Design
• Design only the selected features
• Keep design flexible
3. Implementation
 • Code the planned features
• Build a working version
4. Testing
• Test the new features
• Fix issues early
5. Review / Feedback
• Show working software to users
• Collect feedback for the next iteration
This cycle repeats until the system is complete.

Example: Online Shopping System

Iteration 1
• Features: User registration, login
• Result: Basic working system
Iteration 2
• Features: Product listing, search
• Result: Users can browse products
Iteration 3
• Features: Cart and checkout
• Result: Complete purchase flow
Iteration 4
• Features: Payment, order tracking
• Result: Full system ready

Advantages
• Early delivery of working software
• Easy to handle requirement changes
• Problems are detected early

Disadvantages
• Needs good planning
• Overall cost can be higher
• Requires frequent user involvement

One-line takeaway
The iterative approach builds software in small cycles, improving the product
continuously with user feedback.
Consider a bank application and design the SRS (Software Requirements Specification)
document for the application.
• Follow-up scenario: Suppose we had an SRS document, but RBI (Reserve Bank
of India) guidelines have changed. How will you update the SRS document or
what will you do in this situation?
Software Requirements Specification (SRS)
Bank Application

1. Introduction
1.1 Purpose
This document describes the functional and non-functional requirements of a Bank
Application that supports customer banking operations such as account management,
transactions, and regulatory compliance.
1.2 Scope
The system allows customers to:
• Open and manage bank accounts
• Perform deposits, withdrawals, and transfers
• View balances and transaction history
• Comply with banking regulations
The system will be used by customers, bank staff, and administrators.
1.3 Definitions
• KYC: Know Your Customer
• OTP: One-Time Password
• RBI: Reserve Bank of India

2. Overall Description
2.1 Product Perspective
• Web and mobile-based application
• Connected to a central bank database
• Interfaces with payment gateways and notification services
2.2 User Classes
• Customer – uses banking services
• Bank Staff – verifies accounts, handles issues
• Admin – manages system and compliance rules
2.3 Operating Environment
• Server: Linux/Cloud
• Client: Web browser / Mobile app
• Database: Relational DB

3. Functional Requirements
3.1 User Registration and Login
• Users shall register using mobile number and email
• System shall verify users using OTP
• System shall support secure login and logout
3.2 Account Management
• System shall allow users to open savings/current accounts
• System shall store KYC details
• System shall allow users to update profile information
3.3 Transactions
 • System shall allow deposits and withdrawals
• System shall allow fund transfer between accounts
• System shall generate transaction IDs
3.4 Balance and Statements
• System shall display current account balance
• System shall provide transaction history
• System shall allow statement download (PDF)
3.5 Notifications
• System shall send SMS/email alerts for transactions
• System shall notify users of failed or suspicious activities

4. Non-Functional Requirements
4.1 Security
• Data shall be encrypted
• Two-factor authentication shall be used
• Session timeout shall be enforced
4.2 Performance
• Transactions shall be processed within 3 seconds
• System shall support concurrent users
4.3 Reliability
• System uptime shall be 99.9%
• Automatic backup shall be taken daily
4.4 Compliance
• System shall comply with all RBI regulations
• Audit logs shall be maintained

5. Constraints
• Must follow RBI banking rules
• Must support Indian currency (INR)
• Must comply with data protection laws

6. Assumptions
• Users have internet access
• OTP services are available

Follow-Up Scenario: RBI Guidelines Changed

What to do when RBI guidelines change
Final idea first:
Treat it as a requirements change and update the SRS using a formal change management
process.

Step-by-Step Actions
1. Identify the Change
 • Study new RBI guidelines
• Identify affected areas (KYC, transaction limits, security)
2. Impact Analysis
• Check which SRS sections are affected:
o Functional requirements
o Non-functional (security, compliance)
• Analyze cost, time, and risk impact
3. Update the SRS
• Modify existing requirements
• Add new requirements if needed
• Mark updated sections with version numbers
Example:
• Old: “KYC required during account opening”
• New: “Video KYC mandatory as per updated RBI rules”
4. Review and Approval
• Get approval from:
o Compliance team
o Project stakeholders
• Ensure alignment with RBI rules
5. Version Control
• Update SRS version (e.g., v1.2 → v1.3)
• Maintain change history section
6. Communicate and Implement
• Inform development and testing teams
• Update design, code, and test cases

One-line takeaway
When RBI rules change, perform impact analysis, update the SRS formally, version it,
and realign the system to stay compliant.
By taking a case study, explain Waterfall vs. Iterative model. Choose the best model and
justify why?
Case Study: Online Banking Application
Final idea first:
For a modern online banking application, the Iterative model is the better choice because
requirements (security rules, RBI guidelines, user expectations) change frequently, and early
feedback is critical.

Case Study Overview

A bank wants to build an online system for:
• User registration & login
• Balance enquiry
• Fund transfer
• Bill payments
 • Alerts & notifications
• Compliance with RBI rules

Waterfall Model – How it fits this case

How development happens
1. Requirements: All banking features finalized upfront
2. Design: Complete system architecture designed once
3. Implementation: Full system coded
4. Testing: Testing after coding finishes
5. Deployment: System released at the end
What works well
• Clear documentation
• Easy to manage phases
• Suitable if rules never change
Problems in this case
• RBI guidelines may change mid-project
• Security requirements evolve
• Users see the system only at the end
• Fixing requirement mistakes is costly
Result: Risky for a banking system with changing regulations.

Iterative Model – How it fits this case

How development happens (iterations)
Iteration 1
• Login, basic account view
• Feedback from bank staff
Iteration 2
• Fund transfer, transaction history
• Security improvements
Iteration 3
• Bill payments, alerts
• RBI compliance updates
Iteration 4
• Performance tuning, audit logs
Each iteration includes:
Planning → Design → Coding → Testing → Feedback
What works well
• Early working software
• Easy to apply RBI rule changes
• Continuous testing and security checks
• User and compliance team feedback
Result: Flexible and safer for banking systems.
Side-by-Side Comparison
Aspect Waterfall Model Iterative Model
Requirement changes Very hard Easy
User feedback Late Early & continuous
Risk handling High risk Lower risk
Compliance updates Costly Manageable
Delivery One-time Incremental

Best Model Choice: Iterative Model

Justification
• Banking apps must adapt to regulatory changes
• Security needs continuous improvement
• Early releases reduce risk
• Feedback improves correctness and usability

One-line takeaway
For systems with changing rules and high risk—like banking—Iterative beats Waterfall
by enabling flexibility, early feedback, and safer evolution.