Requirement Process
Requirement Process
CAP 314
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 Process
• 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.
Models used in SRS
• Data Flow Diagrams
• Data Dictionaries
• Entity-Relationship Diagrams
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.
• 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 requirements descriptions.
Software Requirement Management