FSIPD

MODULE-2

Requirements Engineering

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 1
Requirement Engineering

Definition of Requirement It is a statement that identifies a necessary attribute, capability,

characteristic, or quality of a system for it to have value and utility to a customer, organization,

internal user, or other stakeholder. A condition or capability needed by a user to solve a

problem or achieve an objective.

A specification (often abbreviated as spec) may refer to an explicit set of requirements to be

satisfied by a material, design, product, or service

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 2
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 3
Requirements can be said to relate to two fields:

• Product requirements prescribe properties of a system or product.

• Process requirements prescribe activities to be performed by the developing organization.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 4
 Samsung Galaxy S10 Full Specifications
Basic Requirements- • General. Brand. Samsung. Model. ...
Smartphone • Display. Screen size (inches) 6.10.
Touchscreen. ...
• Operating system.
• Hardware. Processor. 1.9GHz octa-core. ...
• Processor. • Camera. Rear camera. 12-megapixel (f/1.5) +
• Battery. 12-megapixel (f/2.4) + 16-megapixel (f/2.2) ...
• Software. Operating system. Android 9.0. ...
• Camera.
• Connectivity. Wi-Fi. Yes. ...
• Storage. • Sensors. Face unlock. Yes.
• Display.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 5
Characteristics of requirements

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 6
Stakeholder:

The stakeholder is defined as someone who is affected by the system that is being developed.

The two main types of stakeholders are

• Users - Users are people who will be using the system and

• Customers- Customers are the people who request the system and are responsible for

approving it. Usually customers pay for the development of the system.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 7
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 8
Internal stakeholders

Internal stakeholders are people who are already in that particular line of business or the organization.

These are people who already serve the organization, for example, staff, board members or volunteers.

External stakeholders

External stakeholders are stakeholders outside the organization, but those who have an impact on the

organization, such as the community or the organization's clients

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 9
Requirement Pyramid

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 10
• Stakeholder need: a requirement from a stakeholder

• Feature: a service provided by the system, usually formulated by a business analyst; a purpose of a

feature is to fulfill a stakeholder need

• Use case: a description of system behavior in terms of sequences of actions

• Supplementary requirement: another requirement (usually non-functional) that cannot be captured in

use cases

• Test case: a specification of test inputs, execution conditions, and expected results

• Scenario: a specific sequence of actions; a specific path through a use case

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 11
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 12
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 13
ACTIVITY

[Link] an use case diagram for Railway Train E-Ticket booking system

[Link] an use case diagram for Online Food Ordering system

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 14
Activity: -

Identify a product from the market and prepare a write up on the requirements and
specifications of the product.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 15
Types of Requirements

• Functional
• Performance
• Physical
• Regulatory
• Economical
• Behavioral
• Technical
• Stakeholder
• Environmental
• Industry specific

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 16
Functional Requirement:

They are also called as solution requirements.

It contains detailed statements of the behaviour and information that the solution will need

For any design problem, the first task is to identify the functional requirements (FRs) of the product,

i.e. the requirements pertaining to what the product will have to do.

FRs focuses on the operational features of products

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 17
Functional Requirement:

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 18
Performance Requirements:

The product performance requirements represent the minimum performance requirements for

products.

It defines How, When and How Much the product or service needs to perform.

They are also called Quality-of-service or non-functional requirement

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 19
Physical Requirements:

The physical requirements or constraints on the system may include:

• Physical size- size of the product should be compact but it should satisfies all the needs •

Geometries

• Power consumption

• Physical robustness- The ability of a system to resist change without adapting its initial stable

configuration. For example, the ability of a computer system to cope with errors during execution

or the ability of an algorithm to continue to operate despite abnormalities in input, calculations.

• Overall weight- The weight of car should be light and should be strong enough to sustain any

type of stress.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 20
Regulatory Requirements:

Regulation may refer a process of the monitoring, and enforcement of rules, established by primary

or delegated legislation.

It is a written instrument containing rules having the force of law.

Safety/Reliability: Direct or indirect hazards should be eliminated during the usage of products for the

safety of workers or users. It should contain human warnings.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 21
Regulation can take many forms:

• Legal restrictions,

• Certification e.g. ISO 9001:2000

• Accreditation or market regulation

• Social regulation e.g. OSHA

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 22
Economical Requirements

Economic means "pertaining to the production and use of income," and economical is "avoiding

waste, being careful of resources.” Therefore Economical is “using the minimum of time or resources

necessary for effectiveness.”

Various parameters for economical requirements of a product are: • Cost of labour • Cost of raw

material • Manufacturing cost • Cost of the labour required to deliver a service to a customer. • Selling

price of service or product • Maintenance cost

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 23
Technical Requirements

Technical Requirements are based on the technology used to make the product or service.

A technical requirement pertains to the technical aspects that your system must fulfil, such as

performance-related, reliability etc.

A technical specification (often abbreviated as spec) is an explicit set of technical requirements to be

satisfied by a product, or service

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 24
Behavioral Requirements

Behavioral requirements explain what has to be done by identifying the necessary behaviour of a

system.

These are requirements that specify “the reactive behaviour of the host”.

They are expressed in scenarios where upon due to some internal or external event, certain reaction is

expected (or) prohibited

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 25
Behavioral Requirements

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 26
Stakeholder Requirements

Stakeholder requirements represent the views of users, acquirers, and customers

Various stakeholder requirements are as follows are

• Service or functional • Operational • Interface • Environmental

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 27
Environmental requirements

The basic environmental requirements of any product are • Think green • Buy green • Be green

Environmental requirements typically list all of the major statutes with appropriate records

addressing environmental, health or safety issues by any governmental authority

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 28
Industry-specific requirements

Industry-specific requirements are the requirements that are pertained or related to a specific industry.

Controls, regulations, laws etc. can be industry specific requirements. For example, aviation, nuclear

energy etc. demand higher safety related rules.

Factories Act, 1948 • Employees Provident Fund & Miscellaneous Provisions Act, 1952 • Employees’

State Insurance Act • Payment of Wages Act, 1936 • Minimum Wages Act, 1948 • The Indian

Partnership Act, 1932 • The Income Tax Act, 1911 • Pollution Control Act

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 29
Process of Requirement engineering

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 30
Feasibility Study:

A feasibility study decides whether the proposed system is worthwhile or not.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 31
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 32
CONTEXT DIAGRAM

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 33
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 34
Requirement analysis

The field requirement analysis is composed of requirement inception and requirement elicitation.

Requirement Inception:

During inception, the following set of questions to be asked by a requirement engineer to

establish a basic understanding of the problem

• The people who want a solution

• The nature of the solution that is desired

• The effectiveness of preliminary communication and collaboration between the customer and

the developer

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 35
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 36
Collaborative requirement gathering:

The following guidelines are followed for requirement gathering

• Conducting meetings and attended by both engineers, customers, and other interested stakeholders

• Establishment of rules for preparation and participation

• Suggestion of an agenda that cover all important points but informal enough to encourage the free
flow of ideas

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 37
Quality Function Deployment:

This is a technique that translates the needs of the customer into technical requirements for
product.
• Normal requirements: These requirements are the objectives and goals stated for a product
or system during meetings with the customer
• Expected requirements: These requirements are implicit to the product or system and may
be so fundamental that the customer does not explicitly state them Requirement Elicitation
Collaborative requirement gathering
• Exciting requirements: These requirements are for features that go beyond the customer's
expectations and prove to be very satisfying when present

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 38
Requirement elaboration:

During elaboration, the engineer takes the information obtained during inception and elicitation and

begins to expand and refine it. Elaboration focuses on developing a refined technical model of

software functions, features, and constraints. It is an analysis modelling task • Development of use

cases • Identification of domain classes along with their attributes and relationships • Capture the life

on an object by state machine diagram

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 39
Requirement Specification:

A specification is the final work product produced by the requirements engineer.

It serves as the foundation for subsequent engineering activities.

It describes the function and performance of a computer-based system and the constraints that will
govern its development.

It formalizes the informational, functional, and behavioural requirements of the proposed software in
both a graphical and textual form

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 40
Requirement Validation

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 41
Requirement Management:

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing

on requirements and then controlling changes and communicating to relevant stakeholders and to

maintain traceability of requirements. • Each requirement is assigned a unique identifier • The

requirements are then placed into one or more traceability tables • These tables may be stored in a

database that relate features, sources, dependencies, subsystems, and interfaces to the requirements •

A requirements traceability table is also placed at the end of the requirements specification

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 42
Requirement Management:

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 43
Voice of the Customer:

Voice of the customer (VOC) is a term used to describe the in-depth process of capturing a customer's

expectations, preferences and aversions. Specifically, the Voice of the Customer is a market research

technique that produces a detailed set of customer wants and needs, organized into a hierarchical

structure, and then prioritized in terms of relative importance and satisfaction with current alternatives

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 44
Types of customer needs:

• Direct Needs: Customers have no trouble declaring these needs. Ex: Cost, Good mileage

• Latent Needs: Not directly expressed by customers without probing. Ex: Smooth ride, Good

exterior and interior design, and High efficiency

• Constant Needs: These needs are essential to the task of the product and always will be. When

product is used, this need is always there. Ex: Less consumption of fuel, Spacious

• Niche Needs: Apply only to a smaller market segment within the entire population. Ex: In-built

mp3 and video players, bullet proof glasses, Rear axle camera

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 45
Quality Function Deployment (QFD):

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 46
Requirement Traceability:

• The ability to describe and follow the life of a requirement, in both forward and backward directions.
• The ability to define, capture and follow the traces left by requirements on other elements of the
product development process and the traces left by those elements on requirements.

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 47
Traceability Matrix and Analysis:

A traceability matrix is a document, usually in the form of a table that correlates any two base lined
documents that require a many-to-many relationship to determine the completeness of the relationship.

It is often used with high-level requirements (these often consist of marketing requirements) and detailed
requirements of the product to the matching parts of high-level design, detailed design, test plan, and test
cases.

The Requirements Traceability Matrix (RTM) is a classical tool that summarizes in a table form the
traceability from original identified stakeholder needs to their associated product requirements and then
on to other work product elements

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 48
Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 49
Problem Statement:-

Authenticating user while performing ATM transaction .

Approved by AICTE |Affiliated to VTU | Recognized by UGC with 2(f) & 12(B) status |Accredited by 50