The objective of a software feasibility study, as the name implies, is to assess from the operational, technical, economic and organizational point of view whether the project is viable. The document is intended for the system’s stakeholder (someone who has some direct or indirect influence on the system’s requirements). The feasibility study, especially professional software project feasibility analysis, takes place after specifying business requirements, that is, it is the second step of the requirements engineering process.

Its justification is justified in order to analyze and answer some questions from the point of view of operational, technical, schedule and economic feasibility, such as:

200+ companies from 25 countries outsourced software development to Relevant

We provide companies with senior tech talent and product development expertise to build world-class software. Let's talk about how we can help you.

Contact us

Types of feasibility to be analyzed

1. Organizational viability: it is related to how much the solution benefits the organization. It is verified if there will be adherence to the use of the solution by the users due to the organizational culture and the perception of those involved; whether the solution is aligned with the organization’s strategic objectives; whether there is understanding and support from the organization’s top management in relation to the project, etc.
2. Operational viability: it is related to how much the solution suits the organization; what are the requirements of the solution; what the customer expects the system to do;
3. Economic viability: analysis between the development cost and the benefits after the project is implemented (cost-benefit).
4. Technical software feasibility: linked to the technical support that the organization will offer for the development of the project; team or technology restrictions; need to invest in research before carrying out the project; etc.
5. Timeline feasibility: crossing between the activities surveyed and the estimated time to carry them out; definition of project milestones; impact of delays.
6. Others: legal, cultural, marketing, etc.

PIECES framework for software feasibility study

A tip that can be found when analyzing operational feasibility is to use a framework to categorize problems (checklist) and assist in requirements gathering, called PIECES. This methodology was created in 1994 by James Wetherbe and serves to analyze systems in order to solve problems, explore opportunities and meet established objectives; it also ensures that both analysts and users “speak the same language” when contributing to the definition of project requirements. The name PIECES comes from the acronym, where each letter categorizes a problem: Performance, Information, Economics, Control, Efficiency and Security.

• Performance: Does the current system or operation offer adequate flow and response time? It also relates to the maximum amount of processing that the system can perform.
• Information: Does the current operation provide stakeholders with correct, useful, and timely information? Is the information organized and easily found?
• Economy: does the current operation offer information services such as cost/efficiency suitable for the organization? Can there be cost savings? How to increase profit?
• Control: involves security. How to manage information security to prevent fraud or potential breaches of privacy, but without bureaucratizing or creating controls that delay operation.
• Efficiency: analyze activities that waste time, mainly caused by redundancy. How are resources being used?
• Services: how accurate is the system? Do you offer reliable services?

Software Feasibility Study Report Structure

Definitions, Acronyms and Abbreviations

This section should contain a brief explanation of possible definitions, acronyms and abbreviations that will appear and be linked to the business and, of course, to the Feasibility Study document, enabling anyone who reads them to interpret them correctly. If not, explain that it does not apply. It should be described in alphabetical order.

Overview

Explain in this section what the rest of the Software Feasibility Study document contains. Similar to the end of the Introduction section of a scientific article.

Purpose

Describe clearly and succinctly the objective of the project. Writing characteristic focused on the executive level. Use phrases in the infinitive.

Scope

Describe the scope of the project, highlighting the aspects that will be and will not be covered. Delimit the frontier of action. For aspects not covered: justify why they will not be attended to. The information stated here, may be more high-level.

Current diagnosis

Describe the customer’s current situation. Inform if in the current environment there is already a software product running that will be replaced or integrated into the new solution. In this case, describe the software, its version, supplier, a brief description of its characteristics and how it is used. Emphasize the current environment and the difficulties of that environment. If he does not have any software, indicate how he controls his business manually. Attach documents like receipts, contracts, spreadsheets, reports and even take pictures if possible.

Requirements

One of the most important items in the feasibility study document, will be covered in a specific post on software requirements specification.

Proposed Alternatives

List all proposed alternatives for solving the problem, including the one you are proposing. Search for similar solutions that already exist in the market, or academic research in the area, etc. Consider the analysis time of the proposed tool, time of implementation and training.

Recommended alternative

Among the alternatives mentioned in the previous item, cite the one recommended by the project’s authors, describing the reasons. Detail in the subsections the benefits of the chosen alternative, its costs for implementation and the risks involved during development.

Benefits

Cite the benefits expected to be achieved through the implementation of the system. Tangible and intangible benefits.

Costs

Relate the costs for the implementation of the alternative, with the highest degree of precision possible. Cite the source from which the costs were consulted.

Risks

Identify possible risks associated with the alternative. Also identify prevention and contingency actions. 

Consider the different types of risks involving: Technology; People; Organization; Tools; and Requirements.

Timeline

Presentation of preliminary activities, with dates and resources involved. Be based on the stages of software development. 

Design -> Elaboration -> Construction -> Transition 

Example activities: Business Modeling, Requirements, Analysis and Design, Implementation, Testing and Deployment.

Conclusions

Identify whether the project is viable or not, presenting the reasons that led it to such finding, summarizing the previous topics of the document.

Basically, software design must go through the above factors to have a greater chance of success. Thank you for reading and I hope this article can be useful.