Feasibility and Testability of Requirements

Feasibility and Testability of Requirements: A Complete Guide for CBAP Exam

Introduction to Feasibility and Testability Requirements

Feasibility and testability are two critical dimensions of requirement quality that business analysts must evaluate during the requirements analysis and design definition phase. These concepts ensure that requirements are not only desirable but also achievable and verifiable within project constraints.

Why Feasibility and Testability Are Important

Feasibility is crucial because it determines whether a requirement can realistically be implemented given:

• Available technology and tools
• Budget and financial resources
• Time constraints and project schedules
• Skill sets and team expertise
• Organizational policies and standards
• Legal and compliance requirements

Testability is important because it ensures that:

• Requirements can be objectively verified and validated
• Quality assurance teams can create meaningful test cases
• Acceptance criteria are clear and measurable
• Scope creep is prevented through clear boundaries
• Defects can be definitively identified
• Project completion can be objectively determined

Together, these concepts prevent costly rework, scope disputes, and project failures by ensuring requirements are grounded in reality and can be proven to be met.

What Are Feasibility and Testability Requirements?

Feasibility of Requirements

Feasibility refers to the practicality and possibility of implementing a requirement within the constraints of a project. A feasible requirement is one that:

• Can be developed with available or obtainable technology
• Fits within project budget limitations
• Can be completed within the project timeline
• Aligns with organizational capabilities and culture
• Complies with legal, regulatory, and security requirements
• Does not conflict with existing systems or infrastructure

Types of Feasibility to Evaluate:

• Technical Feasibility: Can the technology support the requirement? Is integration possible? Are there known solutions or proof of concepts?
• Financial Feasibility: Does the requirement fit within budget? What is the return on investment?
• Operational Feasibility: Can current or planned operations support this requirement? Do we have skilled personnel?
• Schedule Feasibility: Can the requirement be completed within the project timeline?
• Legal/Compliance Feasibility: Does the requirement meet regulatory requirements and organizational standards?

Testability of Requirements

Testability refers to the degree to which a requirement is stated in a way that makes it possible to verify whether the solution actually meets that requirement. A testable requirement must be:

• Measurable: Specific metrics or criteria define success (e.g., "response time under 2 seconds" not "fast response time")
• Verifiable: Can be evaluated through inspection, analysis, testing, or demonstration
• Clear and Unambiguous: Written so all stakeholders understand the same thing
• Objective: Not dependent on personal opinion or subjective judgment
• Complete: Contains all necessary information to determine success

Characteristics of Testable Requirements:

• Written in mandatory language ("shall," "must," "will") rather than suggestive ("should," "may," "nice to have")
• Include specific acceptance criteria
• Define measurable thresholds and tolerances
• Specify conditions under which the requirement applies
• Include clear success and failure conditions

How Feasibility and Testability Work Together

The Relationship

Feasibility and testability work in tandem within the requirements analysis process:

1. Requirements are gathered from stakeholders and documented
2. Feasibility analysis determines if requirements can be delivered
3. Testability review ensures requirements can be verified
4. Requirements are refined based on feasibility and testability findings
5. Approval is obtained when both criteria are satisfied
6. Implementation and testing proceeds with clear success criteria

Common Feasibility and Testability Issues

Feasibility Issues:

• Requirements exceed budget constraints
• Technology to implement the requirement doesn't exist or is too immature
• Timeline is unrealistic given the scope
• Required expertise is unavailable in the organization
• Requirements conflict with existing systems or infrastructure
• Organizational culture or change management capacity cannot support implementation

Testability Issues:

• Vague language ("easy to use," "user-friendly," "fast")
• Subjective criteria without clear metrics ("good quality," "best practices")
• No acceptance criteria defined
• Requirements phrased as solutions rather than needs
• Missing conditional statements or edge cases
• Impossible to measure or verify the requirement

How to Evaluate Feasibility and Testability

Step-by-Step Feasibility Analysis Process

1. Identify all constraints: Budget, schedule, technology, skills, regulatory requirements
2. Research available solutions: Can existing products, tools, or frameworks be used?
3. Assess organizational readiness: Do we have the people, processes, and infrastructure?
4. Conduct proof of concepts: For high-risk or new technology requirements
5. Perform risk analysis: What could prevent implementation?
6. Document findings: Record which requirements are feasible and which need modification
7. Engage stakeholders: Discuss trade-offs and prioritize based on constraints

Step-by-Step Testability Analysis Process

1. Review requirement wording: Replace vague terms with specific, measurable ones
2. Define acceptance criteria: What does "done" look like? What are the success metrics?
3. Identify test conditions: What scenarios, inputs, and situations should be tested?
4. Specify test data: What data is needed to verify the requirement?
5. Determine verification method: Will this be tested, inspected, analyzed, or demonstrated?
6. Review with QA: Can the QA team create meaningful tests from this requirement?
7. Document rationale: Why are these acceptance criteria appropriate?

Examples of Feasibility and Testability

Example 1: Not Feasible

Requirement: "The system shall process 1 million transactions per second with 99.99% uptime on a budget of $50,000."

Why it's not feasible: The infrastructure, development, and testing required to achieve this performance at this scale would cost far more than $50,000. The technology exists but not at this price point.

How to fix it: Revise to either increase budget, reduce performance requirements, or reduce uptime percentage to align with financial constraints.

Example 2: Not Testable

Requirement: "The system shall provide excellent user experience."

Why it's not testable: "Excellent" is subjective and unmeasurable. Different people have different standards for what constitutes a good experience.

How to fix it: Revise to something like: "The system shall allow users to complete the login process in 30 seconds or less with no more than 3 clicks, and 95% of users shall rate their experience as 4 or 5 stars on a 5-star scale."

Example 3: Both Feasible and Testable

Requirement: "The system shall allow users to upload documents up to 50MB in size, and the upload shall complete within 5 minutes on a standard broadband connection (10 Mbps). Upload success shall be confirmed with a confirmation message displayed within 30 seconds of upload completion."

Why it's feasible: Standard server infrastructure can handle this file size. 50MB is achievable with current technology and reasonable development effort.

Why it's testable: Clear metrics (50MB file size, 5-minute completion, 10 Mbps connection), specific acceptance criteria (confirmation message within 30 seconds), and measurable success conditions.

How to Answer Exam Questions on Feasibility and Testability

Question Types You'll Encounter

Type 1: Identifying Non-Feasible Requirements

Example Question: "Which of the following requirements has a feasibility problem?"

How to approach: Look for requirements that:

• Require non-existent or immature technology
• Cost more than stated budget allows
• Cannot be completed in the stated timeline
• Require skills or resources the organization doesn't have
• Conflict with organizational policies or existing systems

Type 2: Identifying Non-Testable Requirements

Example Question: "Which requirement is not testable?"

How to approach: Look for requirements with:

• Vague language (easy, fast, user-friendly, good, excellent)
• No measurable acceptance criteria
• Subjective success conditions
• No clear way to verify compliance
• Suggestive language (should, may, nice to have) instead of mandatory (shall, must)

Type 3: Fixing Non-Feasible or Non-Testable Requirements

Example Question: "How would you revise this requirement to make it testable?"

How to approach:

• Add specific metrics and measurements
• Replace vague adjectives with quantifiable terms
• Define clear acceptance criteria
• Specify conditions and thresholds
• Use mandatory language instead of suggestive
• Include measurable success and failure conditions

Type 4: Scenario-Based Questions

Example Question: "You're analyzing a requirement to build a mobile app that works on all devices with no development cost. What feasibility issues do you identify?"

How to approach: Break down into feasibility categories:

• Technical: Supporting all devices requires significant development effort and testing
• Financial: "No development cost" is not feasible; development requires resources and budget
• Operational: Maintenance and support across all devices is resource-intensive
• Schedule: Supporting all devices increases timeline significantly

Exam Tips: Answering Questions on Feasibility and Testability of Requirements

Essential Tips for Success

Tip 1: Know Your Feasibility Categories

Always remember the five main feasibility dimensions: Technical, Financial, Operational, Schedule, and Legal/Compliance. When analyzing a requirement, consider it against all five categories. The CBAP exam often uses questions that require you to identify which feasibility dimension is being discussed.

Tip 2: Recognize Vague Language Red Flags

On the exam, watch for these words that signal non-testable requirements:

• Avoid: "fast," "slow," "easy," "difficult," "user-friendly," "intuitive," "good," "excellent," "reliable," "stable," "modern," "nice to have"
• Prefer: Specific metrics like "within 2 seconds," "under 5MB," "with 99.5% uptime," "completed in 3 clicks or fewer"

If a question asks you to identify non-testable requirements, look for these vague terms immediately.

Tip 3: Look for Conflicting Constraints

The exam often includes questions where requirements have conflicting feasibility constraints. For example:

• High performance + low budget = feasibility conflict
• Complex functionality + short timeline = schedule feasibility issue
• Advanced technology + limited skills = technical and operational feasibility issue

When you see constraints that seem contradictory, flag it as a feasibility problem.

Tip 4: Understand the Relationship Between Feasibility and Testability

Remember that these are complementary but separate concepts:

• A requirement can be feasible but not testable (e.g., "We can build it, but we can't verify if it works")
• A requirement can be testable but not feasible (e.g., "We could verify it works, but we can't build it with our resources")
• Both must be addressed to have a quality requirement

Tip 5: Use the "How Will We Know?" Test

When reviewing testability on the exam, ask yourself: "How will the QA team know if this requirement is met?" If the answer is unclear or subjective, it's not testable. This is a powerful technique for exam questions.

Tip 6: Know When to Revise vs. When to Reject

Some exam questions ask whether to revise or reject a requirement:

• Revise: When the core need is valid but the requirement as written has feasibility or testability issues that can be addressed through rewording or constraint adjustment
• Reject: When the core need itself is not feasible (e.g., "Build perpetual motion device") or when stakeholders fundamentally disagree on what's needed

Tip 7: Remember the Role of Acceptance Criteria

On the exam, understand that acceptance criteria are essential to testability:

• Acceptance criteria define what "done" means
• They provide measurable, observable evidence that the requirement is met
• They should be defined during requirements analysis, not during testing
• They prevent scope creep by clearly bounding the requirement

If a question shows a requirement without clear acceptance criteria, it's likely non-testable.

Tip 8: Consider Organizational Context

Feasibility is not just technical—it's organizational:

• A requirement might be technically feasible but organizationally unfeasible if it conflicts with corporate policies
• A requirement might require skills the organization doesn't have (feasibility issue)
• A requirement might involve new tools or platforms the organization hasn't approved (operational feasibility)

The exam tests your understanding that feasibility includes organizational and operational dimensions, not just technical ones.

Tip 9: Look for Hidden Assumptions

Exam questions often hide feasibility or testability issues in assumptions:

• "Assuming the system is deployed in the cloud..." (technical assumption)
• "If we hire two additional developers..." (resource assumption)
• "Once we upgrade the infrastructure..." (dependency assumption)

Identify these hidden assumptions and question whether they're realistic.

Tip 10: Practice with Real Business Scenarios

The CBAP exam includes scenario-based questions. For practice:

• Take a real-world requirement and analyze it for both feasibility and testability
• Write requirements that are clearly testable with specific metrics
• Identify feasibility constraints in realistic project scenarios
• Practice proposing revisions to non-feasible or non-testable requirements

Tip 11: Use Quantitative Language in Your Answers

On exam questions that ask you to rewrite or fix a requirement:

• Replace all vague adjectives with numbers or metrics
• Add "within," "by," "no more than," "at least," "maximum," "minimum"
• Define what system state or user action indicates success
• Include thresholds, tolerances, and acceptable ranges

Tip 12: Understand Trade-offs and Prioritization

When facing infeasible or untestable requirements on the exam, know that:

• You can't always meet all constraints (budget, schedule, features)
• Stakeholders must prioritize which constraints matter most
• Requirements may need to be broken into phases or reduced in scope
• Trade-off analysis is a key business analyst responsibility

The exam may ask what you'd do when facing conflicting constraints. The answer usually involves negotiation and prioritization with stakeholders.

Common Exam Scenarios

Scenario 1: The Over-Specified Requirement

Question: "The marketing team wants: 'Create a system that provides the best user experience with lightning-fast response times and unparalleled reliability.' What should you do?"

Answer Strategy: Recognize the vague language ("best," "lightning-fast," "unparalleled"). These are not testable. Ask clarifying questions to get specific metrics. For example: "What response time is 'lightning-fast'? In seconds? Milliseconds? What uptime percentage is 'unparalleled reliability'? 99%? 99.9%?"

Scenario 2: The Conflicting Constraints

Question: "A requirement states: 'Build an advanced AI system with 1M users, in 6 months, with a budget of $100K.' What feasibility issues exist?"

Answer Strategy: Identify feasibility conflicts:

• Technical: AI systems are resource-intensive; serving 1M concurrent users requires significant infrastructure
• Financial: Budget is too low for the scope
• Schedule: 6 months is unrealistic for this complexity
• Operational: Likely need specialized AI talent not readily available

Recommend stakeholders prioritize: reduce user count, extend timeline, increase budget, or reduce AI sophistication.

Scenario 3: The Subjective Success Criteria

Question: "A requirement states: 'The system shall be intuitive to use.' Is this testable? If not, how would you fix it?"

Answer Strategy: No, "intuitive" is subjective and unmeasurable. Fix it by adding metrics:

• "New users shall complete the onboarding process in 5 minutes without assistance"
• "Users shall achieve their primary task with no more than 3 clicks"
• "75% of users shall rate the interface as easy to use (4-5 stars on a 5-star scale)"

Quick Reference Checklist for Exam Day

For Feasibility Questions, Ask Yourself:

• ☐ Is the technology available or achievable?
• ☐ Does the budget support this requirement?
• ☐ Can this be completed in the stated timeline?
• ☐ Does the organization have the necessary skills and resources?
• ☐ Does it comply with legal, regulatory, and policy requirements?
• ☐ Does it conflict with existing systems or infrastructure?
• ☐ Are there dependencies that might impact feasibility?

For Testability Questions, Ask Yourself:

• ☐ Are all success criteria measurable and specific?
• ☐ Are there numerical metrics or thresholds defined?
• ☐ Could the QA team write clear test cases from this?
• ☐ Is the language objective or subjective?
• ☐ Is mandatory language used (shall, must, will)?
• ☐ Are acceptance criteria clearly defined?
• ☐ Can compliance be objectively verified?

Conclusion

Feasibility and testability are fundamental concepts for the CBAP exam and critical skills for business analysts. Success requires understanding:

• The five dimensions of feasibility (technical, financial, operational, schedule, legal/compliance)
• The characteristics of testable requirements (measurable, verifiable, clear, objective, complete)
• How to recognize and fix non-feasible and non-testable requirements
• The relationship between these concepts and overall requirements quality
• How to apply these concepts in real-world scenarios

By mastering these concepts and following the exam tips provided, you'll be well-prepared to answer any CBAP exam question on feasibility and testability of requirements.