Requirement

Engineering
 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.
 Requirement Engineering
Process
• It is a four-step process, which includes -
• Feasibility Study
• Requirement Elicitation and Analysis
• Software Requirement Specification
• Software Requirement Validation
• Software Requirement Management
 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.
 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
• Getting all, and only, the right people involved.
• Stakeholders often don't know what they want
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system
requirements.
 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.
• 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.
• 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.
• 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.
 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
• Requirements Validation Techniques
• Requirements reviews/inspections: systematic manual analysis of the requirements.
• Prototyping: Using an executable model of the system to check requirements.
• Test-case generation: Developing tests for requirements to check testability.
• Automated consistency analysis: checking for the consistency of structured
 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.
 Prerequisite of Software requirements
• Collection of software requirements is the basis of the entire software
development project. Hence they should be clear, correct, and well-defined.
• A complete Software Requirement Specifications should be:
• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Software Requirements: Largely software requirements must be categorized
into two categories:
• Functional Requirements: Functional requirements define a function that a
system or system element must be qualified to perform and must be
documented in different forms. The functional requirements are describing the
behavior of the system as it correlates to the system's functionality.
• Non-functional Requirements: This can be the necessities that specify the
criteria that can be used to decide the operation instead of specific behaviors
of the system.
Non-functional requirements are divided into two main categories:
• Execution qualities like security and usability, which are observable at run time.
• Evolution qualities like testability, maintainability, extensibility, and scalability that
embodied in the static structure of the software system.