Unit 2: Requirements and project management
Software Engineering notes · PTU syllabus (UGCC2514)
On this page
Unit summary
Most software failures come from unclear requirements or poor project management. This unit covers functional and non-functional requirements, the requirements engineering process, risk management with the RMMM plan, software pricing, project scheduling, agile planning and estimation techniques.
After this unit you can
- Distinguish functional and non-functional requirements and write an SRS
- Explain elicitation, analysis, validation and management of requirements
- Identify, project and mitigate risks using an RMMM plan
- Schedule a project and estimate effort and cost
PTU syllabus topics
- Functional and non-functional requirements
- requirements specification and engineering processes
- elicitation
- analysis
- validation and management
- risk strategies
- identification
- projection
- refinement
- RMMM plan
- software pricing
- plan-driven development
- project scheduling
- agile planning
- estimation techniques
- 1Elicitation
Gather needs from users
- 2Analysis
Resolve conflicts and gaps
- 3Specification
Write the SRS
- 4Validation
Confirm with stakeholders
- 5Management
Track changes over time
Topic 1
Functional and non-functional requirements
Describes
What the system must do
How well it must do it
Examples
"Student can register for a course"; "System generates a fee receipt"
Response under 2 seconds; 99.9% availability; data encrypted
Testing
Tested by functional tests
Tested by performance, security, usability tests
A Software Requirements Specification (SRS) documents all requirements. A good SRS is correct, unambiguous, complete, consistent, verifiable, modifiable and traceable.
Topic 2
Requirements engineering process
- 1
Inception
Understand the problem and stakeholders
- 2
Elicitation
Interviews, questionnaires, observation, workshops, use cases
- 3
Analysis and negotiation
Resolve conflicts, prioritise
- 4
Specification
Write the SRS
- 5
Validation
Reviews, prototypes, test-case generation
- 6
Management
Track changes with traceability
Exam tip
Requirements must be validated with the customer before design — fixing a requirement error after delivery can cost many times more than fixing it early.
Topic 3
Risk management and the RMMM plan
A risk is a potential problem that may or may not happen. Types: project risks (budget, schedule, staff), technical risks (design, technology) and business risks (market, management support).
- Reactive strategy: fix problems after they happen. Proactive strategy: identify and plan for risks in advance.
- Risk projection estimates each risk's probability and impact; risk exposure = probability × cost.
- RMMM plan — Mitigation, Monitoring and Management: reduce the chance of the risk, watch for warning signs, and have a contingency plan ready.
Example
Risk: a key developer may leave (probability 30%). Mitigation: pair programming and documentation; monitoring: team morale; management: a trained backup developer.
Topic 4
Pricing, scheduling and agile planning
- Software pricing depends on effort cost, market opportunity, contractual terms, requirement volatility and financial health — price is not just cost.
- Plan-driven development: a detailed plan with milestones and deliverables made at the start.
- Project scheduling: break work into tasks, estimate durations, identify dependencies, and show them in Gantt charts and activity networks (PERT/CPM). The critical path is the longest path and decides the project duration.
- Agile planning: release planning and iteration (sprint) planning based on user stories and the team's velocity.
Topic 5
Estimation techniques
| Technique | How it works |
|---|---|
| Lines of code (LOC) | Estimate size in KLOC, then effort per KLOC |
| Function points (FP) | Count inputs, outputs, inquiries, files and interfaces, weighted for complexity |
| COCOMO | Effort = a × (KLOC)ᵇ person-months; organic, semi-detached, embedded modes |
| Expert judgement / Delphi | Experts estimate independently, then converge |
| Story points (agile) | Relative size of user stories; planning poker |
Example
Basic COCOMO, organic mode: Effort = 2.4 × (KLOC)^1.05. For 10 KLOC, Effort ≈ 2.4 × 11.2 ≈ 27 person-months.
Key terms
- SRS
- Software Requirements Specification document
- Elicitation
- Gathering requirements from stakeholders
- RMMM
- Risk mitigation, monitoring and management plan
- Critical path
- The longest path of dependent tasks in a schedule
- Function point
- A measure of software size based on functionality
Quick revision
- Functional = what; non-functional = how well.
- RE: inception, elicitation, analysis, specification, validation, management.
- Risk exposure = probability × impact cost.
- COCOMO: Effort = a(KLOC)ᵇ.
Important exam questions
Practice questions written to the PTU exam pattern for this unit's syllabus: short answers (Section A style) and long answers (Sections B and C style).
Short-answer questions
- Q1.Differentiate between functional and non-functional requirements.
- Q2.List the characteristics of a good SRS.
- Q3.What is requirements elicitation?
- Q4.What is an RMMM plan?
- Q5.What is the critical path?
- Q6.Name three software estimation techniques.
Long-answer questions
- Q1.Explain the requirements engineering process in detail.
- Q2.Explain risk management, including risk identification, projection and the RMMM plan.
- Q3.Explain project scheduling and the use of Gantt charts and activity networks.
- Q4.Explain software estimation techniques including function points and COCOMO.
Stuck on this unit?
Message SBS on WhatsApp for help with Software Engineering, or to ask about studying BCA at Synetic.