Scribd
Upload
31 views31 pages

Requirements Engineering: Prof. Akila Victor

The document discusses requirements engineering (RE), which refers to the process of defining, documenting, and maintaining requirements in the engineering design process. It outlines the key aspects of RE including the objective to discover, analyze, and validate system requirements. The types of requirements are defined as functional requirements, which are basic system facilities, and non-functional requirements, which are quality constraints. The RE process involves requirements elicitation, analysis, validation, and management to capture stakeholder needs.

Uploaded by

Sukriti Jaitly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
31 views31 pages

Requirements Engineering: Prof. Akila Victor

The document discusses requirements engineering (RE), which refers to the process of defining, documenting, and maintaining requirements in the engineering design process. It outlines the key aspects of RE including the objective to discover, analyze, and validate system requirements. The types of requirements are defined as functional requirements, which are basic system facilities, and non-functional requirements, which are quality constraints. The RE process involves requirements elicitation, analysis, validation, and management to capture stakeholder needs.

Uploaded by

Sukriti Jaitly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

Requirements Engineering

Prof. Akila Victor


Agenda
• Objective
• Definition
• Types of Requirements
• Requirement Engineering Process
• View Points
Objective
• Processes used to discover, analyse and
validate system requirements
Definition
• Requirements engineering (RE) refers to
the process of defining, documenting and maintaining
requirements in the engineering design process.

• Requirement
– A requirement is a specification of a need or want. Sets
of requirements are used to capture the information
needed to design, build and test a process, service, product
or system.
RE Process Model
Types of Requirements
• Functional
• Non-Functional
• Domain
Functional Requirements
• These are the requirements that the end user
specifically demands as basic facilities that the
system should offer.

• All these functionalities need to be necessarily


incorporated into the system as a part of the contract.

• These are represented or stated in the form of input


to be given to the system, the operation performed
and the output expected.
Non-Functional
• These are basically the quality constraints that the system must
satisfy according to the project contract. The priority or extent to
which these factors are implemented varies from one project to
other. They are also called non-behavioral requirements.
They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Cont…
Cont…
Requirements engineering processes

• The processes used for RE vary widely depending


on the application domain, the people involved
and the organisation developing the requirements
• However, there are a number of generic activities
common to all processes
– Requirements elicitation
– Requirements analysis
– Requirements validation
– Requirements management
The requirements engineering process
Feasibility studies
• A feasibility study decides whether or not the
proposed system is worthwhile
• A short focused study that checks
– If the system contributes to organisational
objectives
– If the system can be engineered using current
technology and within budget
– If the system can be integrated with other systems
that are used
Feasibility study implementation
• Based on information assessment (what is
required), information collection and report
writing
• Questions for people in the organisation
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed
system?
Elicitation and analysis
• Sometimes called requirements elicitation or
requirements discovery
• Involves technical staff working with customers
to find out about the application domain, the
services that the system should provide and the
system’s operational constraints
• May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders
Cont…
Problems of requirements analysis
• Stakeholders don’t know what they really want
• Stakeholders express requirements in their own
terms
• Different stakeholders may have conflicting
requirements
• Organisational and political factors may influence
the system requirements
• The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change
Process activities
• Domain understanding
• Requirements collection
• Classification
• Conflict resolution
• Prioritisation
• Requirements checking
Viewpoints
• Viewpoints are a way of structuring the
requirements to represent the perspectives of
different stakeholders. Stakeholders may be
classified under different viewpoints.
• This multi-perspective analysis is important as
there is no single correct way to analyse
system requirements.
Types of viewpoint
• Interactor viewpoints
– People or other systems that interact directly with the
system. In an ATM, the customer’s and the account
database are interactor VPs.
• Indirect viewpoints
– Stakeholders who do not use the system themselves but
who influence the requirements. In an ATM, management
and security staff are indirect viewpoints.
• Domain viewpoints
– Domain characteristics and constraints that influence the
requirements. In an ATM, an example would be standards
for inter-bank communications.
Viewpoint identification
• Identify viewpoints using
– Providers and receivers of system services;
– Systems that interact directly with the system
being specified;
– Regulations and standards;
– Sources of business and non-functional
requirements.
– Engineers who have to develop and maintain the
system;
– Marketing and other business viewpoints.
LIBSYS viewpoint hierarchy
All VPs

Indirect Interactor Domain

Library Article Library UI Classification


Finance Users
manager providers staff standards system

System
Students Staff External Cataloguers
managers
Interviewing
• In formal or informal interviewing, the RE
team puts questions to stakeholders about the
system that they use and the system to be
developed.
• There are two types of interview
– Closed interviews where a pre-defined set of
questions are answered.
– Open interviews where there is no pre-defined
agenda and a range of issues are explored with
stakeholders.
Scenarios
• Scenarios are real-life examples of how a
system can be used.
• They should include
– A description of the starting situation;
– A description of the normal flow of events;
– A description of what can go wrong;
– Information about other concurrent activities;
– A description of the state when the scenario
finishes.
Requirements validation techniques
• Requirements reviews
– Systematic manual analysis of the requirements
• Prototyping
– Using an executable model of the system to check
requirements. Covered in Chapter 8
• Test-case generation
– Developing tests for requirements to check testability
• Automated consistency analysis
– Checking the consistency of a structured requirements
description
Requirements reviews
• Regular reviews should be held while the
requirements definition is being formulated
• Both client and contractor staff should be
involved in reviews
• Reviews may be formal (with completed
documents) or informal. Good
communications between developers,
customers and users can resolve problems at
an early stage
Review checks
• Verifiability. Is the requirement realistically
testable?
• Comprehensibility. Is the requirement properly
understood?
• Traceability. Is the origin of the requirement
clearly stated?
• Adaptability. Can the requirement be changed
without a large impact on other requirements?
Requirements management
• Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development
• Requirements are inevitably incomplete and
inconsistent
– New requirements emerge during the process as
business needs change and a better understanding of
the system is developed
– Different viewpoints have different requirements and
these are often contradictory
Requirements change
• The priority of requirements from different
viewpoints changes during the development
process
• System customers may specify requirements
from a business perspective that conflict with
end-user requirements
• The business and technical environment of the
system changes during its development
Requirements evolution
References
• https://www.geeksforgeeks.org/functional-vs-
non-functional-requirements/

• https://www.javatpoint.com/software-
engineering-requirement-engineering.

• Ian sommervillie.

You might also like