Chapter 5: Requirements Engineering Process
🎯 Learning Objectives
By the end of this study session, you’ll be able to:
- Define requirements engineering and explain its critical role in software development
- Execute all five requirements engineering activities systematically
- Navigate the challenges of requirements analysis using proven techniques
- Apply viewpoint-oriented analysis to discover comprehensive requirements
- Validate requirements effectively using multiple verification methods
- Implement requirements management strategies for changing project needs
🌟 The Big Picture
Requirements engineering is your project’s foundation - it’s the systematic process of figuring out exactly what your software needs to do before you build it. Think of it as being a detective, translator, and diplomat all at once: you’ll discover what stakeholders really need, translate their wishes into clear technical specifications, and negotiate between conflicting demands to create a system that actually works.
đź“š Core Concepts
What is Requirements Engineering?
Requirements engineering encompasses all activities needed to create and maintain a system requirements document. You’re essentially bridging the gap between what people want and what developers can build.
The Complete Process includes:
- Feasibility Studies - Can we actually build this?
- Requirement Elicitation and Analysis - What do people really need?
- Requirement Specification - How do we document it clearly?
- Requirement Validation - Did we get it right?
- Requirement Management - How do we handle changes?
1. Feasibility Studies - The Reality Check
Before diving into development, you need to determine if the project is actually doable. Think of this as your project’s health checkup.
The Three Critical Feasibility Types:
Legal Feasibility:
- Ensures your product complies with all regulations and laws
- Example: Medical software handling protected health information must meet HIPAA requirements
- Identifies legal risks and their potential project impact
Operational Feasibility:
- Examines how the new system will impact daily company operations
- Determines what procedures need implementation
- Assesses maintenance efforts required
Schedule Feasibility:
- Analyzes timelines and deadlines for the proposed project
- Determines realistic completion timeframes
- Critical because projects that miss deadlines often fail to serve their intended purpose
2. Requirements Analysis & Elicitation - The Detective Work
This is where things get interesting (and challenging). You’re extracting requirements from stakeholders who often don’t know exactly what they want.
Why This Process is Genuinely Difficult
Stakeholder Challenges:
- Unclear expectations - People know they have a problem but can’t articulate the solution
- Different vocabularies - Technical teams and business users speak different languages
- Varied expression styles - Everyone communicates requirements differently
- Political factors - Office politics can influence what people say they need
- Environmental changes - Economic and business shifts alter requirements mid-project
The Four Core Activities
2.1 Requirements Discovery - Finding What You Need
You’ll gather information from three main sources:
- Stakeholders - The people who will use or be affected by the system
- Documentation - Existing system specs, business processes, regulations
- Similar Systems - Specifications from comparable projects
Viewpoint-Oriented Analysis - Your Strategic Framework
This approach systematically identifies all the different perspectives on your system. Think of it as creating a comprehensive guest list for your requirements gathering party.
The Three Essential Viewpoint Types:
Interactor Viewpoints:
- People who directly interact with the system
- Focus on system features and user interfaces
- Example (ATM): Bank customers, bank staff, database systems
Indirect Viewpoints:
- People who don’t use the system directly but influence its requirements
- Contribute high-level requirements and constraints
- Example (ATM): Bank managers, security staff, marketing department
Domain Viewpoints:
- Standards and regulations that constrain the system
- Industry-specific requirements that aren’t negotiable
- Example (ATM): Standards for interbank communications, security protocols
Practical Example - College Library System
Interactor Viewpoints: Students, Lecturers, Tutors, System Engineers, Librarians
Indirect Viewpoints: Library Manager, Finance Department, Book Suppliers
Domain Viewpoints: UI Standards, Classification Standards (Dewey Decimal, etc.)
Visual Reference - Library System Hierarchy:
All Viewpoints
├── Interactor VPs
│ ├── Students
│ ├── Lecturers
│ ├── Library Staff
│ └── System Engineers
├── Indirect VPs
│ ├── Library Manager
│ ├── Finance Department
│ └── Suppliers
└── Domain VPs
├── UI Standards
└── Classification Standards
Why Create Viewpoint Hierarchies?
Creating structured viewpoint hierarchies serves three critical purposes:
- Efficiency Management - Large systems have numerous viewpoints. Hierarchies help identify which viewpoints share common requirements, so you don’t need to interview everyone separately
- Complete Coverage - Ensures you don’t miss any important perspectives during analysis
- Validation Tool - Helps determine whether a potential viewpoint is actually relevant to your project
2.2 Requirements Discovery Techniques
Interview: Direct conversations with stakeholders - your primary tool Prototyping: Build quick versions to clarify unclear requirements Scenarios: Walk through real-world use cases Observation: Watch people work to discover implicit requirements Real-life Examples: Study how similar systems actually get used
2.3 Requirements Classification & Organization
Once you’ve gathered requirements, you need to organize them logically:
- Create requirement clusters around related functionality
- Remove overlapping requirements that say the same thing differently
- Group by system areas (e.g., Check In, Room Reservation, Check Out for a Hotel Management System)
2.4 Requirements Prioritization & Negotiation
Reality check time - you can’t build everything at once:
- Prioritize requirements based on business value and technical feasibility
- Resolve conflicts between different stakeholder needs
- Negotiate compromises when requirements contradict each other
2.5 Requirements Documentation
Create documentation that is:
- Complete - Nothing important is missing
- Consistent - No contradictions between requirements
- Aligned - Matches what stakeholders actually need
3. Requirements Specification
(This topic is covered in detail in Chapter 4 of your course materials)
The specification phase transforms your analyzed requirements into formal documentation that developers can use to build the system.
4. Requirements Validation - Getting It Right
Before anyone starts coding, you need to verify that your requirements are actually correct and buildable. Think of this as quality assurance for your requirements.
Five Critical Validation Aspects:
Validity:
- Verify the functions users wanted are correct and actually needed
- Confirm stakeholders really need what’s documented
Consistency:
- Check for conflicts between requirements
- Real Example: Electronic Library System conflict:
- Requirement A: “Allow user to retrieve items in any format”
- Requirement B: “No file conversion should be supported”
- The Conflict: You can’t retrieve in “any format” without file conversion
Completeness:
- Ensure all necessary requirements are captured
- Verify nothing critical is missing
Realism Check:
- Assess whether requirements are technically and economically feasible
- Confirm the system can actually be built with available resources
Verifiability:
- Requirements must be measurable and demonstrable
- You need to be able to prove the final system meets each requirement
Validation Methods You Can Use:
- Prototyping - Build working models to test requirement accuracy
- Structured Walkthrough - Systematically review requirements with stakeholders
- Formal Technical Reviews - Have technical experts evaluate requirement feasibility
5. Requirements Management - Handling Change
Requirements management deals with the reality that requirements will change throughout your project. It’s not about preventing change - it’s about managing it effectively.
The Two Core Components:
5.1 Management Planning
Create a comprehensive plan that provides:
- Clear project objectives that everyone understands
- Defined roles and responsibilities so nothing falls through cracks
- Guidance resource that the entire team can reference
Think of your management plan as your project’s rulebook that keeps everyone aligned.
5.2 Change Management
This covers methods and processes for describing and implementing change in both internal and external processes.
Key Success Factors:
- Prepare and support employees for upcoming changes
- Establish clear steps for implementing changes
- Monitor pre- and post-change activities to ensure successful implementation
- Maintain effective communication - this is absolutely critical for change management success
The Change Management Reality: Effective communication isn’t just helpful - it’s the single most important factor that determines whether your change management succeeds or fails.
🔄 Putting It All Together
Requirements engineering isn’t a linear process - you’ll cycle through these activities multiple times as you refine your understanding. Start with feasibility studies to ensure your project is realistic, then dive deep into elicitation and analysis to discover what stakeholders really need. Use viewpoint-oriented analysis to make sure you haven’t missed anyone important, then validate everything before moving forward. Throughout the entire process, manage changes systematically so your project stays on track even as requirements evolve.
Remember: Good requirements engineering prevents most of the expensive problems that occur later in development. The time you invest here pays dividends throughout the entire project lifecycle.