Unit 2

Requirements Engineering & Analysis

Q. 1) What are functional and non - functional requirements?

Ans: Functional requirements

A functional requirement in software engineering determines a device or component. It defines the functions that must be performed by a programme. Nothing but inputs, their actions, and outputs are a function. It can be a calculation, data manipulation, business method, user interaction, or some other particular feature that determines what is likely to perform a system's purpose.

Requirements for usable applications allow you to capture the system's expected actions. This conduct may be represented in the form of functions, facilities or tasks or which system must be executed.

Example of functional requirements:

Some examples of non-functional specifications are available here:

●      Only workers at the managerial level have the right to access revenue data.

●      It is important to integrate the software framework with the banking API.

●      Automatically, the programme validates clients against the ABC Contact Management System

●      The Sales System should allow users to record sales of customers

Advantages of functional requirement

❏      Helps you to check if all the functionalities specified in the functional requirement of that application are given by the application.

❏      A document of functional specifications allows you to identify a system's functionality or one of its subsystems.

❏      Functional specifications help to define missing requirements along with requirement review. They help describe the intended service and behaviour of the system clearly.

❏      Errors caught in the collection stage of the Practical Requirement are the cheapest to repair.

Non - functional requirements

The quality attribute of a software system is specified by a non-functional requirement. They reflect a collection of criteria that are used to judge a system's basic activity. How quick, for example, does the website load?

To ensure the usability and efficacy of the entire software framework, a non-functional requirement is vital. Failure to meet non-functional specifications will lead to systems that do not meet the needs of users.

Non-functional specifications allow you to enforce system design restrictions or limitations through the various agile backlogs. For eg, if the number of simultaneous users is > 10000, the site should be loaded within 3 seconds. It is just as important as a functional requirement to define non-functional requirements.

Example of non - functional requirements:

Some examples of non-functional specifications are available here:

●      Users must, immediately after the first successful login, adjust the initially assigned login password. In addition, the original can never be reused.

●      Any failed attempt by a user to access a data item must be registered on the audit trail.

●      A website should be able to manage the effect of 20 million users on its results.

●      The device needs to be portable. Therefore, switching from one OS to another OS causes no problem.

Advantages of non - functional requirements

Non-functional testing's benefits/pros are:

❏      The non-functional specifications ensure that legal and regulatory laws are observed by the software system.

❏      They guarantee the reliability, usability and productivity of the software system.

❏      They guarantee good user experience and ease of software activity.

❏      They help to formulate the information system security strategy,

Q. 2) Describe the structure of SRS.

Ans: Structure of SRS

The process to gather the software requirements from client, analyze and document

Them is known as requirement engineering main goal of requirement engineering is

To develop and maintain sophisticated and descriptive ‘System Requirements

Specification’ document.

Requirement Engineering Process includes four steps:

a) Feasibility Study

b) Software Requirement Specification

c) Requirement Gathering

d) Software Requirement Validation

a)     Feasibility study

When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards the goal of the organization. This study analyses whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project

And products such as usability, maintainability, and productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.

b)    Software Requirement Specification-

SRS is a document created by system analyst after the requirements are collected from various stakeholders. It defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from clients are written in natural language. It is the responsibility of the system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.

c)     Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

d)    Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in these documents are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not

Nipped in the bud.

Requirements can be checked against following conditions -

o Able to be practically implemented

o Should be valid and as per functionality and domain of software

o No ambiguities

o Must be complete

o Should be clearly demonstrated

Q. 3) How to write a SRS?

Ans: Writing a SRS

It is necessary to write an SRS text. It's not always easy to do, though.

To write an effective SRS text, here are five measures you can follow.

1. Create an outline (or use an SRS template)

Your first move is to build an outline specification for your programme specifications. This could be something that you yourself make. Or you can use an existing prototype with SRS.

Here's what your outline could look like if you're making this yourself:

1. Introduction

1.1 Purpose

1.2 Intended Audience

1.3 Intended Use

1.4 Scope

1.5 Definitions and Acronyms

2. Overall Description

2.1 User Needs

2.2 Assumptions and Dependencies

3. System Features and Requirements

        3.1 Functional Requirements

        3.2 External Interface Requirements

        3.3 System Features

        3.4 Nonfunctional Requirements

You're able to start filling it out once you have your clear outline.

2.     Start with a purpose

There is a very significant introduction to your SRS. This sets the target for the product you're creating.

So, start by defining your product's function.

Intended Audience and Intended Use

Define who will have access to the SRS in your company, and how they should use it. Developers, reviewers and project managers can be part of this. It may also include stakeholders, including leadership teams, distribution, and marketing in other departments.

Product scope

Describe the programme that is being defined. And they have advantages, priorities, and objectives. This should relate to overall business objectives, especially if the SRS will be accessed by teams outside of growth.

Definition and Acronyms

Including a risk concept is wise. For many developers, especially those working on security-critical development teams, avoiding risk is top-of-mind.

3.     Give an overview of what you’ll build

Your next move is to include a summary of what you will be constructing. Is it a product upgrade to an existing one? Is this an add-on to a product that you have already developed?

These are crucial to explain in advance, so everyone understands what you're creating.

You can also clarify why you are constructing it and who it is for.

User needs

User specifications, or user classes and features, are important. You'll need to define who and how the product will be used.

You'll have primary and secondary users who will frequently use the product. The needs of a separate buyer of the item (who may not be a primary/secondary user) may also need to be specified. And, if you're designing a medical device, for instance, you'll need to explain the needs of the patient.

Assumption and dependencies

There may be variables influencing the ability to meet the criteria specified in your SRS. What factors are those?

Are there any assumptions you're making that could turn out to be wrong with the SRS? You should have, as well, those here.

Finally, you should remember whether any external factors are depending on your project. This may involve software components from another project that you are reusing.

4.     Detail your specific requirement

For your development team, the next section is key. This is where the basic specifications for the construction of your product are detailed.

Functional requirement

To build your product, functional specifications are crucial.

These specifications may include an infusion and a battery if you are developing a medical device.And you may have a subset of risks and requirements under these functional requirements.

External interface requirement

External specifications for interfaces are types of functional requirements. For embedded systems, they're essential. And they outline how other components can interact with your product.

There are many types of interfaces for which you may have specifications, including:

●      User

●      Hardware

●      Software

●      Communications

System features

System characteristics are functional requirement types. In order for a system to operate, these are features that are needed.

Other non- functional requirements

Non-functional criteria may be just as relevant as those that are functional.

These include, among others:

●      Performance

●      Safety

●      Security

●      Quality

Depending on your business, the significance of this form of requirement can vary. Safety standards in the medical device industry, for instance, would be crucial.

5.     Get approval of an SRS

You'll need to have it approved by key stakeholders once you've completed the SRS. And the current edition of the document should be checked by all.

Q. 4) Write short notes on user and system requirement.

Ans: User requirement

Describe what the user does in the device, also referred to as user needs, such as what tasks that users must be able to perform. In a User Requirements Document (URD) using narrative text, user requirements are normally reported. In general, user specifications are signed off by the user and used as the key input to build device requirements.

In designing a software product, a significant and challenging step is to decide what the consumer really wants it to do. This is because the consumer is frequently unable to express their needs and desires in their entirety, and the data they provide can also be incomplete, unreliable and self-conflicting. The burden of thoroughly knowing what the client needs falls on the business analyst. This is why user demands are normally taken into account separately from device specifications.

The business analyst carefully analyses user requirements and carefully builds and records a set of high-quality system requirements to ensure that these quality characteristics are met by the requirements.

System requirements

The building blocks developers use to build the system are system specifications. These are the standard "shall" statements that define what the "shall do. System requirements of the system are categorized as either functional or additional requirements."

For instance, the entry and printing of cost estimates will involve a system; this is a practical requirement. All the remaining specifications not covered by the functional requirements are specified by supplementary or non-functional requirements. Instead of non-functional specifications, I prefer to use the word supplementary demands; who wants to be labelled non-functional? Supplementary specifications are often called requirements for service quality.

In the system design, the strategy for implementing functional specifications is comprehensive. In the system architecture, the plan for implementing supplementary specifications is comprehensive.

The following list indicates different kinds of supplementary specifications:

Q. 5) Explain prioritizing requirements (Kano diagram).

Ans: Prioritizing requirements (Kano diagram)

As a function of customer satisfaction, Kano analysis helps one to prioritize requirements. Kano specified four categories into which it is possible to classify each function or necessity.

1. Surprise and delight

Capabilities that distinguish a service from its competition (e.g the nav-wheel on an iPod)

2.     More is better

Dimensions with a simple path of increasing utility along a continuum (e.g. Battery life or song capacity)

3.     Must be

Functional barriers to entry: consumers would not use the product without these capabilities (e.g. UL approval)

4.     Better not be

Represents material that dissatisfies clients (e.g. Inability to increase song capacity via upgrades).

Surprise and delight requirement:

Think of software as a customer for just a moment, not an accountant. We want software that is interesting to use and enjoyable. User interface affordances that allow us to just "do what comes naturally" and make the programme do precisely what we want. Fresh innovations that render better apps. When we click it, we're not talking about a button that brings up dancing squirrels, we're talking about useful features that make great apps.

These may be the criteria behind the delightful characteristics described above.

●      When holding the iPod in one hand, users must be able to pick songs.

●      With the expectation that users would never delete emails, the system must have an easy way to organise emails.

●      The framework offers appropriate support information for the context in which the consumer seeks assistance.

More is better requirement:

These are the terms that are most readily understood: bigger, quicker, better, stronger. The difficulty in writing a better requirement is to know when sufficient is enough. "They would be ambiguous requirements if we were to write requirements that said "minimize" or "maximize. It would be entirely impractical if we were to unambiguously request that our developers minimize search time.

It can also be very difficult to define accurate targets. The decreasing returns law comes into play. In economics, there is a term called utility that reflects the tangible and intangible benefits of something. With respect to the target users, we may consider the usefulness of a function.

A graph of the search-result generation speed utility will look like the following:

We can see that the associated gain to the consumer of further changes in speed is decreased as the speed of results increases. To define the criterion, we have only defined the benefit side of the cost-benefit analysis required. We now have an idea of the cost of implementing search after getting feedback from our implementation team, as seen in the following graph.

As we see, making increasingly smaller speed changes is progressively becoming more costly. We need to find the point in the curves where the incremental advantage of searching faster is equivalent to the incremental expense of searching faster to decide the ideal specification.

As shown in the next figure, we can do that by graphing utility versus cost.

The circle displays the point where the curve's slope is equal to 1. An additional increase in speed offers less value at this point in the curve than the associated increase in cost.

Must be requirements

These are the criteria that when they talk about requirements, most people think about. These are the best specifications to evoke.

Stakeholders will typically tell us what the app needs them to have. Am I hot in our world or not? We see that 37 signals rely on this as their primary criteria for inclusion in an initial software release after prioritization of requirements. They prefer to place only critical specifications or 'must be' in the initial software update.

Better not to be requirement

No, this is just the opposite of surprise and delight. Then critics complain about what holds it back if dreamers think about what makes something great. In Kano's analysis, we don't think this bucket really has a place. "Saying "Users don't like complicated navigation" offers no advantage over saying "Users prefer intuitive navigation. We recommend that this category not be used at all.

Q. 6) What do you mean by requirement traceability matrix (RTM)?

Ans: Requirement traceability matrix

In the Requirement Traceability Matrix or RTM, we set up a process to record the relations between the client's suggested user specifications and the system being designed. In short, it is a high-level document that maps and traces user specifications with test cases to ensure that appropriate testing levels are accomplished with each and every requirement.

The method for evaluating all test cases specified for each requirement is called Traceability. Traceability helps us to assess which specifications have produced the most defects during the phase of testing.

Full test coverage is and should be the focus of every research interaction. It literally means, by coverage, that we need to test anything that needs to be tested. 100 percent test coverage should be the goal of every research project.

Requirements the Traceability Matrix offers a way to ensure that the coverage element is tested. It helps to define coverage gaps by providing a snapshot. In short, it can also be referred to as metrics that specify for each requirement the number of test cases run, passed, failed or blocked, etc.

Types of Traceability Matrix

Forward Traceability:

Requirements for test cases of 'Forward Traceability'. It guarantees that the project is moving according to the desired path and that every condition is thoroughly tested.

Backward Traceability:

With the 'Backward Traceability' criteria, the test cases are mapped. Its primary objective is to ensure that the new product being produced is on the right track. It also helps to decide that no additional undefined features are implemented and the project's scope is therefore affected.

Bi-Directional Traceability:

(Forward + Backward): A Strong Traceability matrix contains references to criteria from test cases and vice versa (requirements to test cases). This is referred to as Traceability 'Bi-Directional.'

Q. 7) What do you mean by UML diagram?

Ans: UML diagram

In the field of software engineering, UML stands for Unified Modeling Language, a structured general-purpose visual modelling language. It is used to define, visualize, build, and record the software system's primary objects. It helps to design and define, especially those software systems that implement the Object Orientation concept. It defines the operation of software as well as hardware systems.

The UML was developed by Rational Software's Grady Booch, Ivar Jacobson, and James Rumbaugh in 1994-95. In 1997, the Object Management Community adopted it as a standard (OMG).

The Object Management Group (OMG) is a multi-company organisation which controls the open standard UML. The OMG was set up in order to develop an open standard that facilitates the interoperability of object-oriented systems in particular.

It is not limited to borders, but can also be used to model non-software structures. The OMG is best recognized according to the specifications of the Generic Object Request Broker Architecture (CORBA).

Goals of UML:

●      Since it is a modelling language for general purposes, it can be used by all modelers.

●      Due to the absence of standard methods at that time, UML came into existence after the introduction of object-oriented principles to systemize and consolidate object-oriented development.

●      It can therefore be inferred that UML is a basic approach to modelling that is used to model all functional structures.

Characteristics of UML:

The UML has the following characteristics:

●      It is a generalized language for modelling.

●      It is different from programming languages such as C++, Python, etc.

●      Object-oriented research and architecture are inter-related.

●      It is used to simulate the system's workflow.

●      It is a pictorial language that is used to create powerful objects for modelling.

Q. 8) Describe data modeling.

Ans: Data Modeling

For a computer-based system, there are several different ways of looking at the specifications. Different representation types compel you to consider criteria from multiple points of view, an approach that is more likely to expose omissions, contradictions, and uncertainty.

1 scenario-based modeling

From the user's perspective, the system is represented using a Scenario-based methodology. Basic use cases and their accompanying use-case diagrams, for instance, develop into more elaborate use cases based on models.

The first component of the model that is developed is mostly scenario-based elements of the requirements model. Three stages of elaboration are shown, resulting in a representation based on scenarios.

2 class-based modeling

Each scenario of use involves a selection of artefacts that are manipulated as an actor communicates with the device. Such artefacts are grouped into groups, a group of items with similar characteristics and common behaviours.

3 Flow oriented modeling

As knowledge flows through a computer-based system, it converts. In a variety of forms, the machine receives input, applies functions to transform it, and generates output in a variety of forms.

A control signal transmitted by a transducer can be the input, a number series typed by a human operator, an information packet transmitted over a network connection, or a voluminous data file retrieved from secondary storage.

A single logical comparison, a complex numerical algorithm, or an expert system's rule-inference approach can comprise the transform(s).

Q. 9) Define Analysis model.

Ans: Analysis model

Analysis of requirements is an important and necessary task after elicitation. To render clear and unambiguous demands, we evaluate, refine, and scrutinize the collected specifications. All specifications are checked by this operation which can include a graphical view of the entire system. It is expected that the understandability of the project will substantially increase after the completion of the study.

Here, the dialogue with the client may also be used to illustrate points of misunderstanding and to understand which specifications are more relevant than others.

The different steps in the study of requirements are shown in Fig:

1. Draw the context diagram:

A basic model describing the boundaries and interfaces of the proposed structures with the external world is the context diagram. This describes the entities that communicate with the system outside the proposed system.

II.            Development of a Prototype (optional):

Constructing a prototype, something that looks and ideally works as part of the device they claim they want, is one successful way to find out what the consumer needs.

Until the user is consistently pleased, we will use their input to change the prototype. The prototype therefore allows the customer to imagine the device proposed and increase the understanding of requirements.

A prototype may help both parties to make a final decision if developers and users are not sure about some of the elements.

The prototype could be designed at a reasonably low cost and quickly. Therefore, in the final framework, it would still have drawbacks and would not be reasonable. This task is optional.

III.            Model the requirements:

Typically, this method consists of different graphical representations of the functions, data entities, external entities, and their relationships. It will help to find wrong, contradictory, incomplete, and superfluous criteria in the graphical view. The Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc., contain such models.

IV.            Finalize the requirements:

We will have a clearer understanding of the behaviour of the system after modelling the requirements. It has established and corrected the contradictions and ambiguities. The flow of information among different modules has been analyzed. The practices of elicitation and interpretation have provided greater insight into the scheme. The assessed requirements are now finalized, and the next step is to record these requirements in a specified format.

Q. 10) What do you mean by Requirement engineering?

Ans: Requirement engineering

Requirement engineering is the broad spectrum (variety, range) of tasks and techniques that lead to an understanding of requirements.

In other words, RE (requirement engineering) refers to the mechanism in which specifications are specified, recorded and preserved.

A major software engineering operation is from a requirement engineering that starts during the communication activity and continues into the modelling activity. It needs to be customized to the requirements of the process, the project, the product and the people doing the job.

Software Requirements are a set of conditions or a capability possessed by software or system components to solve a real-world problem. The problems can be to automate a part of a system to correct shortcomings of an existing system, to control

a device, and so on. IEEE defines a requirement as:

“A condition or capability needed by a user to solve a problem or achieve an objective” or “The capability possessed by a system to satisfy a contract, standard, specification, or other formally imposed documents”.

When users request for software, they possess an approximation of what the new system should be capable of doing. Requirements differ from one user to another user and from one business process to another business process. Reliability means Operational reliability.

It is described as the ability of a system or component to perform its required functions under static conditions for a specific period. It can also be described as the probability that a software system fulfils its assigned task in a given environment for a predefined number of input cases, assuming that the hardware and the input are free of error.

Software can be defined as a collection of programs, documentation and operating procedures. Institute of Electrical and Electronic Engineers (IEEE) defines software as “a collection of computer programs, procedures, rules, and associated documentation and data”.

It contains seven different activities -

❏      Inception

❏      Elicitation

❏      Elaboration

❏      Negotiation

❏      Specification

❏      Validation

❏      Management

Unit 2

Requirements Engineering & Analysis

Q. 1) What are functional and non - functional requirements?

Ans: Functional requirements

A functional requirement in software engineering determines a device or component. It defines the functions that must be performed by a programme. Nothing but inputs, their actions, and outputs are a function. It can be a calculation, data manipulation, business method, user interaction, or some other particular feature that determines what is likely to perform a system's purpose.

Requirements for usable applications allow you to capture the system's expected actions. This conduct may be represented in the form of functions, facilities or tasks or which system must be executed.

Example of functional requirements:

Some examples of non-functional specifications are available here:

●      Only workers at the managerial level have the right to access revenue data.

●      It is important to integrate the software framework with the banking API.

●      Automatically, the programme validates clients against the ABC Contact Management System

●      The Sales System should allow users to record sales of customers

Advantages of functional requirement

❏      Helps you to check if all the functionalities specified in the functional requirement of that application are given by the application.

❏      A document of functional specifications allows you to identify a system's functionality or one of its subsystems.

❏      Functional specifications help to define missing requirements along with requirement review. They help describe the intended service and behaviour of the system clearly.

❏      Errors caught in the collection stage of the Practical Requirement are the cheapest to repair.

Non - functional requirements

The quality attribute of a software system is specified by a non-functional requirement. They reflect a collection of criteria that are used to judge a system's basic activity. How quick, for example, does the website load?

To ensure the usability and efficacy of the entire software framework, a non-functional requirement is vital. Failure to meet non-functional specifications will lead to systems that do not meet the needs of users.

Non-functional specifications allow you to enforce system design restrictions or limitations through the various agile backlogs. For eg, if the number of simultaneous users is > 10000, the site should be loaded within 3 seconds. It is just as important as a functional requirement to define non-functional requirements.

Example of non - functional requirements:

Some examples of non-functional specifications are available here:

●      Users must, immediately after the first successful login, adjust the initially assigned login password. In addition, the original can never be reused.

●      Any failed attempt by a user to access a data item must be registered on the audit trail.

●      A website should be able to manage the effect of 20 million users on its results.

●      The device needs to be portable. Therefore, switching from one OS to another OS causes no problem.

Advantages of non - functional requirements

Non-functional testing's benefits/pros are:

❏      The non-functional specifications ensure that legal and regulatory laws are observed by the software system.

❏      They guarantee the reliability, usability and productivity of the software system.

❏      They guarantee good user experience and ease of software activity.

❏      They help to formulate the information system security strategy,

Q. 2) Describe the structure of SRS.

Ans: Structure of SRS

The process to gather the software requirements from client, analyze and document

Them is known as requirement engineering main goal of requirement engineering is

To develop and maintain sophisticated and descriptive ‘System Requirements

Specification’ document.

Requirement Engineering Process includes four steps:

a) Feasibility Study

b) Software Requirement Specification

c) Requirement Gathering

d) Software Requirement Validation

a)     Feasibility study

When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software. Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards the goal of the organization. This study analyses whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project

And products such as usability, maintainability, and productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.

b)    Software Requirement Specification-

SRS is a document created by system analyst after the requirements are collected from various stakeholders. It defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from clients are written in natural language. It is the responsibility of the system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.

c)     Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

d)    Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in these documents are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not

Nipped in the bud.

Requirements can be checked against following conditions -

o Able to be practically implemented

o Should be valid and as per functionality and domain of software

o No ambiguities

o Must be complete

o Should be clearly demonstrated

Q. 3) How to write a SRS?

Ans: Writing a SRS

It is necessary to write an SRS text. It's not always easy to do, though.

To write an effective SRS text, here are five measures you can follow.

1. Create an outline (or use an SRS template)

Your first move is to build an outline specification for your programme specifications. This could be something that you yourself make. Or you can use an existing prototype with SRS.

Here's what your outline could look like if you're making this yourself:

1. Introduction

1.1 Purpose

1.2 Intended Audience

1.3 Intended Use

1.4 Scope

1.5 Definitions and Acronyms

2. Overall Description

2.1 User Needs

2.2 Assumptions and Dependencies

3. System Features and Requirements

        3.1 Functional Requirements

        3.2 External Interface Requirements

        3.3 System Features

        3.4 Nonfunctional Requirements

You're able to start filling it out once you have your clear outline.

2.     Start with a purpose

There is a very significant introduction to your SRS. This sets the target for the product you're creating.

So, start by defining your product's function.

Intended Audience and Intended Use

Define who will have access to the SRS in your company, and how they should use it. Developers, reviewers and project managers can be part of this. It may also include stakeholders, including leadership teams, distribution, and marketing in other departments.

Product scope

Describe the programme that is being defined. And they have advantages, priorities, and objectives. This should relate to overall business objectives, especially if the SRS will be accessed by teams outside of growth.

Definition and Acronyms

Including a risk concept is wise. For many developers, especially those working on security-critical development teams, avoiding risk is top-of-mind.

3.     Give an overview of what you’ll build

Your next move is to include a summary of what you will be constructing. Is it a product upgrade to an existing one? Is this an add-on to a product that you have already developed?

These are crucial to explain in advance, so everyone understands what you're creating.

You can also clarify why you are constructing it and who it is for.

User needs

User specifications, or user classes and features, are important. You'll need to define who and how the product will be used.

You'll have primary and secondary users who will frequently use the product. The needs of a separate buyer of the item (who may not be a primary/secondary user) may also need to be specified. And, if you're designing a medical device, for instance, you'll need to explain the needs of the patient.

Assumption and dependencies

There may be variables influencing the ability to meet the criteria specified in your SRS. What factors are those?

Are there any assumptions you're making that could turn out to be wrong with the SRS? You should have, as well, those here.

Finally, you should remember whether any external factors are depending on your project. This may involve software components from another project that you are reusing.

4.     Detail your specific requirement

For your development team, the next section is key. This is where the basic specifications for the construction of your product are detailed.

Functional requirement

To build your product, functional specifications are crucial.

These specifications may include an infusion and a battery if you are developing a medical device.And you may have a subset of risks and requirements under these functional requirements.

External interface requirement

External specifications for interfaces are types of functional requirements. For embedded systems, they're essential. And they outline how other components can interact with your product.

There are many types of interfaces for which you may have specifications, including:

●      User

●      Hardware

●      Software

●      Communications

System features

System characteristics are functional requirement types. In order for a system to operate, these are features that are needed.

Other non- functional requirements

Non-functional criteria may be just as relevant as those that are functional.

These include, among others:

●      Performance

●      Safety

●      Security

●      Quality

Depending on your business, the significance of this form of requirement can vary. Safety standards in the medical device industry, for instance, would be crucial.

5.     Get approval of an SRS

You'll need to have it approved by key stakeholders once you've completed the SRS. And the current edition of the document should be checked by all.

Q. 4) Write short notes on user and system requirement.

Ans: User requirement

Describe what the user does in the device, also referred to as user needs, such as what tasks that users must be able to perform. In a User Requirements Document (URD) using narrative text, user requirements are normally reported. In general, user specifications are signed off by the user and used as the key input to build device requirements.

In designing a software product, a significant and challenging step is to decide what the consumer really wants it to do. This is because the consumer is frequently unable to express their needs and desires in their entirety, and the data they provide can also be incomplete, unreliable and self-conflicting. The burden of thoroughly knowing what the client needs falls on the business analyst. This is why user demands are normally taken into account separately from device specifications.

The business analyst carefully analyses user requirements and carefully builds and records a set of high-quality system requirements to ensure that these quality characteristics are met by the requirements.

System requirements

The building blocks developers use to build the system are system specifications. These are the standard "shall" statements that define what the "shall do. System requirements of the system are categorized as either functional or additional requirements."

For instance, the entry and printing of cost estimates will involve a system; this is a practical requirement. All the remaining specifications not covered by the functional requirements are specified by supplementary or non-functional requirements. Instead of non-functional specifications, I prefer to use the word supplementary demands; who wants to be labelled non-functional? Supplementary specifications are often called requirements for service quality.

In the system design, the strategy for implementing functional specifications is comprehensive. In the system architecture, the plan for implementing supplementary specifications is comprehensive.

The following list indicates different kinds of supplementary specifications:

Q. 5) Explain prioritizing requirements (Kano diagram).

Ans: Prioritizing requirements (Kano diagram)

As a function of customer satisfaction, Kano analysis helps one to prioritize requirements. Kano specified four categories into which it is possible to classify each function or necessity.

1. Surprise and delight

Capabilities that distinguish a service from its competition (e.g the nav-wheel on an iPod)

2.     More is better

Dimensions with a simple path of increasing utility along a continuum (e.g. Battery life or song capacity)

3.     Must be

Functional barriers to entry: consumers would not use the product without these capabilities (e.g. UL approval)

4.     Better not be

Represents material that dissatisfies clients (e.g. Inability to increase song capacity via upgrades).

Surprise and delight requirement:

Think of software as a customer for just a moment, not an accountant. We want software that is interesting to use and enjoyable. User interface affordances that allow us to just "do what comes naturally" and make the programme do precisely what we want. Fresh innovations that render better apps. When we click it, we're not talking about a button that brings up dancing squirrels, we're talking about useful features that make great apps.

These may be the criteria behind the delightful characteristics described above.

●      When holding the iPod in one hand, users must be able to pick songs.

●      With the expectation that users would never delete emails, the system must have an easy way to organise emails.

●      The framework offers appropriate support information for the context in which the consumer seeks assistance.

More is better requirement:

These are the terms that are most readily understood: bigger, quicker, better, stronger. The difficulty in writing a better requirement is to know when sufficient is enough. "They would be ambiguous requirements if we were to write requirements that said "minimize" or "maximize. It would be entirely impractical if we were to unambiguously request that our developers minimize search time.

It can also be very difficult to define accurate targets. The decreasing returns law comes into play. In economics, there is a term called utility that reflects the tangible and intangible benefits of something. With respect to the target users, we may consider the usefulness of a function.

A graph of the search-result generation speed utility will look like the following:

We can see that the associated gain to the consumer of further changes in speed is decreased as the speed of results increases. To define the criterion, we have only defined the benefit side of the cost-benefit analysis required. We now have an idea of the cost of implementing search after getting feedback from our implementation team, as seen in the following graph.

As we see, making increasingly smaller speed changes is progressively becoming more costly. We need to find the point in the curves where the incremental advantage of searching faster is equivalent to the incremental expense of searching faster to decide the ideal specification.

As shown in the next figure, we can do that by graphing utility versus cost.

The circle displays the point where the curve's slope is equal to 1. An additional increase in speed offers less value at this point in the curve than the associated increase in cost.

Must be requirements

These are the criteria that when they talk about requirements, most people think about. These are the best specifications to evoke.

Stakeholders will typically tell us what the app needs them to have. Am I hot in our world or not? We see that 37 signals rely on this as their primary criteria for inclusion in an initial software release after prioritization of requirements. They prefer to place only critical specifications or 'must be' in the initial software update.

Better not to be requirement

No, this is just the opposite of surprise and delight. Then critics complain about what holds it back if dreamers think about what makes something great. In Kano's analysis, we don't think this bucket really has a place. "Saying "Users don't like complicated navigation" offers no advantage over saying "Users prefer intuitive navigation. We recommend that this category not be used at all.

Q. 6) What do you mean by requirement traceability matrix (RTM)?

Ans: Requirement traceability matrix

In the Requirement Traceability Matrix or RTM, we set up a process to record the relations between the client's suggested user specifications and the system being designed. In short, it is a high-level document that maps and traces user specifications with test cases to ensure that appropriate testing levels are accomplished with each and every requirement.

The method for evaluating all test cases specified for each requirement is called Traceability. Traceability helps us to assess which specifications have produced the most defects during the phase of testing.

Full test coverage is and should be the focus of every research interaction. It literally means, by coverage, that we need to test anything that needs to be tested. 100 percent test coverage should be the goal of every research project.

Requirements the Traceability Matrix offers a way to ensure that the coverage element is tested. It helps to define coverage gaps by providing a snapshot. In short, it can also be referred to as metrics that specify for each requirement the number of test cases run, passed, failed or blocked, etc.

Types of Traceability Matrix

Forward Traceability:

Requirements for test cases of 'Forward Traceability'. It guarantees that the project is moving according to the desired path and that every condition is thoroughly tested.

Backward Traceability:

With the 'Backward Traceability' criteria, the test cases are mapped. Its primary objective is to ensure that the new product being produced is on the right track. It also helps to decide that no additional undefined features are implemented and the project's scope is therefore affected.

Bi-Directional Traceability:

(Forward + Backward): A Strong Traceability matrix contains references to criteria from test cases and vice versa (requirements to test cases). This is referred to as Traceability 'Bi-Directional.'

Q. 7) What do you mean by UML diagram?

Ans: UML diagram

In the field of software engineering, UML stands for Unified Modeling Language, a structured general-purpose visual modelling language. It is used to define, visualize, build, and record the software system's primary objects. It helps to design and define, especially those software systems that implement the Object Orientation concept. It defines the operation of software as well as hardware systems.

The UML was developed by Rational Software's Grady Booch, Ivar Jacobson, and James Rumbaugh in 1994-95. In 1997, the Object Management Community adopted it as a standard (OMG).

The Object Management Group (OMG) is a multi-company organisation which controls the open standard UML. The OMG was set up in order to develop an open standard that facilitates the interoperability of object-oriented systems in particular.

It is not limited to borders, but can also be used to model non-software structures. The OMG is best recognized according to the specifications of the Generic Object Request Broker Architecture (CORBA).

Goals of UML:

●      Since it is a modelling language for general purposes, it can be used by all modelers.

●      Due to the absence of standard methods at that time, UML came into existence after the introduction of object-oriented principles to systemize and consolidate object-oriented development.

●      It can therefore be inferred that UML is a basic approach to modelling that is used to model all functional structures.

Characteristics of UML:

The UML has the following characteristics:

●      It is a generalized language for modelling.

●      It is different from programming languages such as C++, Python, etc.

●      Object-oriented research and architecture are inter-related.

●      It is used to simulate the system's workflow.

●      It is a pictorial language that is used to create powerful objects for modelling.

Q. 8) Describe data modeling.

Ans: Data Modeling

For a computer-based system, there are several different ways of looking at the specifications. Different representation types compel you to consider criteria from multiple points of view, an approach that is more likely to expose omissions, contradictions, and uncertainty.

1 scenario-based modeling

From the user's perspective, the system is represented using a Scenario-based methodology. Basic use cases and their accompanying use-case diagrams, for instance, develop into more elaborate use cases based on models.

The first component of the model that is developed is mostly scenario-based elements of the requirements model. Three stages of elaboration are shown, resulting in a representation based on scenarios.

2 class-based modeling

Each scenario of use involves a selection of artefacts that are manipulated as an actor communicates with the device. Such artefacts are grouped into groups, a group of items with similar characteristics and common behaviours.

3 Flow oriented modeling

As knowledge flows through a computer-based system, it converts. In a variety of forms, the machine receives input, applies functions to transform it, and generates output in a variety of forms.

A control signal transmitted by a transducer can be the input, a number series typed by a human operator, an information packet transmitted over a network connection, or a voluminous data file retrieved from secondary storage.

A single logical comparison, a complex numerical algorithm, or an expert system's rule-inference approach can comprise the transform(s).

Q. 9) Define Analysis model.

Ans: Analysis model

Analysis of requirements is an important and necessary task after elicitation. To render clear and unambiguous demands, we evaluate, refine, and scrutinize the collected specifications. All specifications are checked by this operation which can include a graphical view of the entire system. It is expected that the understandability of the project will substantially increase after the completion of the study.

Here, the dialogue with the client may also be used to illustrate points of misunderstanding and to understand which specifications are more relevant than others.

The different steps in the study of requirements are shown in Fig:

1. Draw the context diagram:

A basic model describing the boundaries and interfaces of the proposed structures with the external world is the context diagram. This describes the entities that communicate with the system outside the proposed system.

II.            Development of a Prototype (optional):

Constructing a prototype, something that looks and ideally works as part of the device they claim they want, is one successful way to find out what the consumer needs.

Until the user is consistently pleased, we will use their input to change the prototype. The prototype therefore allows the customer to imagine the device proposed and increase the understanding of requirements.

A prototype may help both parties to make a final decision if developers and users are not sure about some of the elements.

The prototype could be designed at a reasonably low cost and quickly. Therefore, in the final framework, it would still have drawbacks and would not be reasonable. This task is optional.

III.            Model the requirements:

Typically, this method consists of different graphical representations of the functions, data entities, external entities, and their relationships. It will help to find wrong, contradictory, incomplete, and superfluous criteria in the graphical view. The Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc., contain such models.

IV.            Finalize the requirements:

We will have a clearer understanding of the behaviour of the system after modelling the requirements. It has established and corrected the contradictions and ambiguities. The flow of information among different modules has been analyzed. The practices of elicitation and interpretation have provided greater insight into the scheme. The assessed requirements are now finalized, and the next step is to record these requirements in a specified format.

Q. 10) What do you mean by Requirement engineering?

Ans: Requirement engineering

Requirement engineering is the broad spectrum (variety, range) of tasks and techniques that lead to an understanding of requirements.

In other words, RE (requirement engineering) refers to the mechanism in which specifications are specified, recorded and preserved.

A major software engineering operation is from a requirement engineering that starts during the communication activity and continues into the modelling activity. It needs to be customized to the requirements of the process, the project, the product and the people doing the job.

Software Requirements are a set of conditions or a capability possessed by software or system components to solve a real-world problem. The problems can be to automate a part of a system to correct shortcomings of an existing system, to control

a device, and so on. IEEE defines a requirement as:

“A condition or capability needed by a user to solve a problem or achieve an objective” or “The capability possessed by a system to satisfy a contract, standard, specification, or other formally imposed documents”.

When users request for software, they possess an approximation of what the new system should be capable of doing. Requirements differ from one user to another user and from one business process to another business process. Reliability means Operational reliability.

It is described as the ability of a system or component to perform its required functions under static conditions for a specific period. It can also be described as the probability that a software system fulfils its assigned task in a given environment for a predefined number of input cases, assuming that the hardware and the input are free of error.

Software can be defined as a collection of programs, documentation and operating procedures. Institute of Electrical and Electronic Engineers (IEEE) defines software as “a collection of computer programs, procedures, rules, and associated documentation and data”.

It contains seven different activities -

❏      Inception

❏      Elicitation

❏      Elaboration

❏      Negotiation

❏      Specification

❏      Validation

❏      Management