Functional and Non Functional Requirements

Functional Requirements

Functional requirements define a function that a system or system element must be qualified to perform and must be documented in different forms. The functional requirements describe the behavior of the system as it correlates to the system's functionality. Functional requirements should be written in a simple language, so that it is easily understandable. The examples of functional requirements are authentication, business rules, audit tracking, certification requirements, transaction corrections, etc. These requirements allow us to verify whether the application provides all functionalities mentioned in the application's functional requirements. They support tasks, activities, user goals for easier project management. There are a number of ways to prepare functional requirements. The most common way is that they are documented in the text form. Other formats of preparing the functional requirements are use cases, models, prototypes, user stories, and diagrams.

Non-functional requirements

Non-functional requirements are not related to the software's functional aspect. They can be the necessities that specify the criteria that can be used to decide the operation instead of specific behaviors of the system. Basic non-functional requirements are - usability, reliability, security, storage, cost, flexibility, configuration, performance, legal or regulatory requirements, etc.
They are divided into two main categories:

1.Execution qualities like security and usability, which are observable at run time.

2.Evolution qualities like testability, maintainability, extensibility, and scalability that embodied in the static structure of the software system.

Non-functional requirements specify the software's quality attribute. These requirements define the general characteristics, behavior of the system, and features that affect the experience of the user. They ensure a better user experience, minimizes the cost factor. Non-functional requirements ensure that the software system must follow the legal and adherence rules. The impact of the non-functional requirements is not on the functionality of the system, but they impact how it will perform. For a well-performing product, atleast some of the non-functional requirements should be met.

User and System requirements

User Requirements:

Functional Requirements: Descriptions of the system's functionality from the user's perspective. Specify what actions the system must perform.
Non-functional Requirements: Characteristics that do not relate to specific behaviors or functions. Include aspects like performance, usability, reliability, and security.
User Interface Requirements: Describe the look, feel, and behavior of the user interface. Include details on navigation, layout, and interaction.
User Stories: Short, simple descriptions of a feature or functionality, often written from the user's perspective.
Use Cases: Descriptions of how the system will be used in various scenarios. Include actors, preconditions, and expected outcomes.

System Requirements:

Functional Requirements: Detailed specifications of system behavior. Outline the inputs, processes, and outputs of the system.
Performance Requirements: Define the system's capabilities in terms of speed, response time, and throughput. Specify acceptable levels of performance under different conditions.
Security Requirements: Identify measures to protect the system from unauthorized access, data breaches, and other security threats.
Reliability and Availability: Specify the system's expected uptime, reliability, and availability.
Scalability Requirements: Define how the system will handle increased load and user base. Example: "The system should scale horizontally to accommodate a growing number of users."
Compatibility Requirements: Outline the compatibility of the system with other software, hardware, and operating systems. Example: "The system must be compatible with major web browsers (Chrome, Firefox, Safari, and Edge)."
Maintainability and Supportability: Specify requirements for system maintenance, updates, and support. Example: "The system should provide logs for troubleshooting, and updates should be deployable without significant downtime."

Feasibility Study

Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or system. Feasibility study is one of stage among important four stages of Software Project Management Process. 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. Among these Economic Feasibility Study is most important part of the feasibility analysis and Legal Feasibility Study is less considered feasibility analysis.

1. Technical Feasibility
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. Operational Feasibility
In Operational Feasibility degree of providing service to requirements is analyzed along with how much easy product will be to operate and maintenance after deployment. Along with this other operational scopes are determining usability of product, Determining suggested solution by software development team is acceptable or not etc.

3. Economic Feasibility
In Economic Feasibility study cost and benefit of the project is analyzed. Means 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.

4. Legal Feasibility
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.

Requirements Elisitation and Analysis:

Requirements Elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below:

1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations from the software. It is impossible to interview every stakeholder hence representatives from groups are selected based on their expertise and credibility. Interviews maybe be open-ended or structured. In open-ended interviews there is no pre-set agenda. Context free questions may be asked to understand the problem. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions
It is a group technique It is intended to generate lots of new ideas hence providing a platform to share views A highly trained facilitator is required to handle group bias and group conflicts. Every idea is documented so that everyone can see it. Finally, a document is prepared which consists of the list of requirements and their priority if possible.
3. Facilitated Application Specification Technique
Its objective is to bridge the expectation gap – the difference between what the developers think they are supposed to build and what customers think they are going to get. A team-oriented approach is developed for requirements gathering. Each attendee is asked to make a list of objects that are: Part of the environment that surrounds the system. Produced by the system. Used by the system. Each participant prepares his/her list, different lists are then combined, redundant entries are eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements which are valuable to the customer. 3 types of requirements are identified:

• Normal requirements: In this the objective and goals of the proposed software are discussed with the customer. Example – normal requirements for a result management system may be entry of marks, calculation of results, etc.
  
• Expected requirements: These requirements are so obvious that the customer need not explicitly state them. Example – protection from unauthorized access.
  
• Exciting requirements: It includes features that are beyond customer’s expectations and prove to be very satisfying when present. Example – when unauthorized access is detected, it should backup and shutdown all processes.
  

5. Use Case Approach This technique combines text and pictures to provide a better understanding of the requirements. The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional view of the system. The components of the use case design include three major things – Actor, use cases, use case diagram.

• Actor: It is the external agent that lies outside the system but interacts with it in some way. An actor maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors or secondary actors.
• Primary actors: It requires assistance from the system to achieve a goal.
• Secondary actor: It is an actor from which the system needs assistance.
• Use cases: They describe the sequence of interactions between actors and the system. They capture who(actors) do what(interaction) with the system. A complete set of use cases specifies all possible ways to use the system.
• Use case diagram: A use case diagram graphically represents what happens when an actor interacts with a system. It captures the functional aspect of the system.

A stick figure is used to represent an actor. An oval is used to represent a use case. A line is used to represent a relationship between an actor and a use case.