Part 2: Requirements & Feasibility

1. The Hierarchy of Requirement Documentation

In enterprise software engineering, requirements evolve from high-level business goals into hyper-specific technical instructions. Understanding the difference between these documents is a common interview benchmark.

 [ Business Requirement Document (BRD) ]  ───> Why & What (High-Level)
                  │
                  ▼
 [ Functional Requirement Specification (FRS) ] ───> How it behaves (User View)
                  │
                  ▼
 [ Software Requirement Specification (SRS) ]  ───> Technical Blueprint (System View)

• Business Requirement Document (BRD):

• Focus: Why are we building this, and what is the business value?

• Content: High-level business goals, project scope, financial benefits, core stakeholder needs, and market constraints.

• Audience: Executives, clients, sponsors, and product managers. Written in non-technical business language.

• Functional Requirement Specification (FRS):

• Focus: What does the software actually do to meet the BRD’s goals?

• Content: Detailed descriptions of system behavior, user interactions, input/output structures, screens, and workflows.

• Audience: Product managers, business analysts, development leads, and quality assurance teams.

• Software Requirement Specification (SRS):

• Focus: The complete engineering blueprint. How does the system achieve the functional demands?

• Content: Combines both Functional and Non-Functional requirements. Includes system architecture constraints, hardware dependencies, database schemas, performance metrics, security protocols, and third-party API configurations.

• Audience: Developers, architects, and technical QA engineers.

Requirement vs. Specification

An interview trap is confusing these two terms:

• A Requirement is a capability needed by a user to solve a problem (e.g., “The system must allow users to pay for items securely using credit cards.”).
• A Specification is the concrete technical translation of that need (e.g., “The checkout page shall transmit a tokenized payload via TLS 1.3 to the Stripe v3 payment API endpoint, returning an HTTP 200 status code upon successful authorization within 1.5 seconds.”).

---

2. Functional vs. Non-Functional Requirements (NFRs)

Interviews frequently test your ability to separate user actions from systemic constraints.

Attribute	Functional Requirements (FRs)	Non-Functional Requirements (NFRs)
Definition	What the system must do. The core features and operations.	How the system must perform while doing its core functions.
Focus	User actions, inputs, data processing, and workflow steps.	System behavior, performance, constraints, and quality attributes.
Examples	A user can add products to a shopping cart.The system generates a monthly PDF sales report.Admins can suspend user accounts.	The payment page must load in less than 2 seconds (Performance).The system must maintain 99.99% uptime (Availability).All user passwords must be hashed using bcrypt (Security).
Failure Mode	The feature is missing or broken.	The system works, but it is slow, vulnerable, or scales poorly.

---

3. Modeling Requirements: User Stories vs. Use Cases

Modern Agile teams and traditional software teams model user interactions differently.

Use Cases (Traditional/Structured)

A detailed, text-based document outlining a sequence of interactions between an external Actor (user or external system) and the software system to achieve a specific goal.

• Key Elements: Primary Actor, Pre-conditions, Post-conditions, Happy Path (the standard successful flow), and Alternative/Exception Paths (error flows, cancellations).
• Best For: Detailing complex workflows and complex technical error-handling processes.

User Stories (Agile Frameworks)

A lightweight, high-level description of a feature, written from the perspective of the end user. It captures the essence of a requirement without exhaustive technical detail.

• Standard Formula: As a [Type of User], I want to [Perform an Action], so that [Business Value/Benefit].
• The INVEST Criteria: High-quality User Stories must be Independent, Negotiable, Valuable, Estimable, Small, and Testable.
• Acceptance Criteria: The specific, verifiable conditions that a user story must satisfy to be accepted as complete by the Product Owner. Frequently written in the Behavior-Driven Development (BDD) format: Given [Context] -> When [Action] -> Then [Outcome].

---

4. Feasibility Studies & Requirements Engineering Tools

Before a single line of code is approved, teams conduct Feasibility Studies across multiple lenses:

• Technical Feasibility: Do we have the technology, expertise, infrastructure, and hardware to build this system?
• Economic Feasibility: Cost-benefit analysis. Will the return on investment (ROI) justify the development expenses?
• Operational Feasibility: Will the organization be able to effectively operate, support, and adopt this software once it is delivered?
• Legal & Compliance Feasibility: Does the software violate any copyright laws, data privacy acts (e.g., GDPR, CCPA), or industry regulations (e.g., HIPAA, PCI-DSS)?
• Schedule Feasibility: Can the product be delivered within the designated timeline?

Requirements Traceability Matrix (RTM)

A grid document that tracks every single requirement from its origin (the BRD/client request) all the way down through design elements, code modules, and final test cases.

[Business Requirement ID] ➔ [Functional Specs ID] ➔ [Design Component] ➔ [Code Module] ➔ [Test Case ID]

Why RTM is Mandatory: It guarantees forward traceability (ensures every single requirement is built and tested, preventing forgotten features) and backward traceability (ensures no random code or features are added that weren’t explicitly requested, preventing gold-plating).

---

5. Scope Creep & Change Request Management

Scope Creep

The uncontrolled, gradual growth of a project’s scope without adjustments to time, cost, or resources. It typically occurs due to vague initial requirements, poor stakeholder management, or undocumented verbal agreements with the client.

Change Request Management (CRM) Process

When a client requests a change mid-project in a structured or traditional environment, you must execute a strict, formal process rather than immediately coding the change:

[ Receive Change Request ]
           │
           ▼
[ Impact Analysis ] ───> Evaluate effect on Cost, Schedule, Scope, Risk, Quality
           │
           ▼
[ Present Options to Change Advisory Board (CAB) ]
           │
           ▼
┌──────────────────┴──────────────────┐
▼                                     ▼
[ Approved ]                          [ Rejected ]
│                                     │
├─> Update Project Baseline           └─> Log decision & inform client
├─> Adjust Schedule & Budget
└─> Execute Development

Technical Interview Strategy: Handling Unclear Requirements

If asked: “What would you do if given incomplete or ambiguous requirements?”

• Step 1: Do not assume or guess what the client wants.
• Step 2: Organize a structured clarification workshop or a JAD (Joint Application Development) session with business analysts, clients, and technical leads.
• Step 3: Use visual prototypes or wireframes to give the client a tangible look at what you interpret their requirements to mean.
• Step 4: Document every clarification and obtain explicit formal sign-off before allocating development resources.

---

6. Requirements Elicitation Techniques

How do you actually gather requirements from stakeholders? A placement staple:

• Interviews — one-on-one with stakeholders; good for deep, specific detail.
• Questionnaires/Surveys — reach many users cheaply; limited depth.
• Observation — watch users work; reveals implicit needs they don’t articulate.
• JAD (Joint Application Development) Workshops — facilitated group sessions where users + devs agree on requirements together; fast consensus.
• Brainstorming — free-form idea generation.
• Prototyping — a working model to elicit feedback (great when users can’t visualize requirements).
• Document analysis — mine existing systems/specs for requirements.

Good requirement characteristics (the checklist): Unambiguous, Measurable, Attainable, Relevant, Traceable, Complete, Consistent, Testable (UMARTCCT / just remember: clear, specific, verifiable, traceable).

7. Feasibility Study (TELOS)

Before building, assess whether the project is worth it and possible:

• Technical — can we build it with available tech/skills?

• Economic — does the cost justify the benefit (cost-benefit)?

• Legal — does it comply with laws/regulations?

• Operational — will it actually work in the org’s environment and be used?

• Schedule — can we deliver in the required time?

• Requirements Traceability Matrix (RTM): maps each requirement → design → test case → result, giving forward traceability (all requirements are covered) and backward traceability (every artifact traces to a requirement). Vital for compliance and change control.