Requirements Engineering

1. Stakeholder Analysis :-

Stakeholders can include team members, customers, or anyone affected by the project or can be a supplier. Stakeholder analysis was performed to identify participants who would be affected by the program.

2. Interviews :-

The purpose of the interview is to understand the client's expectations in the software. It is not possible to negotiate with all stakeholders and therefore party representatives are selected based on their abilities and loyalty.

Interviews may be open-ended or structured.

Benefits:

· Interactive discussion with stakeholders.

· The immediate follow-up to ensure the interviewer’s understanding.

· Encourage participation and build relationships by establishing rapport with the stakeholder.

3. Brainstorming Sessions :-

This technique is used to generate new ideas and find a solution for a specific issue. The members included for brainstorming can be domain experts, subject matter experts. Multiple ideas and information give you a repository of knowledge and you can choose from different ideas.

This session is generally conducted around the table discussion. All participants should be given an equal amount of time to express their ideas. 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.

Benefits:

· Creative thinking is the result of the brainstorming session.

· Plenty of ideas in a short time.

· Promotes equal participation.

4. Interface Analysis :-

Interface analysis is used to review the system, people, and processes. This analysis is used to identify how the information is exchanged between the components. An Interface can be described as a connection between two components.

Benefits:

· Provide missed requirements.

· Determine regulations or interface standards.

· Uncover areas where it could be a risk for the project.

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

6. Prototyping :-

Prototyping is used to identify missing or unspecified requirements. In this technique, frequent demos are given to the client by creating the prototypes so that client can get an idea of how the product will look like. Prototypes can be used to create a mock-up of sites, and describe the process using diagrams.

Benefits:

· Gives a visual representation of the product.

· Stakeholders can provide feedback early.

7. Use case :-

This process combines text and images to provide a better understanding of needs. Usage cases define 'what', of the system and not 'how'. Therefore, they only provide an active view of the system. The design features of the application case include three main elements - Actor, Application cases, application case drawing.

Actor -

An external agent who is outside the system but interacts with it in some way. A character is probably a person, a machine etc. It is represented as an image of a stick. The characters can be the main characters or the second characters.

· Primary Actor - It needs help in the system to achieve the goal.

· Secondary Actor - Character in which the program needs help.

Use cases -

· They describe the sequence of interactions between the players and the system. They capture (the characters) what they are doing (interacting) with the program. A complete set of usage cases specifies all possible ways to use the system.

Use case diagram -

· The application status diagram clearly represents what happens when the character interacts with the system. Captures the operating system feature.

o The image of the stick is used to represent the character.

o Oval is used to represent the use case.

o The line is used to represent the relationship between the character and the state of use.

Software Requirements: Functional, Non- Functional

Requirements analysis is a very important process that makes the success of a program or software project evaluated. Requirements are usually divided into two types: Functional and non-functional requirements.

Functional Requirements:

Functional requirements define the function that a system or part of a system should perform and should be written in separate forms. Operational requirements define system behavior as they are associated with system performance.

All of these functionalities need to be included in the program as part of the contract. This is displayed or expressed in the form of an input that must be given to the system, the work performed and the expected output. Operational requirements should be written in simple language, so that it is easily understood. They are basically the requirements specified by the user which one can see directly in the final product, as opposed to the non-functional requirements. The examples of functional requirements are authentication, business rules, audit tracking, certification requirements, transaction corrections, etc.

Non-Functional Requirements:

These are basically the quality constraints that the system must satisfy according to the project contract. Non-functional requirements are not related to the software's functional aspect. These requirements define the general characteristics, behaviour of the system, and features that affect the experience of the user. They can be the necessities that specify the criteria that can be used to decide the operation instead of specific behaviors of the system They are also called non-functional requirements. Basic non-functional requirements are - usability, reliability, security, storage, cost, flexibility, configuration, performance, legal or regulatory requirements, etc.