I use the term feasibility to mean the degree to which a requirement for a system I work on can be implemented under the constraints that apply. In plain words, I ask: can we build this requirement with the resources, time, technology, and rules we have? First, I look for technical viability. Next, I check economic viability. Then, I review legal and regulatory viability. After that, I consider operational and organizational feasibility. Moreover, I include schedule, resource, and risk aspects. Therefore, it becomes a balanced judgment across many factors.
I assess feasibility early and often. For example, I evaluate it during elicitation, specification, and validation. However, I do not wait until design or implementation. Instead, I use small experiments to learn fast. In particular, I use exploratory prototypes to validate whether stakeholders mean what they say. Furthermore, I use prototypes to test technical ideas that affect feasibility. Nevertheless, I avoid confusing prototype results with final design decisions. Above all, I separate problems, requirements, and solutions as much as I can when I document them. Yet, I accept that full separation is rarely possible.
I watch for solution bias. Specifically, stakeholders sometimes propose solutions that shape the requirements. As a result, I may see conflicting requirements that stem from different imagined solutions. Therefore, I clarify the underlying problem first. Then, I evaluate whether a requirement remains feasible across plausible solutions. In addition, I check whether a requirement is feasible only after exploring a design idea. Thus, feasibility can depend on finding or inventing a viable solution.
I follow a clear feasibility checklist. First, I verify technical feasibility: do we have the knowledge, tools, and interfaces to implement this? Second, I check cost and benefit: will the expected value justify the expense? Third, I confirm legal and compliance constraints: will regulations allow this? Fourth, I analyze operational fit: can users and operations support this requirement? Fifth, I review schedule and resource limits: can we deliver on time with the people available? Sixth, I consider security, privacy, and environment concerns. Consequently, I rate each requirement with a feasibility status and notes.
I use methods and techniques to improve feasibility assessments. For instance, I use prototypes for validation. Specifically, I build wireframes or mock-ups to clarify user needs. Also, I build experimental breadboards to explore technical feasibility, although I usually keep those separate from requirements engineering. In addition, I use design thinking and creativity techniques to reveal innovative requirements. Moreover, I combine stakeholder input with technical exploration to avoid missing feasible opportunities.
I document feasibility decisions clearly. Likewise, I record assumptions and constraints. For example, I note required hardware, third-party services, or regulatory waivers. Furthermore, I log unresolved risks that affect feasibility. Thus, I enable later teams to revisit decisions with context.
Finally, I treat feasibility as a living attribute. Even if I rate a requirement as feasible today, new constraints can change that rating later. Therefore, I revisit feasibility at major milestones. In short, I balance optimism with realism. Consequently, I deliver requirements that stakeholders want and that we can actually implement.