📋 Chapter 2: Requirements Inception

SE311 - Software Requirements Engineering

🎯 What is Requirements Inception?

Core Definition

Requirements Inception is the initial phase of requirements engineering where the goal is to establish a shared understanding of the product's context, defining its underlying problem, proposed solution, boundaries, and benefits.

The idea is to do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system, and decide if it is worthwhile to invest in deeper exploration.
- Craig Larman
Requirements Inception = Vision + Scope + Business Case

Why Requirements Inception?

A project without a clearly defined and well-communicated direction invites disaster!

Without proper inception, you'll face:

  • Work based on unaligned objectives
  • Stakeholders disagreeing on requirements
  • Missed deadlines and budget overruns
  • Incomplete or incorrect system development

📄 Vision and Scope Document

The result of requirements inception is documented in a Vision and Scope Document, which contains three main sections:

1. Business Requirements

Business Requirements describe the primary benefits that the new system will provide to its sponsors, buyers, and users. They directly influence which user requirements to implement and in what sequence.

1.1 Business Opportunity

Describes the situation driving the need for the project:

  • Corporate: Business problem & environment
  • Commercial: Business opportunity & market

📝 Example - E-commerce Platform

Corporate: Current manual order processing causes delays and errors, reducing customer satisfaction.

Commercial: Online retail market growing at 25% annually; competitors offer 24/7 shopping experience.

1.2 Business Objectives

Business benefits stated in a quantitative and measurable way (financial or non-financial).

Problems describe what is keeping the business from meeting their goals at present. Objectives define ways to measure achievements of these goals. They are intertwined - understanding one can reveal the other.

📝 Example - Business Objectives

Problem: Current system processes only 100 orders/day, limiting growth.

Objective: Process minimum 500 orders/day within 6 months of launch.

Objective: Reduce order processing errors from 5% to less than 0.5%.

Objective: Increase customer satisfaction score from 3.2 to 4.5 out of 5.

1.3 Success Metrics

Indicators used to define and measure success both within and outside the organization. They indicate whether a project is on track to meet its business objectives.

📝 Example - Success Metrics

  • System uptime of 99.9%
  • Average page load time under 2 seconds
  • 50% reduction in customer service calls related to orders
  • ROI of 150% within first year

1.4 Vision Statement

Summarizes the long-term purpose of the project. It should be:

  • Balanced to satisfy diverse stakeholders
  • Idealistic but still grounded in reality
  • Clear and inspiring

📝 Example - Vision Statement Template

For [target customer]
Who [statement of need/opportunity]
The [product name]
Is [product category]
That [key benefit, compelling reason to buy/use]
Unlike [primary competitive alternative],
Our product [statement of primary differentiation]

📝 Real Example - Vision Statement

For small to medium online retailers
Who need to automate their order fulfillment process
The SmartFulfill System
Is an integrated e-commerce platform
That reduces processing time by 80% and errors by 95%
Unlike manual systems or basic shopping carts,
Our product provides AI-powered inventory management and predictive analytics

1.5 Business Risks

Potential factors that could threaten project success.

1.6 Business Assumptions and Dependencies

Factors assumed to be true and external dependencies the project relies on.

Sources for Business Requirements: Funding sponsors, marketing managers, corporate executives, and product visionaries.

2. Scope and Limitations

Defines both what the solution will do and what it will NOT do. This helps manage stakeholder expectations.

Product Vision vs. Project Scope

Product Vision Project Scope
Succinctly describes the ultimate product that will achieve business objectives Identifies what portion of the ultimate product the current project will address
Applies to the product as a whole Pertains to a specific project or iteration
Relatively static More dynamic
Long-term vision Short-term deliverables
The product vision encompasses the scope for each planned release. Scope for the current release should be clear, but the scope of future releases will be fuzzier the farther out you look.

Levels of Scope Definition

  • Highest Level: Scope defined in terms of which business objectives to target
  • Lower Level: Scope defined in terms of features, use cases, or events/responses to include
  • Lowest Level: Scope defined in terms of functional requirements planned for a specific release
In-scope user requirements must map to business objectives, and functional requirements must map to in-scope user requirements. This creates traceability!

2.1 Major Features

List the major features without including unnecessary details.

2.2 Scope of Initial Release

Features planned for the first release. Focus on:

  • Most value to stakeholders
  • Acceptable cost
  • Large community impact
  • Earliest time frame feasibility

2.3 Scope of Subsequent Releases

Build a release roadmap for future versions.

2.4 Limitations and Exclusions

Features that stakeholders might expect but are not planned for inclusion:

  • Items that were cut from scope
  • Functionality deferred to future releases
  • Out-of-scope items that need explicit clarification
New requirements during development must be evaluated according to the defined scope. In-scope requirements can be incorporated if high priority, but usually require deferring other requirements or negotiating a new schedule.

3. Business Context

3.1 Stakeholder Profiles

Each profile should include:

  • Major value the stakeholder expects
  • Expected attitude toward the product
  • Restrictions that must be built in

📝 Example - Stakeholder Profile

End Users (Customers):

  • Value: Fast, easy online shopping experience
  • Attitude: Enthusiastic about convenience, concerned about security
  • Restrictions: Must support mobile devices, accessibility requirements

3.2 Project Priorities

Stakeholders must agree on project priorities. When changing a feature, check its priority.

3.3 Deployment Considerations

Summarizes required information when publishing the system.

🎨 Scope Representation Techniques

The purpose is to foster clear and accurate communication of scope among stakeholders. It's important to follow a notation standard to achieve this goal.

1. Context Diagrams

Visually illustrates the boundary between the system being developed and everything else in the universe.

  • Provides no visibility into the system's internal objects, processes, or data
  • Identifies external entities (terminators) that connect to the system
  • Shows data, control, and material flows

External entities can be:

  • User classes
  • Organizations
  • Other systems
  • Hardware devices

📝 Example - Context Diagram Elements

For a Chemical Tracking System:

  • External Entities: Chemist, Buyer, Chemical Stockroom, Health and Safety Department, Bar Code Reader, Training Database
  • Data Flows: vendor catalog query, chemical container requests, inventory reports, training records

2. Ecosystem Maps

Shows all systems related to the system being developed and the interactions among them. Identify systems by determining which ones consume data from your system or vice versa.

Context Diagram Ecosystem Map
All types of external entities that directly interface with the system Systems that relate to the system whether directly or indirectly
Shows immediate connections only Shows broader system relationships

📝 Example - Ecosystem Map

For Chemical Tracking System:

  • Vendor → sends chemical containers → Receiving System
  • Receiving System → sends chemical containers → Chemical Tracking System
  • Purchasing System → sends requests → Chemical Tracking System
  • Personnel System → Training records → Corporate Training Database
  • Health and Safety Database → compliance reports → OSHA/EPA Reporting Interface

3. Feature Trees

Visual depiction of the product's features organized in logical groups, hierarchically subdividing each feature into further levels of detail.

  • Can show up to three levels: L1, L2, and L3
  • Scope of a specific release = defined set of features chosen from the tree

📝 Example - Feature Tree Structure

L1: User Management

  • L2: Registration
    • L3: Email verification
    • L3: Social media login
  • L2: Profile Management
    • L3: Update personal info
    • L3: Change password
Feature trees are excellent for planning releases. You can easily select which L1, L2, or L3 features go into each release version.

4. Event Lists

Identifies external events that could trigger behavior in the system. Events could be:

  • User-triggered: User clicks button, enters data
  • Time-triggered: Monthly report generation, automatic backup
  • Signal events: Received from external components

The functional requirements that describe how the system responds to events would be detailed in the SRS (Software Requirements Specification). The scope of a release is defined in terms of certain events.

📝 Example - Event List

Event Type Event System Response
User-triggered User submits order Validate, process payment, send confirmation
Time-triggered End of business day Generate daily sales report
Signal Low inventory alert from warehouse system Notify purchasing manager, auto-reorder if configured

👥 Identifying Stakeholders

Stakeholder identification is critical for successful requirements inception. Ask these questions:

  • Who uses the system?
  • Who is the customer?
  • Who is affected by outputs?
  • Who evaluates/approves the system?
  • Other external/internal users?
  • Who maintains the system?
  • Anyone who cares? (legal, regulatory, etc.)

📝 Exam Question Example - Riyadh Season Scenario

Scenario: Riyadh Season event modernizes ticket selling. Traditional agencies + new online system. Secure Payment Inc. for online payments. Self-check-in terminals issue electronic bracelets for cashless purchases.

Q: List all possible stakeholders

Answer:

  • Event organizers
  • Event agencies (traditional sellers)
  • Customers/attendees
  • Secure Payment Inc.
  • Website developers/IT team
  • Terminal operators
  • Vendors (snacks, beverages)
  • Security personnel
  • Government regulators

⚡ Identifying Constraints

Constraints are restrictions on the solution space that put limitations on the ability to deliver a solution as envisioned. They are usually non-functional requirements that impose major restrictions on the system.

Sources of Constraints:

  • Economics: Costs, licensing issues, budget limits
  • Politics: Internal/external, interdepartmental issues
  • Technology: Choice of technology/platform, legacy systems
  • Systems: Existing system compatibility issues
  • Environment: Legal, environmental, security, standards compliance
  • Schedule and Resources: Fixed deadlines, team availability

📝 Example - Constraints

  • Economic: Project budget cannot exceed $500,000
  • Technology: Must integrate with existing Oracle database
  • Schedule: Must launch before holiday season (deadline: Oct 1)
  • Legal: Must comply with GDPR for EU customers

💎 Tips & Tricks for Requirements Inception

Tip #1: Always start with "Why?" before "What?" - Understand the business problem before jumping to solutions.
Tip #2: Make business objectives SMART: Specific, Measurable, Achievable, Relevant, Time-bound.
Tip #3: Use visual representations (context diagrams, ecosystem maps) early and often - they catch misunderstandings faster than text.
Tip #4: Define what's OUT of scope as clearly as what's IN scope - this manages expectations and prevents scope creep.
Tip #5: Get stakeholder sign-off on the Vision and Scope document before detailed requirements work - it's your contract and reference point.
Tip #6: Problems and objectives are intertwined - if you're stuck on one, work on the other to gain clarity.
Tip #7: For feature trees, start broad (L1) and only go deeper (L2, L3) for features in the current release.
Tip #8: Remember: Context diagrams show direct interfaces only; ecosystem maps show the bigger picture including indirect relationships.

⚠️ Common Pitfalls to Avoid

Pitfall #1: Skipping inception because "everyone knows what we need" - This leads to misaligned expectations and rework.
Pitfall #2: Making the vision statement too vague or too detailed - Find the sweet spot: inspiring but grounded in reality.
Pitfall #3: Not distinguishing between product vision and project scope - Vision is long-term and stable; scope is specific to a release.
Pitfall #4: Forgetting to identify stakeholders systematically - Use the checklist questions to ensure no one is missed.
Pitfall #5: Treating all requirements as equally important - Prioritization is critical for managing scope and releases.

📝 Exam Practice Questions

Question 1: Vision Statement (From Exams)

Q: Create a vision statement for a university library management system that helps students find and borrow books online.

Answer:

For university students and faculty
Who need quick access to library resources without visiting physically
The Digital Library Portal
Is an online library management system
That enables 24/7 book search, reservation, and digital borrowing
Unlike traditional library visits requiring physical presence,
Our product provides instant access to the catalog and extends borrowing periods automatically based on availability

Question 2: Requirements Engineering Process (From Major Exam)

Q: Based on your understanding of the requirement engineering process, fill in the following activities in correct sequence:

  1. Inception
  2. Requirements elicitation
  3. Requirements analysis and negotiation
  4. Requirements specification
  5. Requirements validation
  6. Requirements management

Explanation:

  • Inception: Start the process (business need, feasibility study, scope)
  • Elicitation: Discover requirements through consultation
  • Analysis: Analyze and resolve conflicts through negotiation
  • Specification: Produce precise requirements document
  • Validation: Check for consistency and completeness
  • Management: Handle evolving needs and contexts (ongoing)

Question 3: Scope Representation

Q: What is the difference between a Context Diagram and an Ecosystem Map?

Answer:

  • Context Diagram: Shows all types of external entities that directly interface with the system. It illustrates the immediate boundary of the system and what directly connects to it.
  • Ecosystem Map: Shows systems that relate to the system whether directly or indirectly. It provides a broader view of all related systems and their interactions, even if they don't directly connect to your system.

Question 4: Business Objectives (Application)

Q: For the Riyadh Season ticketing system, write two business objectives with success metrics.

Answer:

  • Objective 1: Increase ticket sales by 40% within the first season by offering online purchasing options.
    • Success Metric: Track total tickets sold online vs. traditional channels; target 40% more total sales compared to previous year.
  • Objective 2: Reduce customer wait time at event entrances by 60% through self-check-in terminals.
    • Success Metric: Measure average time from arrival to entry; target reduction from 15 minutes to 6 minutes or less.

Question 5: Functional vs Non-Functional Requirements

Q: For the Riyadh Season scenario, list two functional and two non-functional requirements.

Answer:

Functional Requirements:

  • The system shall allow customers to purchase tickets online using credit cards or digital wallets.
  • The system shall issue electronic bracelets at self-check-in terminals that can be loaded with money for purchases.

Non-Functional Requirements:

  • The online payment system shall process transactions securely using PCI DSS compliance standards.
  • The self-check-in terminals shall complete the check-in process within 30 seconds per customer.

Question 6: Requirements Inception Summary

Q: Summarize requirements inception in one sentence.

Answer:

Agree on a well-defined project's vision, scope, and business case.

⚡ Quick Reference Guide

Vision and Scope Document Structure:

  1. Business Requirements
    • Background
    • Business Opportunity (Corporate & Commercial)
    • Business Objectives (Problems vs Objectives)
    • Success Metrics
    • Vision Statement
    • Business Risks
    • Business Assumptions and Dependencies
  2. Scope and Limitations
    • Major Features
    • Scope of Initial Release
    • Scope of Subsequent Releases
    • Limitations and Exclusions
  3. Business Context
    • Stakeholder Profiles
    • Project Priorities
    • Deployment Considerations

Four Scope Representation Techniques:

  1. Context Diagrams: Direct interfaces only, external entities
  2. Ecosystem Maps: All related systems, direct or indirect
  3. Feature Trees: Hierarchical features (L1, L2, L3)
  4. Event Lists: External events triggering system behavior

Key Formulas to Remember:

Product Vision ≠ Project Scope
Vision (static, long-term) → Scope (dynamic, per release)
Problems ↔ Objectives (intertwined)