Unit 4

Smart Notes: Software Requirements

Specification (SRS)
1. Introduction to SRS
●​ A Software Requirements Specification (SRS) is a detailed document describing a
software system's requirements.
●​ It includes functional and non-functional requirements.
●​ Developed based on an agreement between the customer and contractors.
●​ Used as a reference for developers, testers, and project managers.

2. Features of a Good SRS

2.1 Correctness

●​ Ensures the accuracy of requirements.

●​ Must cover all essential system needs.
●​ Verified through user reviews.

2.2 Completeness

●​ Includes:
○​ All essential requirements (functionality, performance, design constraints,
external interfaces).
○​ System responses to valid and invalid inputs.
○​ Full labels for figures, tables, and terms.

2.3 Consistency

●​ Requirements should not contradict each other.

●​ Three types of conflicts:
1.​ Real-world conflicts: e.g., One requirement states an output should be in a
table, another in text.
2.​ Temporal conflicts: e.g., One rule states that A follows B, another requires
A and B to occur together.
3.​ Terminology conflicts: Different terms used for the same element (e.g.,
"prompt" vs. "cue").

2.4 Unambiguity
 ●​ Each requirement should have only one interpretation.
●​ Ambiguous terms should be defined clearly.

2.5 Ranking for Importance & Stability

●​ Prioritize requirements using labels like:

○​ Essential (must-have)
○​ Conditional (nice-to-have)
○​ Optional (low-priority)

2.6 Modifiability

●​ Should allow for easy updates.

●​ Modifications should be indexed and cross-referenced.

2.7 Verifiability

●​ Every requirement must be testable.

●​ Helps ensure software meets specifications.

2.8 Traceability

●​ Ability to track each requirement’s origin and reference it in future modifications.

●​ Types:
○​ Backward Traceability: Links requirements to their sources.
○​ Forward Traceability: Links requirements to future implementation and
design.

2.9 Design Independence

●​ Should focus on what the system does, not how it is implemented.

2.10 Testability

●​ Requirements should be written in a way that allows easy test case generation.

2.11 Understandability

●​ Should be clear for non-technical users.

●​ Avoid excessive technical jargon.

2.12 Right Level of Abstraction

●​ Early-stage requirements → More abstract.

●​ Later stages → More detailed.
3. Properties of a Good SRS Document
●​ Concise: Avoid unnecessary information.
●​ Structured: Clear formatting for readability.
●​ Black-box View: Defines system behavior without implementation details.
●​ Conceptual Integrity: Should maintain logical flow.
●​ Verifiable: Should be testable.

Common Issues in SRS Writing

❌ Complex conditional statements​

❌ Inconsistent terminology​
❌ Assumes prior knowledge from readers
✅ Solution: Use clear writing, diagrams, and standardized terminology.

4. Best Practices for Writing SRS

4.1 Use Standard Templates

●​ Benefits:
○​ Improves readability.
○​ Acts as a checklist for analysts.
○​ Ensures consistency.

4.2 Use Simple & Consistent Language

●​ Short sentences improve readability.

●​ Avoid nested conditions (use decision tables instead).
●​ Define technical terms consistently.
●​ Use consistent terminology (e.g., "shall" for mandatory requirements).

4.3 Use Diagrams Effectively

●​ Use block diagrams for system structure.

●​ Use flowcharts for sequences.
●​ Keep diagrams simple and labeled.

4.4 Supplement Natural Language with Other Representations

●​ Decision tables for complex conditions.

●​ Mathematical expressions for numeric processing.
●​ Entity-relationship models for system structure.
5. Key Takeaways
✅ A good SRS ensures clear, unambiguous, and complete documentation of
✅ Maintains traceability, verifiability, and modifiability.​
requirements.​

✅ Uses structured writing, standard templates, and diagrams to improve clarity.​

✅ Simplifies communication between customers, developers, and testers.

6. Possible Exam Questions

1.​ Define Software Requirements Specification (SRS) and explain its importance.
2.​ List and describe five characteristics of a good SRS.
3.​ What are the common consistency issues in an SRS? Provide examples.
4.​ Explain the difference between functional and non-functional requirements
with examples.
5.​ Describe the importance of traceability in SRS.
6.​ How can diagrams improve the clarity of an SRS?
7.​ Explain the ranking of requirements and why it is necessary.
8.​ What are the challenges of writing a well-structured SRS, and how can they be
overcome?
9.​ Describe backward and forward traceability with examples.
10.​How does an SRS contribute to software testing and quality assurance?

7. Memory Aids (Mnemonics)

Key Features of a Good SRS – “CCU-RMVT-DTU”

●​ Correctness
●​ Completeness
●​ Unambiguity
●​ Rank for importance
●​ Modifiability
●​ Verifiability
●​ Traceability
●​ Design independence
●​ Testability
●​ Understandability

🚀
These notes provide a structured, exam-focused summary of the key concepts in SRS,
making revision easy and effective. Let me know if you need any modifications!
Requirement Validation - Exam-Focused
Smart Notes
1. Objectives of Requirement Validation
Requirement validation ensures that the defined system requirements are correct, complete,
and aligned with stakeholders' needs. Key objectives include:

●​ Checking the completeness and consistency of requirements.

●​ Identifying and resolving ambiguities or conflicts.
●​ Ensuring conformance to quality standards.
●​ Avoiding costly errors in later stages.

Key Takeaways:

●​ Validation is the final check before development begins.

●​ Detecting errors early reduces rework costs (can be up to 100 times higher in later
stages).
●​ Involves stakeholders, engineers, and designers.

2. Difference Between Requirement Analysis &

Validation
Requirement Analysis

●​ Deals with raw requirements gathered from stakeholders.

●​ Requirements are often incomplete, informal, and unstructured.
●​ Identifies conflicts and inconsistencies during elicitation and negotiation.

Requirement Validation

●​ Works with finalized requirements document.

●​ Ensures completeness and adherence to quality standards.
●​ Confirms that the requirements represent a clear system description.
●​ Last chance for corrections before development starts.

3. Challenges in Requirement Validation

 ●​ No direct reference to validate against (unlike program validation against a
specification).
●​ Stakeholders must agree on correctness.
●​ Time-consuming; may require prototyping and multiple meetings.
●​ Rushing validation increases rework later.

Possible Exam Questions:

1.​ Why is requirement validation important?

2.​ How does requirement validation differ from requirement analysis?
3.​ What are the common challenges in requirement validation?

4. Techniques for Requirement Validation

A. Check Standards Compliance

Process:

●​ A single analyst checks whether the document follows defined standards.

●​ Checks for missing sections, numbering, labeling of diagrams, etc.
●​ If deviations exist, either:
1.​ Return to the engineering team for corrections.
2.​ Distribute as-is with notes if changes are minor.

Benefits:

●​ Quick and cost-effective.

●​ Identifies large-scale issues early.
●​ Prevents wasted review time on structural problems.

B. Formal Requirement Inspections

Process:

●​ A multi-disciplinary team systematically reviews the document.

●​ Issues identified are categorized into:
1.​ Clarifications - Improve poorly worded requirements.
2.​ Missing Information - Retrieve missing details.
3.​ Conflicts - Resolve contradictions between requirements.
4.​ Unrealistic Requirements - Assess feasibility and modify if needed.
●​ A formal meeting is held, chaired by an independent facilitator.

Benefits:

●​ Cost-effective method to catch errors early.

●​ Provides a neutral environment for conflict resolution.
 ●​ Reduces risks of misinterpretation and unrealistic expectations.

Challenges:

●​ Requires significant effort and time (e.g., 40 requirements per hour for a 4-person
team).
●​ Scheduling issues due to involvement of multiple stakeholders.

C. Multi-Disciplinary Team Reviews

Participants:

●​ End-users or their representatives.

●​ Customer representatives.
●​ Domain experts.
●​ System designers and engineers.
●​ Requirement engineers.

Benefits:

●​ Diverse perspectives increase problem detection.

●​ Encourages cross-team understanding.
●​ Improves acceptance of necessary requirement changes.

Challenges:

●​ Hard to get all relevant experts to participate.

●​ Stakeholders may have moved to other projects.

D. Use of Validation Checklists

Purpose:

●​ Provides structured guidance for reviewing requirements.

●​ Helps focus attention on key attributes.

Example Checklist Items:

1.​ Completeness – Are all necessary requirements included?

2.​ Consistency – Do any requirements contradict each other?
3.​ Comprehensibility – Are the requirements easy to understand?
4.​ Ambiguity – Could any requirement be misinterpreted?
5.​ Organization – Are related requirements grouped logically?
6.​ Traceability – Can requirements be linked to their sources?
7.​ Standards Compliance – Do requirements follow established guidelines?

Benefits:

●​ Ensures structured validation.

●​ Helps new validators by guiding them.
 ●​ Saves time by focusing on critical aspects.

Challenges:

●​ Needs balance: too long = overwhelming, too short = ineffective.

●​ Some engineers may resist checklists, viewing them as bureaucratic.

5. Cost-Benefit Analysis of Validation Methods

Method Cost Benefits

Standards Compliance Low Quick identification of structural issues

Check

Formal Inspections Moderate-Hig Reduces major requirement errors, avoids

h costly rework

Multi-Disciplinary Moderate Ensures diverse perspectives, improves

Review requirement quality

Checklists Low Adds structure, aids less experienced

validators

Key Exam Takeaways:

●​ Formal inspections are the most effective but resource-intensive.

●​ Standards checks are quick, cheap, and effective for catching format issues.
●​ Checklists help streamline validation and ensure thorough review.
●​ Multi-disciplinary reviews are useful for real-world feasibility checks.

6. Summary of Best Practices

✅ Start validation early – Don’t rush the process. ✅ Use a mix of techniques – Different
methods catch different issues. ✅ Involve all stakeholders – Ensures alignment and
acceptance. ✅ Check compliance with standards – Ensures document structure and
completeness. ✅ Use checklists for consistency – Reduces oversight and improves
efficiency. ✅ Document findings and resolutions – Avoids redundant discussions.

Final Mnemonic for Requirement Validation Success:

🔹 C – Check standards compliance 🔹 I – Inspect formally 🔹 T – Team-based

multidisciplinary review 🔹 C – Create validation checklists 🔹 H – Highlight missing,
conflicting, or ambiguous requirements
👉 CATCH potential errors early to save time and cost!

Potential Exam Questions:

1.​ What are the main objectives of requirement validation?
2.​ Explain the difference between requirement analysis and validation.
3.​ List and describe four techniques used for requirement validation.
4.​ What are the benefits of using checklists in requirement validation?
5.​ Why is a multi-disciplinary team important in requirement validation?
6.​ What are the common challenges in organizing formal requirement inspections?
7.​ How can requirement validation reduce project costs?

Quick Revision Summary:

●​ Requirement validation ensures final requirements are complete, consistent, and

implementable.
●​ Techniques include standard checks, inspections, team reviews, and checklists.
●​ Early validation saves money by reducing costly rework in later stages.
●​ A structured process (CATCH mnemonic) ensures systematic validation.

🔹 Master these key concepts for your exam success! 🎯

Unit 6

Here are your exam-focused smart notes on Chapter 6: Requirements Management,

summarizing key concepts, definitions, arguments, and takeaways in a structured format for
quick revision.

Requirements Management – Exam

Notes
1. Introduction to Requirements Management

●​ Definition: The process of handling changes and maintaining the quality of system
requirements throughout development and operation.
●​ Importance: Poor requirements management can lead to:
1.​ Customer dissatisfaction.
2.​ Delayed project schedules.
3.​ Increased costs due to rework.
●​ Primary Goals of Requirements Management:
1.​ Managing changes to agreed requirements.
 2.​ Tracking relationships between requirements.
3.​ Ensuring consistency between requirements and other project documents.

2. Causes of Requirements Changes

●​ Errors & misunderstandings during requirements gathering.

●​ Design or implementation problems discovered later.
●​ Evolving stakeholder needs as system understanding improves.
●​ External changes such as:
○​ Economic shifts (affecting business priorities).
○​ Regulatory/legal updates.
○​ New technological advancements.

🔹 Key Takeaway: Requirements management is crucial to adapt to inevitable changes

while keeping development efficient.

3. Key Concepts in Requirements Management

A. Requirements Traceability

●​ Definition: Ability to track a requirement from its origin through design,

implementation, and testing.
●​ Types of Traceability:
○​ Backward traceability: Links requirements to their origins (e.g., stakeholder
input).
○​ Forward traceability: Tracks requirements into design, code, and testing.
●​ Benefits:
○​ Helps assess the impact of changes.
○​ Ensures consistency in documentation.
○​ Improves compliance with regulations.

B. Unique Requirement Identification

●​ Why? To maintain clarity and track changes effectively.

●​ Methods:
○​ Numbering based on document structure.
○​ Assigning mnemonics (e.g., EFF-1 for efficiency-related requirements).
●​ Challenges:
○​ Changing document structure requires renumbering.
○​ Misinterpretation of numbering as a classification system.

✅ Mnemonic for Traceability: “FIT” – Find, Identify, Track

●​ Find the origin, Identify dependencies, Track changes.
4. Policies in Requirements Management

A. Requirements Management Policies

●​ Purpose: Defines standards, processes, and goals for handling requirements.

●​ Key Elements:
○​ Objectives of requirements management.
○​ Documentation & reporting guidelines.
○​ Change management policies.
○​ Validation & review protocols.
○​ Traceability policies.
●​ Challenges:
○​ Takes time to define and implement.
○​ Requires buy-in from all stakeholders.

B. Traceability Policies

●​ Purpose: Defines what traceability information to maintain and how.

●​ Methods of Maintaining Traceability:
○​ Tables (cross-referencing requirements).
○​ Lists (attaching traceability data to each requirement).
○​ Databases (automated linking for efficiency).
●​ Cost Considerations:
○​ Small systems: Moderate costs.
○​ Large systems: Higher complexity and costs.

🔹 Key Takeaway: Lightweight policies are better than overly bureaucratic ones.

5. Managing Requirements Using Databases

●​ Benefits:
○​ Efficient organization & searching.
○​ Improved traceability.
○​ Easier concurrent access for teams.
○​ Automated processing of requirements.
●​ Database Selection Factors:
○​ Volume of requirements (small = PC database, large = server-based).
○​ Type of data (text vs. multimedia).
○​ Multi-site access needs.
○​ Existing database expertise.
●​ Challenges:
○​ High initial setup cost.
○​ Linking database with the formal requirements document.
✅ Quick Tip: Using databases enables automated traceability & change tracking,
reducing manual errors.

6. Change Management in Requirements

A. Change Management Policies

●​ Why? To ensure cost-effective and controlled modifications to requirements.

●​ Key Elements:
1.​ Formal Change Request Process: Stakeholders submit structured requests.
2.​ Impact Analysis: Assess costs & side effects of changes.
3.​ Approval Mechanism: Decisions by a Change Control Board (CCB).
4.​ Software Support: Use of change management tools or databases.

🔹 Key Takeaway: A structured change control system prevents uncontrolled

"requirement drift."

B. Identifying Volatile Requirements

●​ Definition: Requirements that are likely to change over time.

●​ Types of Volatile Requirements:
1.​ Mutable: Changes due to external factors (e.g., tax laws).
2.​ Emergent: Unclear at first but develop over time (e.g., UI design).
3.​ Consequential: Depend on assumptions that might be incorrect.
4.​ Compatibility: Depend on external systems or hardware.

✅ Mnemonic for Volatile Requirements: “MECC” – Mutable, Emergent,

Consequential, Compatibility

●​ Why track them? Helps in system design by isolating volatile components.

📌 Possible Exam Questions

1.​ Define requirements management and explain its key goals.
2.​ What are the common causes of requirements changes? Provide examples.
3.​ Explain requirements traceability and its types. Why is it important?
4.​ What are the benefits and challenges of using databases for requirements
management?
5.​ Describe the steps involved in a formal change management process.
6.​ List and explain the different types of volatile requirements.
7.​ Discuss the impact of poor requirements management on software projects.
8.​ What are the key elements of effective traceability policies?
9.​ Compare and contrast traceability tables, lists, and databases.
 10.​Why is unique requirement identification important? What methods can be
used?

📝 Final Key Takeaways

✔ Requirements always evolve, so traceability is crucial.​
✔ Change management policies prevent uncontrolled modifications.​
✔ Databases enhance efficiency but come with setup costs.​
✔ Volatile requirements should be identified early for better system design.​
✔ Good requirements management saves time & cost in the long run.

🚀
This structured summary is optimized for quick revision and easy recall. Let me know if
you’d like additional explanations, examples, or mnemonics!

Unit 8

Here are exam-focused smart notes for Chapter 8: Requirements Engineering

Techniques, summarizing key concepts, definitions, methods, and takeaways for quick
revision and easy recall.

Requirements Engineering Techniques –

Smart Notes
1. Introduction to Requirements Engineering
●​ Definition: The process of defining, documenting, and maintaining system
requirements.
●​ Purpose:
○​ Helps in understanding, analyzing, and documenting user needs.
○​ Ensures the development of high-quality software that meets user
expectations.

🔹 Key Takeaway: A well-structured requirements engineering process reduces project

risks and improves software quality.

2. Methods for Requirement Engineering

Several elicitation techniques exist to gather requirements effectively.

1. Interviews

●​ Definition: Direct interaction with stakeholders to collect system requirements.

●​ Types of Interviews:
○​ Individual Interviews: One-on-one discussion with a stakeholder.
○​ Group Interviews: Multiple stakeholders discuss requirements together.
●​ Structured vs. Unstructured Interviews:
○​ Structured: Predefined, focused questions → Efficient but rigid.
○​ Unstructured: Open-ended discussion → Flexible but can go off-topic.
●​ Best Practices:
○​ Define clear interview goals.
○​ Identify participants (e.g., product owner, end-users).
○​ Use a mix of open-ended and closed questions.
○​ Document responses and validate findings.

✅ Pros:​
✔ Easy to schedule & conduct.​
✔ Provides detailed insights from key stakeholders.

❌ Cons:​
✖ Risk of off-topic discussions.​
✖ Stakeholders may introduce unnecessary features.

2. Questionnaires & Surveys

●​ Definition: Structured forms used to collect data from multiple users.

●​ Uses:
○​ Gather feedback on existing systems.
○​ Validate assumptions with statistical evidence.
●​ Common Question Types:
○​ Likert Scales: (e.g., Strongly Agree → Strongly Disagree)
○​ Rating Scales: (0–5 or 0–10)
○​ Checkboxes/Drop-downs: Predefined answers for controlled responses.
○​ Text Boxes: Open-ended responses (difficult to analyze).
●​ Best Practices:
○​ Pilot test the questionnaire before distributing.
○​ Keep questions clear and concise.
○​ Mix quantitative (ratings) and qualitative (text responses).

✅ Pros:​
✔ Cost-effective (suitable for large user groups).​
✔ Helps in trend analysis & identifying key problem areas.
❌ Cons:​
✖ Misinterpretation risk with closed questions.​
✖ Open-ended responses are hard to analyze.

3. Brainstorming

●​ Definition: A creative technique for generating new ideas & solutions.

●​ Steps:
○​ Define problem statement.
○​ Set brainstorming rules (e.g., no criticism of ideas).
○​ Encourage free-thinking and build on ideas.
○​ Categorize & prioritize ideas.
●​ Best Practices:
○​ Send agenda before the session.
○​ Assign a facilitator to guide discussions.
○​ Use a whiteboard/mind maps to document ideas.

✅ Pros:​
✔ Encourages innovation & out-of-the-box thinking.​
✔ Helps gather diverse perspectives.

❌ Cons:​
✖ Some people may hesitate to speak in a group.​
✖ Ideas can drift off-topic.

4. User Observation

●​ Definition: Watching users perform tasks to understand workflows and pain

points.
●​ Types:
○​ Active Observation: Asking questions while observing.
○​ Passive Observation: Silent, non-intrusive monitoring.
●​ Best Practices:
○​ Construct end-to-end process maps.
○​ Observe real user actions without interference.
○​ Collect supporting documents (e.g., manuals, workflows).

✅ Pros:​
✔ Provides real-world user insights.​
✔ Identifies implicit behaviors that users may not articulate.

❌ Cons:​
✖ Time-consuming.​
✖ Users may alter behavior when being observed.
5. Document Analysis

●​ Definition: Reviewing existing documentation to understand current processes.

●​ Common Documents Analyzed:
○​ Business plans (process details, workflows).
○​ User manuals (functional understanding).
○​ System specifications (technical constraints).
●​ Best Practices:
○​ Identify gaps & outdated information.
○​ Cross-check with stakeholder interviews.

✅ Pros:​
✔ Useful when stakeholders are unavailable.​
✔ Helps validate requirements from other sources.

❌ Cons:​
✖ Documents may be outdated.​
✖ Time-consuming to review large volumes of information.

3. Viewpoint-Oriented Requirements Methods

●​ Definition: Captures multiple stakeholder perspectives to ensure no key
requirements are overlooked.
●​ Examples of Viewpoints:
○​ Drivers (for a traffic light system).
○​ Pedestrians (safety requirements).
○​ Regulatory bodies (compliance).
●​ Benefits:
○​ Improves requirement completeness.
○​ Helps in conflict resolution between stakeholders.
○​ Enhances traceability of requirements.

4. PREview: A Structured Viewpoints Approach

●​ Definition: A systematic way to identify, analyze, and manage stakeholder
viewpoints.
●​ Key Steps in PREview:
1.​ Elicitation → Identify viewpoints & collect requirements.
2.​ Analysis → Identify inconsistencies or redundancies.
3.​ Negotiation → Resolve conflicts & refine requirements.
4.​ Documentation → Organize verified requirements.
✅ Pros:​
✔ Reduces missed requirements.​
✔ Helps in managing conflicting stakeholder needs.

❌ Cons:​
✖ Can be complex for small projects.

📌 Possible Exam Questions

1.​ What is requirements engineering? Why is it important?
2.​ Compare and contrast structured vs. unstructured interviews in requirement
elicitation.
3.​ Explain the advantages and disadvantages of using questionnaires for
requirement gathering.
4.​ Describe the brainstorming technique and its role in requirement engineering.
5.​ Why is document analysis useful in requirement engineering? What are its
limitations?
6.​ What are the benefits of a viewpoint-oriented approach to requirement
elicitation?
7.​ Explain the PREview approach and its three key activities.
8.​ How does user observation improve requirement gathering?
9.​ List and describe different types of stakeholders in a requirement engineering
process.
10.​Discuss the role of negotiation in requirement engineering and why it is
necessary.

📝 Final Key Takeaways

✔ Interviews are direct & detailed, but risk off-topic discussions.​
✔ Surveys are cost-effective, but require careful question design.​
✔ Brainstorming fosters innovation, but requires focus control.​
✔ User observation provides real-world insights, but is time-intensive.​
✔ Document analysis helps with cross-validation, but may be outdated.​
✔ Viewpoint-based approaches reduce missed requirements & improve traceability.

🚀
These structured notes ensure efficient revision & easy recall. Let me know if you need
further clarifications, examples, or mnemonics!
Unit 9

Software Requirement and Risk

Management – Smart Notes
1. Introduction to Risk Management
●​ Definition: A risk is a potential condition that could cause loss or threaten the
success of a project.
●​ Risk vs. Issue:
○​ Risk: A potential problem that hasn’t occurred yet but may impact cost,
schedule, quality, or team effectiveness.
○​ Issue: A current problem that must be resolved.
●​ Risk Management: The process of identifying, evaluating, and controlling risks
before they become issues.

✅ Key Takeaway: Risk management improves project success by dealing with risks before
they turn into crises.

2. Fundamentals of Software Risk Management

Common Sources of Risk:

1.​ Requirements Risks:

○​ Misunderstanding requirements.
○​ Inadequate user involvement.
○​ Constantly changing scope.
2.​ Project Management Risks:
○​ Poor estimation & unrealistic deadlines.
○​ Staff turnover & insufficient visibility into progress.
3.​ Technology Risks:
○​ Dependence on cutting-edge technology (unproven solutions).
○​ Lack of team experience with new methods/tools.
4.​ External Dependencies:
○​ Relying on subcontractors or other projects for components.
5.​ Regulatory Risks:
 ○​ Changes in government regulations affecting project scope.

✅ Key Takeaway: Every project must identify and control risks to prevent failure.

3. Elements of Risk Management

Risk Management Process:

1.​ Risk Assessment:

○​ Identifying potential threats and risks.
○​ Using checklists and industry risk databases.
2.​ Risk Analysis:
○​ Examining the probability & impact of each risk.
○​ Calculating risk exposure using: Risk Exposure=Probability×Impact\text{Risk
Exposure} = \text{Probability} \times \text{Impact}
3.​ Risk Prioritization:
○​ Focusing on high-probability, high-impact risks first.
4.​ Risk Avoidance & Mitigation:
○​ Avoidance: Not doing the risky activity (e.g., skipping unproven tech).
○​ Mitigation: Reducing probability/impact (e.g., more testing, prototypes).
5.​ Risk Resolution & Monitoring:
○​ Implement mitigation plans.
○​ Track risk status and adjust strategies.

✅ Key Takeaway: Not all risks can be avoided—the goal is reducing their impact.

4. Documenting Project Risks

●​ Risk Statements Format: Use a Condition → Consequence structure:
○​ If the customers don’t agree on the product requirements,
○​ Then we might be able to satisfy only one major customer.
●​ Risk Tracking Methods:
○​ Spreadsheets & databases to list risks.
○​ Risk logs separate from project plans (for frequent updates).
●​ Quantifying Risks:
○​ Probability: 0.1 (unlikely) → 1.0 (certain).
○​ Impact: 1 (low) → 10 (severe).
○​ Risk Exposure Calculation: Risk Exposure=Probability×Impact\text{Risk
Exposure} = \text{Probability} \times \text{Impact}
●​ Mitigation Cost Analysis:
○​ Ensure mitigation costs don’t exceed potential losses.
○​ Example: Spending $20,000 to control a risk worth only $10,000 is not
justified.
✅ Key Takeaway: Risk documentation should be systematic, quantified, and
action-oriented.

5. Planning for Risk Management

●​ Small projects: Include risk management in the Project Management Plan.
●​ Large projects: Create a separate Risk Management Plan with:
○​ Risk Identification Methods.
○​ Evaluation & Documentation Processes.
○​ Tracking Responsibilities.
●​ Risk Managers: Some projects appoint dedicated risk managers.
●​ Regular Risk Monitoring:
○​ Track top 10 risks.
○​ Reassess mitigation success.
○​ Update risks & priorities.

✅ Key Takeaway: Risk management must be continuous and proactive.

6. Requirements-Related Risks & Mitigation Strategies

6.1. Requirements Elicitation Risks
Risk Factor Mitigation Strategy

Unclear Scope & Vision Define a Vision & Scope Document early.

Tight schedules Allocate sufficient time for requirement gathering.

Lack of Customer Involvement Identify key stakeholders early & involve them.

Missing Non-Functional Explicitly query customers about performance,

Requirements security, etc.

Conflicting Customer Needs Use Product Champions to resolve disputes.

6.2. Requirements Analysis Risks

Risk Factor Mitigation Strategy

Poor Prioritization Rank features based on business value &

impact.

Technically Difficult Features Conduct feasibility analysis & create prototypes.

 Unfamiliar Technologies Allow time for learning & training.

6.3. Requirements Specification Risks

Risk Factor Mitigation Strategy

Ambiguous Terminology Maintain a glossary of terms.

Unclear Requirements Use diagrams, models, & peer reviews.

Design Constraints in Focus on "What" needs to be done, not "How".

Requirements

6.4. Requirements Validation Risks

Risk Factor Mitigation Strategy

Skipping Reviews Plan incremental validation sessions.

Untrained Reviewers Train team members in requirement

inspection.

6.5. Requirements Management Risks

Risk Factor Mitigation Strategy

Scope Creep (Uncontrolled Use strict change control processes.

Changes)

Unimplemented Requirements Use traceability methods to track missing

requirements.

✅ Key Takeaway: Managing requirements effectively reduces scope creep & project
failures.

7. Risk Management in Agile vs. Waterfall

Factor Agile Approach Waterfall Approach

Requirements Continuous, evolving Defined upfront

Gathering
 Risk Control Iterative risk Early-stage risk
assessment planning

Requirement Changes Easier to adapt More rigid

✅ Key Takeaway: Agile mitigates risks incrementally, while Waterfall plans upfront.

📌 Possible Exam Questions

1.​ Define risk and explain the difference between risk and an issue.
2.​ What are the key steps in the risk management process?
3.​ How do you quantify risk exposure? Provide an example.
4.​ Explain the importance of documenting risks and risk tracking methods.
5.​ What are common requirements-related risks? How can they be mitigated?
6.​ Compare and contrast risk management in Agile vs. Waterfall.
7.​ What strategies can be used to prevent scope creep in software projects?
8.​ Why is stakeholder involvement important in risk management?
9.​ Explain the role of a risk manager in large projects.
10.​What are the benefits of periodic risk monitoring?

📝 Final Key Takeaways

✔ Risk management prevents costly project failures.​
✔ Prioritize risks based on probability × impact.​
✔ Requirements-related risks are among the most critical.​
✔ Proper documentation & tracking improve risk control.​
✔ Agile & Waterfall handle risk differently—choose wisely.

🚀
These structured notes optimize revision and ensure easy recall for exams. Let me know
if you need clarifications, examples, or mnemonics!