What is Feasibility Study ? | Types of Feasibility Study

Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or system. As name suggests feasibility study is the feasibility analysis or it is a measure of the software product in terms of how much beneficial product development will be for the organization in a practical point of view. Feasibility study is carried out based on many purposes to analyze whether software product will be right in terms of development, implantation, contribution of project to the organization etc. 

Types of Feasibility Study: 

The feasibility study mainly concentrates on below five mentioned areas.

1. Technical Feasibility:

Technical feasibility inspects whether software can be built at all with available tools and experts. In Technical Feasibility current resources both hardware software along with required technology are analyzed/assessed to develop project. This technical feasibility study gives report whether there exists correct required resources and technologies which will be used for project development. Along with this, feasibility study also analyzes technical skills and capabilities of technical team, existing technology can be used or not, maintenance and up-gradation is easy or not for chosen technology etc. 

2. Economic Feasibility:

Economic feasibility examines the costs and financial benefits of the project. Under this feasibility study a detail analysis is carried out what will be cost of the project for development which includes all required cost for final development like hardware and software resource required, design and development cost and operational cost and so on. After that it is analyzed whether project will be beneficial in terms of finance for organization or not. 

3. Operational Feasibility:

Operational feasibility explores how a new project will impact daily processes in your company, what procedures should be implemented, and what efforts should be taken to maintain it. Say you’re going to launch a global e-commerce platform. Then, you need to have local warehouses, local service teams, and, in some cases, even local websites in each country. It’s very difficult to realize operationally and might make no sense at all though the initial idea looks commercially attractive and technically feasible.

4. Legal Feasibility: 

Legal feasibility makes sure that the product complies with all regulations and doesn’t break any law. In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing barriers of legal implementation of project, data protection acts or social media laws, project certificate, license, copyright etc. Overall it can be said that Legal Feasibility Study is study to know if proposed project conform legal and ethical requirements. 

5. Schedule Feasibility:

In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed project which includes how many times teams will take to complete final project which has a great impact on the organization as purpose of project may fail if it can’t be completed on time. 

Functional and Non-Functional Requirements:

Functional Requirement:

Functional requirements define what a software system should do. It defines a function of a software system. Functional requirement describes the functions software must perform. A function is nothing but inputs, its behavior, and outputs. It can be a calculation, data manipulation, business process, user interaction, or any other specific functionality which defines what function a system is likely to perform.

Functional requirements describe what specifically needs to be implemented in a software system or product, what actions should be performed by users about this development. Functional requirements in software engineering help us to capture the intended behavior of the system. This behavior may be expressed as functions, services or tasks or which system is required to perform.

We can describe functional requirements as the behavior of the system as it connects to the system’s functionality. Authentication, audit tracking, certification requirements, etc are examples of functional requirements.

 

Non-Functional Requirement:

A non-functional requirement defines the quality attribute of a software system. Some of the basic non-functional requirements are reliability, security, usability, scalability, maintainability, storage, cost, configuration, performance, etc.

The non-functional requirements primarily include various attributes of product quality properties – the requirements that determine the qualitative characteristics of development (software, information system) such as reliability, scalability, product performance, etc.

Non-functional requirements describe exactly how the created system or software product works, what properties and characteristics a particular development has.

A non-functional requirement is essential to ensure the usability and effectiveness of the entire software system. Failing to meet non-functional requirements can result in systems that fail to satisfy user needs.

 

Difference between Functional and Non-Functional Requirements:

 

Functional Requirements	Non-Functional Requirements
Functional requirements help to understand the functions of the system.	Non-functional requirements help to understand the system's performance.
A functional requirement defines a system or its component.	A non-functional requirement defines the quality attribute of a software system.
Helps us verify the functionality of the software.	Helps us to verify the performance of the software.
Functional requirements are mandatory.	Non-functional requirements are not mandatory.
Functional requirements allow us to measure the functionality of the software.	It allows us to check the performance of the system.
The functional requirements mentioned the activities a software system should perform.	It sets some rules and regulations for a software system on how it should fulfil the essential need.
These requirements are established by the user.	These requirements are established by technical persons, such as e.g. software developers, architects, and more.
These are easy to define.	These are hard to define.
Focuses on user requirement	Concentrates on the user's expectation and experience.
Functional requirements can exist without a non-functional requirement.	Non-functional requirements cannot exist without functional requirement.

 

SRS Document:

A  SRS ( Software requirements specification) document describes the intended purpose, requirements and nature of software to be developed. It provides a detailed overview of software product, purpose, requirements and features. The SRS document fully describes what the software will do and how it will be expected to perform.

The customer requirements identified during the requirements gathering and analysis activity are organized into SRS document. The three most important contents of this document are the functional requirements, non-functional requirements, and the goals of implementation.

It is written using end-user terminology. This makes the SRS document understandable by the customer. SRS document acts as a representation of software that enables the customers to review whether it (SRS) is according to their requirements. The SRS document normally serves as a contract between the development team and the customer. Any future dispute between the customer and the developers can be settled by examining the SRS document. The SRS document is therefore an important document which must be thoroughly understood by the developer team, and reviewed jointly with the customer. The SRS document not only forms the basis for carrying out all the development activities, but several documents such as users’ manuals, system test plan, are prepared directly based on it.

Characteristics of a Good SRS Document:

Software requirements specification should be unambiguous, accurate, complete, efficient, and of high quality, so that it does not affect the entire project plan. An SRS is said to be of high quality when the developer and user easily understand the prepared document. 

The characteristics of SRS are explained below:

Correctness: 

Every requirement in the SRS must be true requirements of the system. User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it covers all the requirements that are actually expected from the system. Correctness ensures that all specified requirements are performed correctly.

Completeness: 

SRS is complete when the requirements clearly define what the software is required to do. This includes all the requirements related to performance, design and functionality. SRS should contain all sorts of input and it should provide features for handling all functions of the system.

Consistency:

Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. For example, there can be a case when different requirements can use different terms to refer to the same object. SRS should use consistent terminologies so that there is no requirement that conflicts with another.

Unambiguousness: 

SRS is unambiguous when every requirement specified in SRS document has only one interpretation. This implies that each requirement is uniquely interpreted. In case there is a term used with multiple meanings, the requirements document should specify the meanings in the SRS so that it is clear and simple to understand.

Verifiability: 

SRS is verifiable if and only if there exists some cost-effective process that can check whether the final product meets the requirement.

Modifiability: 

SRS Document must be modifiable. The requirements of the user can change, hence requirements document should be created in such a manner that those changes can be modified easily, consistently maintaining the structure and style of the SRS.

Traceability: 

SRS is traceable when the source of each requirement is clear and facilitates the reference of each requirement in future. For this, forward tracing and backward tracing are used. Forward tracing implies that each requirement should be traceable to design and code elements. Backward tracing implies defining each requirement explicitly referencing its source.