Unit -3 SOFTWARE PROJECT PLANNING & MANAGEMENT

(MTCS042)

SOFTWARE REQUIREMENTS GATHERING

1. Inputs and Start Criteria for Requirements Gathering

What is it?
Before you begin collecting requirements for a software project, you need certain
things ready. These things are called inputs and start criteria. Without these, the
requirements process may become confusing, incomplete, or go in the wrong
direction.

Inputs (What you must have before starting)

1. Project Charter or Project Proposal
o It contains the project goals, scope, and client expectations.

o Example: If a university wants to develop an online examination

system, the proposal might include the purpose (e.g., conducting
remote exams), user types (students, teachers), and basic scope.
2. Stakeholder List
o A list of all the people who are involved or affected.

o Example: For the exam system, stakeholders are students, faculty,

exam controllers, and IT staff.
3. Business Case
o Justification for starting the project.

o Example: Online exams reduce paper costs, save time, and

improve accessibility.
 4. Existing System Documentation (if any)
o If an older system exists, its manuals and diagrams are useful.

o Example: The university might already use a paper-based exam

system. Its timetable and grading rules can guide the new system.
5. Constraints and Assumptions
o These are limitations and things considered true.

o Example: The exam system must work on mobile phones

(constraint), and users will have internet access (assumption).

Start Criteria (When to start gathering?)

 Client has approved the initial scope and objectives.
 You have access to all stakeholders.
 A team of analysts and developers is ready.
 Time, cost, and deadlines are roughly estimated.
 Everyone agrees on the goals and is ready to proceed.

2. Dimensions of Requirements Gathering

What is it?
Dimensions mean different angles or types of requirements that we must collect.
Not all requirements are the same.

Types of Requirements
1. Functional Requirements
o What the software should do.
 o Example: In an ATM system, users should be able to check
balance, withdraw money, and change PIN.
2. Non-Functional Requirements
o How the software should behave.

o Example: The ATM should respond within 5 seconds and support

Hindi, English, and regional languages.
3. Business Requirements
o Why the software is being built—business goals.

o Example: A company wants to increase online sales by 40% using

a new e-commerce website.
4. User Requirements
o What the user expects to do with the software.

o Example: A student using a university portal wants to download

the admit card and check results.
5. System Requirements
o Technical and environmental needs.

o Example: The exam portal must run on Android, iOS, and

desktops, and support cloud-based databases.

3. Steps to Be Followed During Requirements Gathering

What is it?
It is a structured way of collecting, analyzing, and validating requirements.

Step-by-Step Process (with real examples)

1. Identify Stakeholders
 o Find out who uses or impacts the system.

o Example: For a hospital management system – doctors, nurses,

receptionists, and patients.
2. Understand Business Goals
o What problem are we solving?

o Example: A hospital wants to reduce patient waiting time by

automating appointment bookings.
3. Conduct Interviews
o Ask questions to users, clients, and managers.

o Example: Ask doctors what reports they need and how they prefer
patient history to be displayed.
4. Organize Workshops and Group Meetings
o Group brainstorming with all stakeholders.

o Example: A meeting between doctors and software developers to

agree on the treatment record format.
5. Use Surveys and Questionnaires
o Useful for large groups.

o Example: Asking 200 students through Google Forms about

features they want in the university portal.
6. Observe Existing System
o Watch users do their tasks to find pain points.

o Example: Observe how reception staff book appointments

manually and note their challenges.
7. Create Use Cases or User Stories
o Describe actions from a user's perspective.
 o Example: “As a student, I want to log in and check my grades.”
8. Develop Prototypes (optional)
o Show users what the final product might look like.

o Example: A rough design of the student dashboard shown to

students for feedback.
9. Validate Requirements
o Double-check if requirements are clear, complete, and agreed upon.

o Example: Share the requirement document with the client and take
approval.
10.Document Requirements
 Create a final SRS (Software Requirements Specification) document.

4. Outputs and Quality Records from Requirements Phase

Outputs (Final Deliverables)

1. Software Requirements Specification (SRS)
o The main document listing all approved functional and non-functional
requirements.
2. Use Case Diagrams / User Stories
o Diagrams or short descriptions of how users interact with the system.
3. Requirement Traceability Matrix (RTM)
o A table mapping each requirement to design, implementation, and
testing.
4. Meeting Notes and Approvals
o Evidence that stakeholders agree on what is being built.
 Quality Records (Proof of Good Practice)
 Peer review comments and changes.
 Feedback forms from clients.
 Signatures from stakeholders.
 Updated version logs of requirement documents.

Example: A school principal signs the final SRS document for a result-
reporting app.

5. Skill Sets Required During Requirements Phase

To gather requirements properly, certain skills are important:
1. Communication Skills
o To talk clearly with clients and users.
2. Listening Skills
o To understand user problems deeply.
3. Analytical Thinking
o To identify gaps, patterns, and organize information logically.
4. Documentation Skills
o To write correct and complete requirement documents.
5. Domain Knowledge
o Knowing the industry.

o Example: If you’re building a hospital system, understand terms

like OPD, prescription, insurance claims.
6. Technical Knowledge
o Helps understand what’s possible in terms of technology.
 7. Negotiation Skills
o To settle disputes when different users want conflicting features.

6. Differences for a Shrink-Wrapped Software

Shrink-wrapped software is pre-built for many users (e.g., MS Office, Tally),
unlike custom software built for one client.

Feature Custom Software Shrink-Wrapped Software

Target User Specific client General public

Flexibility Very high Low

Requirements Source From client From market trends

Feedback Direct from user Collected via surveys, reviews

Example University Portal Microsoft Word

7. Challenges During the Requirements Management Phase

1. Changing Requirements
o Stakeholders may change their minds as they see progress.

o Example: A college initially wants attendance tracking but later

adds online test modules.
2. Misunderstood Requirements
o Developers may interpret client needs incorrectly.

o Example: "Easy to use" is subjective — means different things to

different people.
3. Unclear Requirements
o Users may not know exactly what they want.
 o Example: A small business owner might say “make it like
Amazon,” which is too vague.
4. Conflicting Requirements
o Marketing team wants speed; finance team wants security.
5. Budget and Time Limitations
o Some features may be too costly or time-consuming.
6. Stakeholder Unavailability
o Delays occur when users don’t give timely feedback.

8. Metrics for Requirements Phase

Why use Metrics?

Metrics help measure the effectiveness and quality of requirement gathering.

Metric Meaning Real Example

Total Requirements Total count 150 features listed

Requirement Stability % of unchanged

90% stable = good
Index requirements

10 major updates in 2 weeks

Volatility Number of changes
= risky

80% bugs caught in SRS =

Review Efficiency % issues caught early
great

Requirements Coverage % of requirements tested 95% tested = success

Stakeholder 100% clients joined all

Attendance in meetings
Participation workshops
 Estimation in Software Engineering –

1. What is Estimation?

Definition:
Estimation is the process of predicting or calculating how much effort, time, cost,
and resources will be required to complete a software project.
Estimation is not exact, but it gives us an approximate idea that helps in planning
the project properly.

Real-World Analogy:
Imagine you're planning a wedding. You don't know the exact cost or time for
every task, but you need an idea:
 How much food will be required?
 How many guests will attend?
 How many days will it take to prepare?
Similarly, in software development, we need to estimate how much work is needed
before starting.

2. When and Why is Estimation Done?

When is Estimation Done?

Estimation is done at different stages of the project:
 Before the project starts – during project planning
 After gathering requirements
 Before major phases like design, coding, testing
 Whenever scope changes
 Why is Estimation Important?
1. To plan properly – We can decide deadlines, resources, and costs.
2. To manage risk – Early estimation helps in identifying unrealistic
expectations.
3. To build trust – Clients and stakeholders know what to expect.
4. To allocate resources – We know how many developers or testers are
needed.

Real-World Example:
You are hired to build an e-commerce website. The client asks:
 How much will it cost?
 When will it be delivered?
You must estimate:
 Pages needed (Home, Cart, Payment)
 Backend work (Database, Server)
 Features (Login, Search)
Without estimation, you might overpromise and underdeliver.

3. The Three Phases of Estimation

Estimation in software has three main phases:

a) Size Estimation
 Here, we estimate the size of the software in terms of work.
 Common units: Lines of Code (LOC) or Function Points (FP).
 Size tells us how big the software is.
 Real-Life Example:
You want to build a car. You estimate:
 1,000 parts needed
 4 doors, 5 seats, etc.
In software, you estimate:
 20,000 LOC for an online exam system

b) Effort Estimation
 This is the amount of work required to complete the project.
 Measured in person-hours or person-days.

Formula:
Effort = Size / Productivity
If a developer writes 500 LOC per day, and the project needs 10,000 LOC:
Effort = 10,000 / 500 = 20 person-days

Real-Life Example:
You’re painting a building. If one painter paints 10 walls a day, and you have 50
walls:
You’ll need 5 days with 1 painter, or 2.5 days with 2 painters.

c) Schedule Estimation
 This is the calendar time or total days required to finish the project.
 Depends on team size, working hours, holidays, etc.
 Formula:
Schedule = Effort / Number of People
If you need 30 person-days of effort and you have 3 people:
Schedule = 30 / 3 = 10 working days

Real-Life Example:
To prepare 100 lunch boxes:
 If one cook takes 5 mins/box → Total effort = 500 minutes
 With 2 cooks → Time = 250 minutes

4. Estimation Methodology
This defines how estimation is performed. Two main ways:

a) Top-Down Estimation
 Start with the overall project estimate and then break it down into smaller
parts.
 Used when details are not yet clear.

Example:
A manager says, “This project looks like a 6-month job,” and splits:
 Design – 1 month
 Coding – 3 months
 Testing – 2 months

Like budgeting ₹1 lakh for a wedding first, then dividing for dress, food, etc.

b) Bottom-Up Estimation
 Estimate each module, feature, or task individually.
  Add all to get the total.
 More accurate, but time-consuming.

Example:
Each developer estimates:
 Login Module = 3 days
 Dashboard = 5 days
 Payment = 4 days
Total = 12 person-days

Like listing all items for a wedding (DJ, lights, catering) and then calculating
total cost.

5. Formal Models for Size Estimation

To estimate size formally, we use mathematical models:

a) Lines of Code (LOC)

 Estimate how many lines of code will be written.
 Simple but depends on coding style.

Example:
Login system = 1,000 LOC
Report generation = 5,000 LOC

Each function/module is measured based on past data.

b) Function Point Analysis (FPA)

 Estimates based on functionality provided to the user.
 Independent of programming language.
  Counts: Inputs, Outputs, Inquiries, Files, Interfaces

Example:
 Inputs: 10 forms
 Outputs: 5 reports
 Files: 3 databases
Use weighted values to get total Function Points (FP).

Like measuring a car by features (AC, GPS, Power Windows) instead of size.

6. Translating Size Estimate into Effort Estimate

Once size is estimated, effort is calculated:

Effort = Size / Productivity
Example:
If size = 1,200 Function Points
And team’s productivity = 6 FP/day
Effort = 1,200 / 6 = 200 person-days
This tells us how many working days are required to develop the system.

Like knowing how many days it takes to sew 200 dresses if one tailor sews 2
per day.
 7. Translating Effort into Schedule Estimate

Once effort is known, we estimate the total calendar time:

Schedule = Effort / Team Size
Example:
Effort = 200 person-days
Team = 4 developers
Schedule = 200 / 4 = 50 working days
But remember:
 Adding more people doesn’t always reduce time.
 New people take time to understand the project (Brooks' Law).

Like 9 women can’t make a baby in 1 month.

8. Common Challenges During Estimation

Problems faced:
1. Unclear Requirements
o Hard to estimate when goals are not clear.
o Like planning a party without knowing how many guests.
2. Changing Requirements
o Scope keeps changing, estimates become invalid.
3. Lack of Historical Data
o No past project to compare with.
4. Incorrect Assumptions
o Assuming tasks will go smoothly when they won’t.
5. Overconfidence
 o Underestimating testing/debugging time.
6. Communication Gaps
o Misunderstanding between client and developer.

9. Metrics for Estimation Process

These help evaluate the quality of your estimates.

a) Estimation Accuracy
 Measures how close your estimate was to actual.
Accuracy = |Estimated – Actual| / Actual × 100%

Example:
Estimated = 100 days, Actual = 120 days
Error = 20/120 × 100 = 16.6% error

b) Variance
 Difference between actual and estimated values.
 Helps identify overestimation or underestimation.

c) Productivity
Productivity = LOC / person-day OR FP / person-day

Example:
10,000 LOC in 25 person-days → Productivity = 400 LOC/day

d) Defect Density
 Used to check if low estimation impacted quality.
Defect Density = Number of bugs / LOC

Final Summary Example:

You’re making a hotel management system.

Step Details

Size Estimation 15,000 LOC

Effort Estimation 15,000 / 500 = 30 person-days

Schedule Estimation 30 / 2 developers = 15 working days

Challenges Unclear login roles added later

Result Actual = 20 days, Estimation Error = 5 days

 Summary Table for Quick Revision

Concept Meaning Real-Life Example

Estimation Predict effort, time, cost Planning a wedding

Size Estimation How big the project is No. of pages in website

Effort Estimation Total work needed Hours to paint a building

Schedule
Total calendar time Days to finish wedding planning
Estimation

Budgeting wedding first, then

Top-Down Big picture → parts
details

Bottom-Up Parts → total List each cost item

LOC & FP Measuring size LOC = Length; FP = Features

Accuracy & Like checking your monthly

Metrics
Productivity expenses
Design and Development Phases –

1. Some Differences in Our Chosen Approach

Explanation:
In software engineering, different projects or teams may adopt different
development models or strategies depending on the needs, time constraints, and
goals. The chosen approach significantly affects how design and development are
carried out.
Common Approaches:
 Waterfall Model: Step-by-step process, once a phase is completed, you
don’t go back.
 Agile Model: Flexible, iterative development with regular user feedback.
 DevOps: Focuses on integration between development and operations,
emphasizes automation and continuous delivery.
Real-World Example:
A government taxation system might use the Waterfall model because
requirements are clear and fixed.
Whereas a food delivery app like Zomato would use Agile, as customer feedback
is needed regularly, and features evolve with trends.

2. Salient Features of Design

Explanation:
A good software design should ensure:
 Modularity: Breaking the system into independent parts (modules).
 Abstraction: Hiding complex details behind simple interfaces.
 Reusability: Ability to use parts of the design in other systems.
 Flexibility: Easy to update when changes occur.
  Simplicity and Understandability: Developers should understand the flow
quickly.
 Scalability: Able to grow (handle more users/data).
Real-World Example:
In Amazon, different teams manage different modules: product listings, payments,
orders, delivery. Each is designed as a separate module that can be modified or
upgraded without affecting the others.

3. Evolving an Architecture / Blueprint

Explanation:
Software architecture is the high-level structure of the system. It shows:
 How different components interact
 Technologies and platforms to be used
 Layered design: UI, Business logic, Database
It acts like a building blueprint for developers.
Real-World Example:
For a university portal, the architecture might be:
 Frontend (UI): React.js for the student dashboard
 Backend: Java or Python Flask for logic
 Database: MySQL for storing results, profiles
This clear structure helps development, maintenance, and scaling.

4. Design for Reusability

Explanation:
When you create a part of software in a general, adaptable way so it can be used
again in different projects or parts of the same project.
Benefits:
  Saves time and cost
 Reduces errors
 Promotes standardization
Real-World Example:
A user authentication module developed for a hospital management system can
be reused in an e-learning portal by just modifying the database fields.

5. Technology Choices / Constraints

Explanation:
Selecting the right set of tools, frameworks, languages, and platforms to build the
software. But, there may be constraints like:
 Budget
 Skillset of developers
 Licensing cost
 Compatibility with existing systems
Real-World Example:
A startup may use Python + Django + PostgreSQL (open-source tools) due to low
budget, while a multinational company might prefer Microsoft .NET + SQL
Server for scalability and support.

6. Design to Standards
Explanation:
Following industry standards, best practices, and protocols to make sure the
software is:
 Compatible with other systems
  Secure
 Maintainable
Examples of Standards:
 ISO/IEC 25010: Quality of software
 IEEE 830: SRS standard
 HTML5, CSS3: For web development
Real-World Example:
A banking app must comply with PCI DSS standards for handling customer card
data securely.

7. Design for Portability

Explanation:
Portability means the ability of software to run on multiple platforms or
environments with minimal changes.
Benefits:
 Broader audience
 Reduced development time for new platforms
Real-World Example:
A mobile game developed using Unity engine can be deployed on Android, iOS,
and Windows without rewriting the entire code.

8. User Interface (UI) Issues

Explanation:
Designing a UI that is:
  Simple and intuitive
 Visually appealing
 Easy to navigate
 Responsive (works on all screen sizes)
Common UI Issues:
 Cluttered layout
 Inconsistent buttons and menus
 Poor color choices
 Slow loading
Real-World Example:
Old railway ticket booking websites had poor UI. New apps like IRCTC Rail
Connect are modern, user-friendly, and mobile-responsive.

9. Design for Testability

Explanation:
Making the software easy to test by:
 Writing independent, small functions (low coupling)
 Clear input and output
 Adding logs and debug messages
Real-World Example:
In a library management system, having a clear method like
calculateLateFine(days) helps test it easily with different inputs (e.g., 5 days late
→ ₹50).

10. Design for Diagnosability

Explanation:
Diagnosability means the software should help in quickly identifying and solving
problems or bugs.
How?
 Use of error messages
 System logs
 Monitoring tools
Real-World Example:
In Google Chrome, when it crashes, it shows a clear error message and stores
crash logs, which help developers fix the issue quickly.

11. Design for Maintainability

Explanation:
Maintaining software means:
 Fixing bugs
 Updating features
 Adapting to new requirements
Design should be:
 Well-documented
 Modular
 Easily readable
Real-World Example:
Open-source projects like WordPress are easily maintainable because of modular
plugin-based design and clear documentation.
12. Design for Installability
Explanation:
This means making sure the software can be installed easily by users or system
admins.
Features:
 One-click installer
 Minimal configuration required
 Clear instructions
Real-World Example:
Applications like Zoom or VLC Player offer very simple installation processes –
just double-click the setup file and follow steps.

13. Interoperability Design

Explanation:
Software should be able to exchange data and work with other systems or
services smoothly.
Common Methods:
 REST APIs
 XML/JSON data formats
 Webhooks
Real-World Example:
Google Calendar can sync with Outlook Calendar, showing interoperability
between systems from different companies.

14. Challenges During Design and Development Phases

Common Challenges:
 Incomplete or changing requirements
  Tight deadlines
 Technical complexity
 Communication gap between team and client
 Budget limitations
Real-World Example:
In a project for a government e-governance portal, frequent changes in
regulations caused redesigning of modules, increasing time and cost.

15. Skill Sets for Design and Development

Design Phase Skills:
 System architecture
 UML diagramming
 Requirement analysis
 User experience understanding
Development Phase Skills:
 Programming (Java, Python, etc.)
 Version control (Git)
 Debugging and testing
 Integration with databases and APIs
Real-World Example:
A UI designer working on a health-tracking app needs skills in Figma, color
psychology, and layout, while a developer needs to know Flutter and Firebase
integration.
16. Metrics for Design and Development Phases
Why Metrics?
To track progress, identify bottlenecks, and measure quality.
Design Metrics:
 Number of modules designed
 Design complexity
 Cohesion and coupling levels
Development Metrics:
 Lines of Code (LOC)
 Defect density = Bugs per 1000 LOC
 Code coverage = % of code tested
 Time to deliver each feature/module
Real-World Example:
In a software project, if code coverage is only 40%, it means a large part of code is
not tested—risk of bugs is high.