Scribd
Upload
20 views7 pages

Unit2 Requirements Engg

requirement engineering

Uploaded by

mukundsinghkushwaha
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
20 views7 pages

Unit2 Requirements Engg

requirement engineering

Uploaded by

mukundsinghkushwaha
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/ 7

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.

Requirements analysis is very critical process that enables the success of a


system or software project to be assessed. Requirements are generally split
into two types: Functional and Non-functional requirements.
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.
• They are basically the requirements stated by the user which one can
see directly in the final product, unlike the non-functional requirements.
Non-functional requirements:
• 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
Following are the differences between Functional and Non Functional
Requirements
Functional Requirements Non Functional Requirements

A non-functional requirement defines


A functional requirement defines a
the quality attribute of a software
system or its component.
system.

It places constraints on “How should


It specifies “What should the
the software system fulfill the
software system do?”
functional requirements?”

Non-functional requirement is
Functional requirement is specified specified by technical peoples e.g.
by User. Architect, Technical leaders and
software developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the functionality of Helps you to verify the performance
the software. of the software.

Functional Testing like System, Non-Functional Testing like


Integration, End to End, API testing, Performance, Stress, Usability,
etc are done. Security testing, etc are done.

Usually easy to define. Usually more difficult to define.

Example Example
1) Authentication of user whenever 1) Emails should be sent with a
he/she logs into the system. latency of no greater than 12 hours
2) System shutdown in case of a from such an activity.
cyber attack. 2) The processing of each request
3) A Verification email is sent to should be done within 10 seconds
user whenever he/she registers for 3) The site should load in 3 seconds
the first time on some software when the number of simultaneous
system. users are > 10000
Requirement Engineering Process
It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

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:
1. Technical Feasibility - Technical feasibility evaluates the current technologies,
which are needed to accomplish customer requirements within the time and
budget.
2. Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and
customer requirements.
3. 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.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.


o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.
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.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling
the requirements. DFD shows the flow of data through a system. The system
may be a company, an organization, a set of procedures, a computer hardware
system, a software system, or any combination of the preceding. The DFD is also
known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements stage,
the data dictionary should at least define customer data items, to ensure that
the customer and developers use the same definition and terminologies.
o Entity-Relationship Diagrams: Another tool for requirement specification is
the entity-relationship diagram, often called an "E-R diagram." It is a detailed
logical representation of the data for the organization and uses three main
constructs i.e. data entities, relationships, and their associated attributes.

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 -

o If they can practically implement


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

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the


requirements.
o Prototyping: Using an executable model of the system to check requirements.
o Test-case generation: Developing tests for requirements to check testability.
o Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

Software Requirement Management:


Requirement management is the process of managing changing requirements during
the requirements engineering process and system development.

New requirements emerge during the process as business needs a change, and a
better understanding of the system is developed.

The priority of requirements from different viewpoints changes during development


process.
The business and technical environment of the system changes during the
development.

You might also like