Phases of Requirement Engineering

Phases of Requirement Engineering:

These phases are part of the requirement engineering (not necessary one by one – they do overlap):

Eliciation (gathering requirement from Stakeholders)

Requirement Management

Analysis & Negotiation

(Technical documentation, check management)

(checking for consistency and completeness)

Verification & Validiation (making sure the specified requirements are correct and are doing correctly)

Phases of Requirement Engineering

Documentation (requirements and their analyses are committed to some formal media)

Trusted by over 1 million members

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.







Requirement Elicitation;

Requirements Requirements elicitation is the process that identifies the sources of requirements for a new system and after identifying it obtains requirements from those sources. Requirements elicitation is a crucial part of the Requirements Engineering. Requirements elicitation is a very challenging activity that requires focus and skill from the business analyst. For Requirement Elicitation, a business analyst need to have knowledge of Domain, Regulation, Standards and other constrains. If a business analyst doesn‟t have prior knowledge then quality of requirement will suffer.

There are three types of requirement elicitations:

1. Greenfield Engineering: In this type of Requirement Elicitation, a new system is build. No Prior system exists so requirements are extracted from Client and End User. This type of engineering is dependent on User needs.

2. Re-Engineering: In this type of requirement elicitation, an existing system is redesign and re-implemented using a newer technology. This type of engineering is technology oriented.

3. Interface Engineering: In this type of requirement elicitation, system and functionally of system remains

but environment is modified.

This type of







In requirement Elicitation the following activities are performed:

* Identify actors * Identify scenarios * Identify use cases * Identify relationships among use cases * Refine use cases * Identify nonfunctional requirements * Identify participating objects

For performing the above stated activities different Requirement Elicitation Techniques are being used. Some of requirement elicitation techniques are:

1. Brainstorming: Brainstorming sessions are used to let the stakeholders come up with creative ideas or new approaches to a problem. 2. Workshops: Workshops are facilitated meetings with multiple stakeholders. 3. Interviewing: Interviews are one-on-one meetings where the business analyst asks questions to get information from the stakeholders about their needs and expectations. 4. Surveys: Surveys are used to gather information anonymously from the







6. Prototyping: This is the use of partially finished versions of the software that have been created to help validate requirements. Most of the time a prototype contains no or less functionality. 7. Focus Groups: Focus Groups are group interviews with potential and/or actual users where the business analyst raises issues and questions to obtain information from the stakeholders. 8. Observation: Observation is when the business analyst watches the users performing their daily tasks and asks questions about the tasks and work. This technique gives you the advantage of actually seeing what the users do.







Requirement Analysis and Negotiation:

Requirement Analysis is a process in which different requirement are analyzed in terms of cost. In this process, dependencies among different requirement are identified. Moreover requirement analysis is an initial step which helps in identifying how the application integrates with the business processes. In requirement analysis scope and limitations of software application are finalized. Requirement Negotiation is a process starts with identification all the stakeholders. Aim of requirement negotiation is to resolve conflicts between different requirements. In this process all requirements are discussed discussed with different different stakeholder and acceptance creation for every requirement is set and every requirement is prioritized.

Requirement Analysis and Negotiation is important for many reasons. Some of the reasons are given below:

Avoiding (Scope, Cost, Schedule) Creeps: In Software Project Management terms a creep is regarded as an uncontrolled change. This uncontrolled change can have imparts on project scope, project cost and project schedule. As a result, a software project can drift away from target cost, target schedule and target scope. In most of the case, (scope, cost and schedule) creeps occur because of unrealistic requirements. So for avoiding these creeps Requirement Analysis and Negotiations is very important. With the help of proper requirement analysis and negotiation, needs of all stakeholders can







Better Understanding of requirements: Reason behind most software project failures is unrealistic or poor requirements. Unrealistic and poor requirements always lead to a fail software product because every building needs proper bases if bases are weak then quality of building will suffer as well. Similarly for understanding the needs and requirements of all the users, we need to spend time on requirement analysis and negotiation.

Avoiding Conflicts (between stakeholders): It is a common observation that within an organization different stakeholders have different/conflicting requirements. Requirement Analysis Analysis and negotiation provides solution solution to this problem as well. In the process of requirement analysis and negotiation, requirements are prioritize and for conflicting requirement alternative ways are identified.

Understanding Customer Needs: Software is considered as a successful product if it satisfies the needs of customer (end user). Software can only satisfy customer needs when development and design team are aware with actual customer needs. For a healthy design and development process, requirements are negotiated with all the stakeholders. In this way, all the stakeholders get involved in requirement engineering process and it becomes easy to understand the need of all stakeholders.

Avoiding Ambiguous Requirements: When Requirements are gathered from requirement elicitation phase, it is possible that some ambiguous requirements may emerge along real requirements. For avoiding such requirements it is important to









Many difficulties and problem emerge during the process of requirement analysis and negotiation. Some of the problems are: 

Confused Stakeholder



Difference of Expression



Conflicting Requirements Requirements



Organizational and Political Factors



Change of Environment







Requirement Documentation: Documentation:

In this phase, all negotiated and analyzed requirements are documented. For having a better understanding of requirements, a document is used. This document is known as different names like Requirement Document, System‟s Requirement Specifications. This Requirement Document Document plays critical role in software development. Apparently it seems that requirement document is only used by the system developers and Engineers. But in reality almost all the stakeholders are concerned with the requirement document. In the rest of this post, we will see that who is concerned with requirement document and what are the concerns of different stakeholders with requirement document. The figure given below tells us who is concerned with the requirement document:

System Customer

System managers

Requirement Documentation

System Maintanance Engineers







2. Requirement Document must give the details about the constraints under which system will operate. 3. Requirement Requirement Document must provide the definition of other systems with which the system is expected to integrate. 4. Requirement Document must provide information about the application domain of the system. 5. Requirement Document must provide the knowledge of constraints on the process used to develop the system.

According to IEEE standard Requirement Document a requirement document must contain the following chapters: 1. Introduction 2. General description 3. Specific Requirements 4. Appendices







Requirement Validation and Verification:

The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e. Verification is a process that makes it sure that the software product is developed the right way. The software should confirm to its predefined specifications, as the product development goes through different stages, an analysis is done to ensure that all required specifications are met.

Methods and techniques used in the Verification and Validation shall be designed carefully, the planning of which starts right from the beginning of the development process. The Verification part of „Verification and Validation Model‟ comes before Validation, which incorporates Software inspections, reviews, audits, walkthroughs, buddy checks etc. in each phase of verification (every phase of Verification is a phase of the Testing Life Cycle)

During the Verification, the work product (the ready part of the Software being developed and various documentations) is reviewed/examined personally by one or more persons in order to find and point out the defects in it. This process helps in







the end of the development process in order to determine whether the product satisfies specified requirements.

Validation and Verification processes go hand in hand, but visibly Validation process starts after Verification process ends (after coding of the product ends). Each Verification activity (such as Requirement Specification Verification, Functional design Verification etc.) has its corresponding Validation activity (such as Functional Validation/Testing, Code Validation/Testing, System/Integration Validation etc.).

All types of testing methods are basically carried out during the Validation process. Test plan, test suits and test cases are developed, which are used during the various phases of Validation process. The phases involved in Validation process are: Code Validation/Testing, Integration Validation/Integration Testing, Functional Validation/Functional Testing, and System/User Acceptance Testing/Validation.

Three components of verification: 

Inspections









Requirement Management:

In Software Development new requirements emerge and existing requirements change during all the stages of SDLC (Software Development Life Cycle). It has been observed that in most of the software projects more than 50% of system‟s requirement change or modify before the system is deployed. This astonishing figure of 50% can cause serious problems during system development and it may also have negative impact on the quality of software system. On the basis of these facts, system developers and Managers want to minimize these negative impacts to maintain the quality of software system. To minimize these negative impacts, a process is needed for documenting the changes and controlling the effects of changes. The name of needed process is “Requirement Management”. Requirement Management is a process where changes in requirements are







• Supplementary specification • Creating test cases from use cases • Creating test cases from the supplementary specification • System design

Phases of Requirement Engineering

Recommend Documents