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:
Table of Contents
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.
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.
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.
Describe clearly and succinctly the objective of the project. Writing characteristic focused on the executive level. Use phrases in the infinitive.
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.
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.
One of the most important items in the feasibility study document, will be covered in a specific post on Requirements.
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.
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.
Cite the benefits expected to be achieved through the implementation of the system. Tangible and intangible benefits.
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.
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.
Presentation of preliminary activities, with dates and resources involved. Be based on the stages of software development.
Design -> Elaboration -> Construction -> Transition
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.