Requirements Engineering: The process of identifying, eliciting, analyzing, specifying, validating and managing stakeholders’ needs and expectations for a software system (creating and maintaining the system requirements document).
Causes
Not specified in notes
Goals / Objectives
Produce a complete, correct and managed set of system requirements that stakeholders agree on.
Importance
Foundation for correct design, implementation and testing; reduces misunderstandings and rework.
Procedures
The process includes five activities (detailed in following subtopics).
Advantages & Disadvantages
Not specified in notes
Impact / Effect
Good requirements engineering produces clear SRS documents that guide the whole project.
Examples
Not specified in notes
Key Takeaways
Requirements engineering covers elicitation through management.
It ensures stakeholder needs are captured, checked, and maintained.
5 Activities in Requirements Engineering (overview)
Definition
The five main activities that make up requirements engineering.
Causes
Need to structure all work around requirements creation and maintenance.
Goals / Objectives
Break down the discipline into manageable, repeatable steps.
Importance
Each activity addresses different risk areas: feasibility, correctness, traceability, validation and change.
Procedures
The five activities:
Feasibility Studies
Requirements Elicitation and Analysis
Requirements Specification (covered in Chapter 4)
Requirements Validation
Requirements Management
Advantages & Disadvantages
Not specified in notes
Impact / Effect
Using these activities systematically reduces project risk and improves requirement quality.
Examples
Chapter uses feasibility topics and viewpoint analysis to illustrate these activities.
Key Takeaways
Follow the five-step process from feasibility to management.
Specification and validation ensure requirements are usable and correct.
1. Feasibility Studies
Definition
Assessment activities to decide whether the project should proceed.
Causes
Need to check technical, financial, legal, operational and scheduling viability before committing resources.
Goals / Objectives
Determine if project is technically possible, financially sensible, legally compliant, operationally maintainable and schedulable.
Importance
Prevents starting projects that are unworkable, unprofitable or non-compliant.
Procedures
Types of feasibility checks:
Technical feasibility: Is the project technically possible?
Economic feasibility: Does it make financial sense?
Legal feasibility: How can legal limitations affect the project?
Operational feasibility: How hard is it to maintain and manage the project?
Scheduling feasibility: Can realistic deadlines be met?
Examples in notes:
Legal feasibility example mentions medical software and HIPAA (as compliance illustration).
Schedule feasibility: analyze timelines/deadlines to ensure the project can be completed on time.
Advantages & Disadvantages
Advantage: Identifies showstoppers early.
Disadvantage: Not specified in notes.
Impact / Effect
Influences go/no-go decisions and early scope definition.
Examples
Medical software needing HIPAA compliance (legal feasibility) as described.
Key Takeaways
Feasibility covers technical, economic, legal, operational and schedule checks.
Feasibility avoids wasting effort on infeasible projects.
2. Requirements Elicitation & Analysis
Definition
Activities to discover, classify, prioritize, negotiate and document system requirements; derive system requirements from stakeholder input.
Causes
Stakeholders’ needs must be discovered and reconciled; stakeholders may be unclear or use different terms.
Goals / Objectives
Discover requirements from stakeholders, classify and organize them, prioritize and negotiate conflicts, and document complete and consistent requirements.
Importance
This phase is difficult but critical because unclear stakeholder needs and political or business changes can derail projects.
Procedures
Core activities (notes list):
Requirement Discovery: interact with stakeholders; use sources: stakeholders, documentation, similar system specifications.
Requirement Classification & Organization: group requirements into clusters and remove overlaps.
Requirement Prioritization & Negotiation: prioritize and resolve conflicts.
Requirement Documentation: produce complete, consistent documentation aligned with stakeholders.
These help reveal implicit requirements and focus on end-user needs.
Advantages & Disadvantages
Advantage: Structured elicitation techniques help find implicit requirements.
Disadvantage: Stakeholders often unclear, use own terms, and express needs differently; political/economic changes complicate analysis.
Impact / Effect
Proper analysis yields traceable, testable requirements; poor analysis results in ambiguous or conflicting SRS items.
Examples
Hotel Management example for classification (Customer Registration, Check In, Room Reservation, Check Out, Print Report).
Stakeholder issues listed: unclear wants; stakeholders using own terms; different expression styles.
Key Takeaways
Elicitation + analysis is hard but essential; use multiple techniques and organize requirements clearly.
Expect stakeholder ambiguity and political change; classify and prioritize to resolve conflicts.
Viewpoint-oriented Analysis (part of elicitation)
Definition
An approach that collects requirements by identifying viewpoints representing different stakeholder perspectives.
Causes
Large systems have many stakeholders; organizing viewpoints reduces elicitation effort and helps coverage.
Goals / Objectives
Identify interactor, indirect and domain viewpoints and organize them in a hierarchy to share and reuse common requirements.
Importance
Reduces the need to interview every stakeholder; ensures coverage and validity of viewpoints.
Procedures
Types of viewpoints (from notes):
Interactor Viewpoints — interact directly with system (features & interfaces). Examples: bank customers, bank staff, bank database.
Indirect Viewpoints — do not use system but influence requirements (high-level requirements & constraints). Examples: managers, security staff, marketing staff.
Domain Viewpoints — domain constraints and standards (e.g., interbank communication standards, UI standards, classification standards).
Additional viewpoint roles listed: providers & receivers of system services; regulations & standards; marketing viewpoint; other systems interfacing directly; engineering viewpoint.
Create a viewpoint hierarchy for large systems to:
Disadvantages: Not explicitly listed; implied that constructing correct hierarchies requires judgment.
Impact / Effect
Helps focus elicitation on representative viewpoints rather than every individual stakeholder.
Examples
College library and online hotel reservation viewpoint hierarchies given in notes.
Key Takeaways
Use viewpoints (interactor, indirect, domain) and hierarchies to organize elicitation.
Hierarchies let analysts treat similar stakeholders collectively and ensure coverage.
Requirement Classification & Organization
Definition
Grouping requirements into logical clusters and removing overlaps.
Causes
Raw elicited requirements are often scattered and duplicated.
Goals / Objectives
Produce structured requirement sets (modules or functional clusters) that are easier to manage.
Importance
Simplifies specification and reduces redundancy.
Procedures
Organize into clusters; remove overlapping requirements; example clustering for hotel system (Customer Registration, Check In, Room Reservation, Check Out, Print Report).
Advantages & Disadvantages
Advantage: Easier to plan and assign work.
Disadvantage: Not specified in notes.
Impact / Effect
Makes SRS clearer and helps traceability.
Examples
Hotel Management clustering example from notes.
Key Takeaways
Cluster related requirements and eliminate overlaps to produce coherent requirement groups.
Requirement Prioritization & Negotiation
Definition
Process of ranking requirements by importance and resolving conflicts.
Causes
Limited resources/time and conflicting stakeholder desires.
Goals / Objectives
Decide which requirements must be implemented first and negotiate trade-offs.
Importance
Ensures the most critical functionality is delivered under constraints.
Procedures
Prioritize requirements; negotiate to resolve conflicts between stakeholders.
Advantages & Disadvantages
Not specified in notes
Impact / Effect
Enables a realistic scope and prevents deadlock over conflicting needs.
Examples
Notes list prioritization and negotiation as distinct activities.
Key Takeaways
Prioritize and negotiate so scarce resources target the most valuable requirements.
Requirement Documentation
Definition
Recording requirements in complete, consistent form aligned with stakeholder needs.
Causes
Need for a referenceable, testable source of system requirements.
Goals / Objectives
Produce documentation that is complete, consistent and conforms to stakeholder requirements.
Importance
Documentation is the basis for specification, design, testing and agreement.
Procedures
Document requirements after discovery, classification and prioritization; ensure completeness and consistency.
Advantages & Disadvantages
Advantage: Clear traceability and reduced ambiguity.
Disadvantage: Not specified in notes.
Impact / Effect
Supports SRS creation and later validation.
Examples
Documentation activity appears as an explicit step in analysis phase.
Key Takeaways
Document requirements fully and consistently; align with stakeholder expectations.
3. Requirements Specification
Definition
See Chapter 4: turning analyzed requirements into a formal Software Requirements Specification (SRS).
Causes
Need for an authoritative, structured document for developers and testers.
Goals / Objectives
Produce system requirement statements (functional and non-functional), models and system architecture descriptions.
Importance
SRS is the contract between developer and customer and the starting point for design.
Procedures
Not detailed here (Chapter 4 covers SRS structure and notation).
Advantages & Disadvantages
Not specified in notes
Impact / Effect
Well-specified requirements lead to better designs and easier testing.
Examples
Reference to Chapter 4 content.
Key Takeaways
Specification formalizes the output of elicitation and analysis; refer to Chapter 4 for structure and notation.
4. Requirements Validation
Definition
Activities that check the requirements for correctness, completeness and realism.
Causes
Requirements may be ambiguous, conflicting or unrealistic after elicitation/specification.
Goals / Objectives
Check validity, consistency, completeness, realism, verifiability and measurability of requirements.
Importance
Detects and resolves requirement issues before design and implementation.
Procedures
Validation checks (from notes):
Validity: functions user wanted are correct and confirmed needed.
Consistency: no conflicts between requirements (example: A: retrieve items in any format; B: no file conversion — possible conflict).
Completeness: all needed requirements present.
Realism check: ensure requirements are achievable.
Verifiable / Measurable: requirements must be testable (demo, measurable criteria).
Methods to validate user requirements (listed in notes): prototyping, structured walkthroughs, formal technical reviews.
Advantages & Disadvantages
Advantage: Early conflict detection (e.g., usability vs cost/schedule) and correction.
Disadvantage: Not specified in notes.
Impact / Effect
Reduces design and implementation rework; clarifies ambiguous requirements.
Examples
Electronic library example: Requirement A (retrieve items in any format) vs Requirement B (no file conversion) creates a conflict identified by an expert system and verified by the team.
Key Takeaways
Validate for validity, consistency, completeness, realism and verifiability.
Use prototyping, walkthroughs and formal reviews to validate requirements.
5. Requirements Management
Definition
Ongoing process of controlling and tracking requirements and their changes.
Causes
Requirements change due to evolving stakeholder needs, environment or discovery.
Goals / Objectives
Validate and meet stakeholder needs; plan and control requirement changes; ensure traceability and alignment with product strategy.
Importance
Keeps the SRS and project aligned with changing needs and prevents uncontrolled scope drift.
Procedures
Management Planning: produce a management plan defining objectives, roles and responsibilities.
Change Management: define methods to describe and implement change, prepare/support employees, establish steps for change, and monitor pre/post-change activities. Effective communication is critical for successful change management.
Advantages & Disadvantages
Advantage: Structured change handling reduces chaos and misalignment.
Disadvantage: Not specified in notes.
Impact / Effect
Proper requirements management preserves project coherence and stakeholder satisfaction.
Examples
Notes stress that the management plan is a shared resource and that communication matters in change management.
Key Takeaways
Plan how requirements will be managed and how changes are controlled.
Use a management plan plus change-management processes and strong communication.
Problems in Requirements Analysis Phase (summary)
Definition
Typical difficulties encountered during elicitation and analysis.
Causes
Stakeholders unclear about needs; use of different terminology; political/economic changes; many viewpoints; natural-language ambiguity.
Goals / Objectives
Identify and mitigate typical analysis problems.
Importance
Awareness helps analysts choose techniques and notations to reduce ambiguity and conflict.
Procedures
Use viewpoint analysis, structured elicitation techniques, classification and validation to address these problems.
Advantages & Disadvantages
Not specified in notes
Impact / Effect
If not handled, problems lead to inconsistent, incomplete or conflicting requirements and project risk.
Examples
Notes list difficulties: stakeholders not clear, stakeholders use their own terms, different expression styles, political factors, ambiguity in natural language.
Key Takeaways
Requirements analysis is hard because stakeholders differ and language is ambiguous; use structured methods to reduce risk.
Viewpoint Hierarchies and Why They Matter
Definition
Organizing viewpoints into hierarchical branches to manage large numbers of stakeholder perspectives.
Causes
Large systems have many viewpoints; eliciting each is impractical.
Goals / Objectives
Group similar viewpoints, ensure coverage and validate viewpoint relevance.
Importance
Hierarchies reduce elicitation effort and help ensure completeness and validity.
Procedures
Build hierarchy that groups Interactor, Indirect and Domain viewpoints; use hierarchy to decide which sub-viewpoints share requirements and which must be individually elicited.