0% found this document useful (0 votes)
41 views3 pages

Requirement Engineering

Requirement engineering is the process of defining, documenting, and maintaining requirements throughout the engineering design process. It involves understanding customer needs, analyzing feasibility, negotiating solutions, clearly specifying solutions, validating specifications, and managing requirements as the system is developed. There are different types of requirements including user requirements, system requirements, functional requirements, and non-functional requirements. The requirement engineering process involves feasibility studies, eliciting and analyzing requirements, creating software requirement specifications, and validating requirements. Requirements elicitation and analysis specifically includes discovering requirements from stakeholders, classifying and organizing requirements, prioritizing and negotiating requirements, and documenting requirements.

Uploaded by

trs smriti
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
0% found this document useful (0 votes)
41 views3 pages

Requirement Engineering

Requirement engineering is the process of defining, documenting, and maintaining requirements throughout the engineering design process. It involves understanding customer needs, analyzing feasibility, negotiating solutions, clearly specifying solutions, validating specifications, and managing requirements as the system is developed. There are different types of requirements including user requirements, system requirements, functional requirements, and non-functional requirements. The requirement engineering process involves feasibility studies, eliciting and analyzing requirements, creating software requirement specifications, and validating requirements. Requirements elicitation and analysis specifically includes discovering requirements from stakeholders, classifying and organizing requirements, prioritizing and negotiating requirements, and documenting requirements.

Uploaded by

trs smriti
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/ 3

Requirement Engineering

Requirements engineering ( RE ) refers to the process of defining, documenting, and maintaining


requirements in the engineering design process. Requirement engineering provides the appropriate
mechanism to understand
● what the customer desires,
● analyzing the need,
● and assessing feasibility,
● negotiating a reasonable solution,
● specifying the solution clearly, validating the specifications
● and managing the requirements
● as they are transformed into a working system. Thus, requirement engineering is the
disciplined application of proven principles, methods, tools, and notation to describe a
proposed system's intended behavior and its associated constraints.

Types of Requirement
UserRequirements
User requirements are statements, in a natural language plus diagrams, of what services the system
is expected to provide and the constraints under which it must operate.
SystemRequirements
System requirements set out the system's functions, services and operational constraints in detail.
The system requirements document (sometimes called a functional specification) should be
precise. It should define exactly what is to be implemented. It may be part of the contract between
the system buyer and the software developers.(what,how?)

TypesOfSystemRe
1. Functional requirements These are statements of services the system should provide, how the
system should! react to particular inputs and how the system should behave in particular sinlations.
In sOMie cases, the functional requirements may also explicitly state what the system should not do.

2. Non:functional requirements Thesc;: are constraints on the services or functions offered by the
system. They include tim~ng constraints, constraints on the development process and standards.
Non-funcltional requireme,nts often apply to the system as a whole. They do not usually just apply to
individual system features or services.

TypesOfNonfunctionalRequirements
The types of non-functional requirements are:
ProductRequrements These requirements specify product behaviour.
Examples include performance requirements on how fast the system must execute and how much
memory it requires; reliability requirements that set out the acceptable failure rate; portability
requirements; and usability requirements.

OrganisationalRequirements These requirements are derived from policies and procedures in the
customer s and developer s organisation. Examples include process standards that must be used;
implementation requirements such as the programming language or design method usedl; and
delivery requirements that spedfy when the product and :Its documentation are to be delivered.

ExternalRequirements This broad heading covers all requirements that are derived from factors
external to the system and its development process. These may include interoperability
requirements that define how the system interacts with systems in other organisations: legislative
requirements that must be followed to ensure that the system operates within the law; and ethical
requirements. Ethical requirements are requirements placed on a system to ensure that it will be
acceptable
to its users and the general public.

RequirementEngineeringProcess
It is a four-step process, which includes -
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to established standards.
Types of Feasibility:
Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.
Operational Feasibility - Operational feasibility assesses the range in which the required software
performs a series of levels to solve business problems and customer requirements.
Economic Feasibility - Economic feasibility decides whether the necessary software can generate
financial profits for an organization.

2. Requirement Elicitation and Analysis:


This is also known as the gathering of requirements. Here, requirements are identified with the help
of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships
and also resolve conflicts if any.

3. Software Requirement Specification:


Software requirement specification is a kind of document which is created by a software analyst
after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

4. Software Requirement Validation:


After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the needs.
Requirements can be the check against the following conditions -

If they can practically implement


If they are correct and as per the functionality and specially of software
If there are any ambiguities
If they are full
If they can describe

RequirementsElicitationAndAnalysis
The process activities are:
1. Requirements discovery This is the process of interacting with stakeholders in the system to
collect their requirements. Domain requin:ments from stakeholders and documentation are also
discovered during this activity.
2. Requirements classijication and organisation This activity takes the unstructured collection of
requirements, groups related requirements and organises them into coherent clusters.
3. Requirements prioritisation and negotiation Inevitably, where multiple stakeholders are involved,
requirements will conflict. This a,ctivity is concerned with requirements, and finding and resolving
requirements conflicts through negotiation.
4. Requirements documentation The requirements are documented and input into the next round of
the spiral. Formal or informal requirements documents may be produced.

You might also like