Software Engineering Requirements Analysis

Requirements Analysis

By Degree Corners Last updated Aug 29, 2024

IEEE defines a requirement:

“A condition or capability needed by a user to solve a problem or achieve an objective”;

Software Requirements can be of two types:
1. Functional requirements:

It specifies how the system should process particular input in order to provide certain service.
It specifies the behavior and features of the system.
2.Non-functional requirements:
It specifies the constraints imposed on a system.
Constraints can be regarding quality, security, performance of the system.

Requirements Elicitation

Requirements elicitation is nothing but gathering the requirements of the proposed system.
It mainly aims at understanding and clarifying business goals through communication with the stakeholders.
Stakeholders together gives problem specification and features expected from the proposed solution.
Problems which can be faced during this activity are:

Problems of scope: When boundary of the system is not clearly defined it results into problems of scope.
Problems of understanding: These problems are faced when customer cannot clearly specify what they need from the system.
Problems of volatility: These problems occur when requirements are volatile or change over period of time.

Collaborative Requirements Gathering Approaches:

1.Quality Function Deployment:

QFD is a technique that translates customer requirements into technical requirements for software.
QFD focuses on customer needs throughout the software engineering process.
QFD identifies 3 types of requirements :
Normal requirements:
It reflects objectives and goals stated for a system during meetings with the customer. If these requirements are present, the customer is satisfied.
Example graphical displays, specific system functions and defined levels of – performance.
Expected requirements:
These are implicit to the system and may be so fundamental that the customer does not explicitly state them.
Absence of such requirements causes customer dissatisfaction
Example – ease of human-machine interaction, overall operational correctness and reliability and ease of software installation.
Exciting requirements:
These reflect features that go beyond the customer’s expectations and prove to be very satisfying when present.
Example word processing software is requested with standard features.
The delivered product contains a number of page layout capabilities that are quite pleasing and unexpected.

Identifying the Stakeholders

Stakeholder is the personnel who benefits in a direct or indirect way from the system that is being developed.

Different stakeholders that are included in the RE process:

Client/Customer: He is the contract partner who orders the software. Decides on budget and system functionalities

Users: Uses the system

Advocate: Speaks two languages – one of the customer and one of the engineers. Should be technically expert and domain expert.

Project Manager: Is the contract partner. Controls the budget.

Requirement Engineer/ Programmer/ Software engineer: Has knowledge of software engineering and is actually responsible for software development.

Example:

ATM stakeholders

Bank customers: receive services from the system. Representatives of other banks have reciprocal agreements that allow each other’s ATMs to be used.

Bank managers: obtain management information from the system.

Counter staff: are involved in the day-to-day running of the system.

Database administrators: are responsible for integrating the system with the bank’s customer database.

Security managers: ensure that the system will not pose a security hazard.

Marketing department: uses the system as a means of marketing the bank.

Hardware and software maintenance engineers: are responsible for maintaining and upgrading the hardware and software

Requirement Elicitation Techniques:

software system by communicating with clients, end users, system users and others who have a stake in the software system development.

There are various ways to discover requirements, some of them are given below:

1.Interviews :

Analysis used interviews to collect information from individuals or from groups.
The respondence are current users or new users. The current users are from existing system and new users are from proposed in.
For example – managers or employee provide data.
Interviews are not always the best source for collecting information because the time is required for interviews to held. During interview, the respondents and software engineers discuss with each other.
Interview provides opportunities for gathering information from respondents.
Interview is the best method for producing qualitative information such as opinions, policies, subjective description of activities and problems.
The format encourages respondent to share their feelings, ideas etc.
They structured interview uses standardize question; it close response format.
The unstructured interview allows the respondents to answer in their own words.
Whereas a structure interview uses the set of prescribe answers.
The success of an interview depends on the skill of interviewer and on the preparation for the interview

2.Surveys:

Organizations may conduct surveys among various stakeholders by querying about their expectations and requirements from the upcoming system.

3.Questionnaires:

A document with a predefined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended.

4.Observation:

Team of experts visit the client’s organization or workplace.
They observe the actual working of the existing installed systems.
They observe the workflow at client’s end and how execution problems are dealt.
The team itself draws some conclusions which aid to form requirements expected from the software.

software requirements specification:

IEEE defines software requirements specification as, “a document that clearly and precisely describes each of the essential requirements (functions, performance, design constraints and quality attributes) of the software and the external interfaces. Each requirement is defined in such a way that its achievement can be objectively verified by a prescribed method, for example, inspection, demonstration, analysis or test.”

Features of SRS:

1. It forms the basis for software development.

2. SRS provides a reference for validation of the final software product

3. It is a medium or media through the client and used needs are accurately specified and determined.

4. SRS helps clients to understand their own needs and requirements. 5. It establishes the basis for agreement between the client and the supplier.

Purposes served by SRS:

1. Feedback: Provides feedback, which ensures to the user that the organization (which develops the software) understands the issues or problems to be solved and the software behavior necessary to address those problems.

2. Decompose Problem into Components: Organizes the information and divides the problem into its component parts in an orderly manner.

3. Validation: Uses validation strategies applied to the requirements to acknowledge that requirements are stated properly.

4. Input to Design: Contains sufficient detail in the functional system requirements to devise a design solution.

5. Basis for Agreement Between the User and the Organization: Provides a complete description of the functions to be performed by the system. In addition, it helps the users to determine whether the specified requirements are accomplished.

6. Reduce the Development Effort: Enables developers to consider user requirements before the designing of the system commences. As a result, ‘rework’ and inconsistencies in the later stages can be reduced.

7. Estimating Costs and Schedules: Determines the requirements of the system and thus enables the developer to have a ‘rough’ estimate of the total cost and schedule of the project.

Characteristics of SRS :

I.Correct: Every requirement specified in SRS shows something required from the software.

ii. Complete: All functionalities expected from the software should be mentioned in the SRS. It is very important and difficult to achieve.

iii. Clear/Unambiguous: Every requirement specified in SRS should be clear to understand. It should not lead to any ambiguity. iv. Verifiable: There should be some cost-effective process to check whether the final product meets every requirement specified in the SRS.

V.Consistent: There should not be requirements which are conflicting with each other in the SRS.

vi. Stability: It refers to the chances of the requirements to be changed in future.

Advantages of SRS:

1.It creates a general agreement between the client / user and the developer on what facilities the developed software should produce.

2.It also provides specification for validating the final product. It helps both customer and developer to convince whether the final software developed is same as per the user’s expectations.

3.High quality SRS results in high quality software

4.A high-quality SRS also reduces the development cost as fixing bugs in later stage of development is very expensive.

Analysis Patterns:

Analysis patterns are those patterns that reoccur across all projects within a specific application domain and they represent a class, a function or a behavior within the application domain that can be reused when modeling different applications.
Advantages :
Analysis patterns speed up the development of abstract analysis models that can be reusable.
Analysis patterns facilitate the transformation of analysis model into a design model by suggesting design patterns and reliable solutions for common problems.
Analysis patterns are integrated and stored in a repository so that requirements engineers can use search facilities to find and reuse them.
Information about analysis pattern is presented in a standard template that takes the form:
Pattern Name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents or what problem is addressed within the context of an application domain.
Motivation: A scenario that illustrates how the pattern can be used to address the problem.
Forces and context: A description of external issues that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied.
Solution: A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied and what trade-offs exist during its application.
Design: Discusses how the analysis pattern can be achieved through the use of known design patterns.
Known Uses: Examples of uses within actual systems.

Negotiating Requirements

Requirements engineering plays an important role in shaping of the desired software.
The quality of software developed is directly related with the requirements specified.
Though all stakeholders have common goal to build the system, as an individual each one of them has different expectations and perception towards the system.
Conflicts are unavoidable during the requirements elicitation process because of different roles, responsibilities, concerns and priorities of stakeholders. I
n order to handle these conflicts negotiation of requirements is essential.
Requirements Analysis The intention of the negotiation is to achieve a win-win situation for all.
The stakeholders win as the software satisfying most of their requirements is delivered and the developer win by developing the software within given budget and time.
Boehm defines set of negotiation activities to be performed at the beginning of the software engineering process, as follows:
i. Identification of the system or subsystem’s key stakeholders.
ii. Determining “win conditions” for each stakeholder.
iii. Negotiation of the stakeholder’s “win conditions” in order to overcome the conflicts.

Validating Requirements:

It is a process which checks whether the requirements gathered define the system expected by the user.
In order to maintain consistency and clarity of requirement model different validity checks are performed on it such
1. Validity checks: As user requirements may change with changing environment it is required to check whether requirement model shows the real needs of the client.
ii. Consistency checks: It is required to check that requirements are not conflicting or contradicting each other.
iii. Completeness checks: Ensures all constraints and functions are bounded and specified clearly in SRS.
iv. Realism checks: It checks whether the requirements specified shows an essential feature of the system and whether it is cost effective to implement these features.
V. Verifiability: These checks are performed to find whether implemented requirements are testable in order ensure the delivered system meets the specification.

Validation techniques which can be used individually or in combination are:

1.Requirements reviews: Review team conducts systematic review order to find bugs or inconsistencies.

2.Prototyping: In order to handle changing and hidden needs of the user a working system is developed and given to the end user. Feedback from the end user can help in updating the requirements.

3.Test-case generation: Every requirement specified should be testable, so tests are developed for every requirement specified by the user leading to test-driven development.

Elements of the Analysis Model:

1.Scenario based elements:

One approach of scenario based elements is where; the system is described from user’s point of view using the use cases and their corresponding use case diagrams.
Use case is the description of the interaction between an actor and the system.
Another approach depicts the functions that exist within a processing context. These functions can be defined at various levels of abstraction in the analysis model.

2.Class based elements:

Each usage scenario implies a set of objects that are manipulated as an actor interacts with the system.
These objects are categorized into classes.

3.Behavioral elements:

It describes the overall behavior of the system.
The State diagram is one method for representing the behavior of a system by depicting its states and the events that cause the system to change state.
A state is an observable mode of behavior and also it states what actions are performed as a result of a particular event.

4.Flow oriented elements

This shows how data is processed by a system.
The data flow diagram is a method to represent the way the data is processed in the existing system. It shows how data flows through a sequence of processing steps.
We can create a flow model for any system regardless of its size and complexity.