Feasibility study in software engineering: types, steps and a checklist
A feasibility study in software engineering checks, before development starts, whether a proposed system is worth building and can be built. It looks at five areas, often remembered as TELOS: technical, economic, legal, operational and schedule feasibility. It ends with a clear recommendation: go ahead, go ahead with a changed scope, or stop.
The study is cheap compared with what it prevents. A project that is technically risky, too expensive to run, at odds with data protection law or impossible to deliver by the date that matters is far cheaper to change on paper than halfway through the build. This article covers what each type of feasibility checks, how to test whether individual requirements are feasible, the steps of a study, and what the final report should contain.
If you are planning custom software, this is the thinking to do before you ask for quotes, and the questions a good development partner should help you answer.
What a feasibility study answers
Every feasibility study, large or small, comes down to five questions:
- Can we build it? With the technology, data and skills available to us.
- Is it worth it? Do the benefits outweigh the cost of building and running it?
- Are we allowed to? Under the laws, contracts and licences that apply.
- Will people use it? Does it fit how the organisation actually works?
- Can it be ready in time? By the date when it still matters.
A "no" to any one of them is enough to stop or reshape a project, which is why the study looks at all five rather than just the technology.
The five types of feasibility
Technical feasibility
Technical feasibility asks whether the system can be built with the technology and skills available. Check the integrations it depends on (do the other systems have usable APIs?), the data it needs (does it exist, and is it clean enough?), the performance and security it must reach, and whether your team or partner has built something similar before.
Where something is genuinely uncertain, such as an integration nobody has tried or an AI feature whose accuracy is unknown, build a small prototype to find out. A few days spent proving the riskiest part works is the best value in the whole study.
Economic feasibility
Economic feasibility compares costs with benefits. Count the full cost of ownership, not just the build: hosting, licences, support, maintenance and the internal time needed to run the system. Put the benefits in the same units, such as hours saved, errors avoided or revenue gained, and work out when the project pays for itself.
Use ranges rather than single numbers. "Between AED 150,000 and 220,000" is more honest at this stage than a precise figure, and it shows how sensitive the decision is to the estimate.
Legal feasibility
Legal feasibility checks that the system can be built and run lawfully. The usual questions are data protection (in the UAE, Federal Decree-Law No. 45 of 2021 covers personal data on the mainland, while the DIFC and ADGM free zones have their own laws), sector rules in areas such as health and finance, the licences of any open-source or third-party components, and who will own the code and the data. Your legal adviser should confirm what applies to you.
Operational feasibility
Operational feasibility asks whether the system will actually be used once it exists. Who uses it, how does it change their work, and what training will they need? Who supports it after launch? Many technically sound systems fail here, because they were designed around how a process should work rather than how it does.
Schedule feasibility
Schedule feasibility tests whether the project can be delivered by the date that matters, such as a regulatory deadline, a season or a contract start. List the dependencies outside your control, such as approvals, data from another team or a third party's API, and plan the order of work so the date-critical parts come first.
Software requirements feasibility analysis
Alongside the five areas, the study checks the requirements themselves. A requirement is feasible when it is:
- A real need, not a solution in disguise. "Managers approve leave on their phone" is a need; "build a mobile app" is one way to meet it.
- Clear and testable. "Search returns results within two seconds" can be checked; "search is fast" cannot.
- Achievable within the constraints. Possible with the budget, data and technology available.
- Consistent with the others. Requirements that contradict each other, such as full offline use and live data everywhere, need a decision before the build.
- Worth its cost. Rank requirements by value, so the expensive ones that add little can be dropped or deferred.
Requirements that fail these checks are not thrown away. They are rewritten, split, or moved to a later phase, and the study records why.
Steps of a feasibility study
- Define the problem and the measure of success. What should be different once the system exists, and how will you know?
- Gather high-level requirements. From the people who will use, pay for and support the system.
- List the options. Build custom software, buy an existing product, adapt what you have, or do nothing. Doing nothing is a real option with its own cost.
- Assess each option against the five areas. Technical, economic, legal, operational and schedule.
- Test the biggest risks. Prototype the uncertain parts rather than estimating around them.
- Estimate costs and benefits. As ranges, including running costs.
- Recommend and document. Go, go with changes, or stop, with the reasons.
What goes in a feasibility report
- The problem, the goal and how success will be measured.
- The options considered, and why the others were rejected.
- Findings for each of the five areas, with the evidence behind them.
- The main risks and how each will be reduced.
- Cost and benefit ranges, and when the project pays back.
- An outline plan and timeline for the recommended option.
- A clear recommendation, and what would change it.
Keep it short enough that the people making the decision will read it. A few pages is enough for a small internal tool; a large platform justifies more, with appendices for the detail.
A quick checklist
| Area | Ask before you start |
|---|---|
| Technical | Have the risky integrations or features been proven with a prototype? |
| Economic | Does the cost range include running and support, and when does it pay back? |
| Legal | Which data protection rules apply, and who owns the code and the data? |
| Operational | Who uses it, who supports it, and what changes in their day? |
| Schedule | Which date matters, and which dependencies could move it? |
Questions people ask
What are the five types of feasibility study?
Technical, economic, legal, operational and schedule feasibility, often shortened to TELOS. Some methods add market feasibility for products sold to customers, which asks whether enough people will pay for it.
Is a feasibility study the same as requirements analysis?
No. Requirements analysis works out in detail what the system must do. A feasibility study comes first and decides whether the project should go ahead at all, using high-level requirements. Their findings feed each other: a feasibility study often trims the requirements, and detailed analysis can reopen feasibility questions.
When can you skip a feasibility study?
For small, low-risk changes to a system you already run, a short conversation covering the five questions is usually enough. A formal study pays off when a project is expensive, depends on technology or data you have not used before, handles personal or regulated data, or has a fixed deadline.
Who should carry out the feasibility study?
Someone who understands the business problem working with someone who has built similar systems. The client brings the goals, constraints and processes; the development partner brings the technical judgement, estimates and prototypes. A study done by only one side tends to miss what the other knows.
