Andrew
Burak
CEO at Relevant

Software Feasibility Study: Its Types and How to Write

#Tech label

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:

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 process
Source

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.

How to Tap Into Global Talent Pool to Fill Tech Positions Faster
In this ebook, you'll learn how to solve your tech talent shortage by tapping into the global talent pool.
Download the ebook

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 Requirements.

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.

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.

Schedule a call

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

Why these 200 tech companies & startups outsource to Ukraine
Download the whitepaper

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.

Written by
Andrew Burak
CEO at Relevant
My company has helped hundreds of companies scale engineering teams and build software products from scratch. Let's connect.

What are you looking to do?

Do you want a price estimate for your project?