Course Notes: Perform Requirements
Analysis
Learning Outcome 1: Perform Requirements Analysis
Learning Hours: 10
1. Perform Requirements
Analysis
1.1. Terms of reference are properly analysed according to industry
quality assurance standards.
1.2 Requirement specification is effectively examined based on
industry standards, project objectives, and stakeholder needs.
1.3 Inception report is properly analysed based on established
criteria and project requirements.
1. Introduction to Quality Assurance (QA)
1.1 Definition
● Quality Assurance (QA): A systematic process that ensures products, services,
or systems meet defined quality standards and stakeholder expectations.
● Focus: Prevention of defects rather than detection.
1.2 Stages / Processes of QA
1. Planning – Define objectives, policies, procedures.
2. Design – Align deliverables with quality standards.
3. Implementation – Apply QA practices throughout development.
4. Monitoring & Testing – Verify processes and outputs.
5. Improvement – Continuous refinement based on feedback.
1.3 Types of QA
● Process QA: Ensures processes are effective and efficient.
● Product QA: Ensures final output meets requirements.
● Industry-Specific QA: Tailored to domains (e.g., healthcare, finance, IT).
● Manual QA: Human-driven reviews, inspections, and tests.
● Automated QA: Tool-based testing and verification.
1.4 Standards
● ISO 9001 – International quality management system.
● IEEE 730 – Standard for software quality assurance plans.
● CMMI (Capability Maturity Model Integration) – Process improvement
framework.
1.5 QA vs. QC
Aspect Quality Assurance Quality Control (QC)
(QA)
Focus Process Product
Natur Proactive Reactive
e
Goal Prevent defects Detect defects
1.6 Tools & Techniques
● Checklists
● Reviews/Inspections
● Defect Tracking Systems (Jira, Bugzilla)
● Automated Testing Tools (Selenium, JUnit, Postman)
1.7 Benefits of QA
● Prevents costly errors.
● Builds stakeholder confidence.
● Improves efficiency and reliability.
● Enhances customer satisfaction.
2. Analysing Terms of Reference (TOR)
2.1 Definition
● TOR (Terms of Reference): A formal document that defines the purpose, scope,
and structure of a project or assignment.
2.2 Purpose
● Clarifies project direction.
● Defines roles and responsibilities.
● Sets clear stakeholder expectations.
2.3 Elements of TOR
● Background/Context
● Objectives
● Scope of Work
● Deliverables
● Roles & Responsibilities
● Timeline
● Resources & Budget
● Evaluation Criteria
2.4 Importance of TOR
● Prevents misunderstandings.
● Provides reference during project execution.
● Helps in performance evaluation.
2.5 Test Cases for TOR
● Are objectives clearly stated?
● Are roles/responsibilities well defined?
● Is the scope realistic and achievable?
2.6 TOR Analysis Report Structure
1. Introduction – Purpose of the TOR.
2. Analysis – Strengths, weaknesses, and gaps.
3. Findings – Issues identified.
4. Recommendations – Suggested improvements.
3. Examining Requirement Specification
3.1 Definition
● A requirement specification documents functional and non-functional
requirements.
● Basis for system design, development, and testing.
3.2 Functional Requirements
● Define what the system should do.
● Example: “System must allow users to log in with email and password.”
3.3 Non-Functional Requirements
● Define how the system should perform.
● Example: “System must support 1000 concurrent users with <2s response time.”
3.4 Steps in Requirement Specification Analysis
1. Review entire document – Ensure completeness.
2. Understand stakeholder requirements – Align with business goals.
3. Verify consistency and completeness – Eliminate contradictions.
4. Identify dependencies & interactions – Clarify relationships.
5. Generate findings document – Record issues, risks, and recommendations.
4. Analysing Inception Report
4.1 Definition
● The inception report summarizes initial project plans, stakeholder expectations,
and feasibility considerations.
4.2 Steps in Analysis
1. Document Review – Check for all required sections.
2. Understand Stakeholder Expectations – Confirm goals and priorities.
3. Assess Clarity & Completeness – Ensure no ambiguities.
4. Evaluate Feasibility & Risks – Identify risks (technical, financial,
organizational).
5. Document Assumptions & Constraints – Record dependencies and limitations.
6. Document Analysis Findings – Report on risks and improvements.