REQUIREMENT ENGINEERING:

Requirements Engineering is a set of activities concerned with identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used. Hence, Requirement Engineering acts as the bridge between the realworld needs of users, customers, and other constituencies affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies.

Requirements engineering is the discipline concerned with understanding the externally imposed conditions on a proposed computer system, determining what capabilities will meet these imposed conditions and documenting those capabilities as the software requirements for the computer system. Requirements solicitation, analysis, and management are key elements of a successful and safe development process for any system. Many costly and critical system failures can ultimately be traced back to missing, incorrect, misunderstood, or incompatible requirements. Requirements are statements of need that define what a system will do and how well it must perform those tasks. At lower levels of the system, such as for a complex electronic device, the requirements will include specifics on what the device must do (and how well), how the device will interface to other parts of the system, and what part the device will play in overarching requirements, such as safety. Systems are usually conceptualized as having levels of structure. The highest level defines the interface between the system and the outside world. The system itself is a black box at this level. Requirements for this level describe how the users (people or other systems) will interact with the system, and what the system will do in response to those inputs. Constraints that are imposed on the system from outside entities,

including the environment the system must operate in, also influence the requirements specification. Once the system is conceptually broken up into a set of interacting elements, the process of requirements decomposition (or derivation) begins. Some of the higher-level requirements will be implemented in whole by a particular element. Other requirements will be partitioned between several components. The process of requirements decomposition continues as the system is further sub-divided, until the lowest practical level is reached. The stopping point for requirement decomposition will vary across systems. For systems with complex electronic devices, a separate requirements document for the complex electronics is preferred. In reality, only the most critical devices have requirements separate from a higher-level assembly. Requirements can also be classified by the role they play in the system. This classification will vary, depending on the organization or project. The following list of requirements types is commonly used in many government organizations.

Functional requirements describe the capabilities of the product or system (what the system must do).

Performance requirements describe how well the product or system must perform a function. Performance requirements complement the functional requirements, and these are sometimes combined into single requirements.

Interface requirements specify how the system will interact or interoperate with an adjacent system.

Safety, Quality, Reliability, Maintainability, etc. (the ilities) this set of requirements relate to overarching system questions, such as how long will it work without breaking and can it hurt me. Some ility requirements can be decomposed into specific functional and performance requirements. Others essentially put constraints on the design, implementation, manufacturing, or production processes.

Constraint requirements are a limitation that a product or system must stay within.

Requirement:

A requirement is "a singular documented need of what a particular product or service should be or do". Systems may have from dozens to hundreds of requirements. A collection of requirements then defines the characteristics of the desired (required) system, but does not say how the system should implement those requirements. In other words, it imposes constraints on the delivered system that are important to the customers or other stakeholders, while leaving most design and implementation decisions to the discretion of the developer. A golden rule of requirements writing is that all requirements must be verifiable. This means it must be possible to decide whether a requirement is satisfied without recourse to subjective opinion. If this is not the case, then the offending requirements should be altered or dropped. A common example is where the customer states that the application (or perhaps particular features, such as a database search) must be fast. When stated so plainly, this is not verifiable as one person's interpretation of 'fast' is different to anothers. Better is to make a statement such as 'Under typical usage, 90% of search requests must terminate within 10 seconds'. This puts hard numbers onto the performance requirement, and by working with a set of users to establish what 'typical usage' really means, it is possible to test whether this requirement has been satisfied.

Requirements are typically classified into three categories: * Functional Requirements - describe system features or things the system must do. * Non-Functional Requirements - describe properties the system must have (e.g. performance, availability, accessibility). * Constraints - limits the development in some way. Such as, defining an operating system the system must run on, or defining which programming language must be used to implement the system.

Expert users often play a key role in eliciting the requirements. They can provide a necessary link between the user base and the software developers, because they understand the problems of the users and are able to identify necessary functionality of the required system. However, the project development team should not assume that all users are like their expert user. Most users want simplicity in the user interface, whereas expert users sometimes ask for complex functionality that is not needed by most users. This can extend the duration of the project unnecessarily or lead to a userinterface that is too complicated to use for common tasks.

Good requirements have the following attributes:

Necessary: it.

The product/system cannot meet the real needs of the user without

Unambiguous: If a requirement has multiple interpretations, the system that is built may not match what the user wanted. Clarity is very important.

Comprehensible: Requirements are to be understood by all stakeholders. Complete: It is impossible to know all of a system's future requirements, but all of the known ones should be specified.

Correct: According to stakeholders intention. Consistent: Requirements must not conflict with each other. Checkable: Requirements can be used to generate tests on the final software. Traceable: The source of each requirement should be identified. Verifiable: Each requirement must be able to be verified by test, analysis, inspection, or demonstration. Avoid negative requirements where possible. Example - The component shall not overheat.

Importance of Requirements Engineering

Software engineering projects are all too often undertaken without a good understanding of the needs or wants of the client, or their problem domain. Developers lapse into making design decisions too early and without an understanding of all the constraints on the system to be developed. As a consequence unnecessary and (more typically) incorrect assumptions are built into the system and the result is all too often a system which fails to meet customers expectations! There are many issues that can have a negative impact on software development projects and products if practitioners dont do a good job of defining their software requirements. These issues include: Incomplete requirements Lack of user involvement Requirements churn Wasted resources Gold plating Inaccurate estimates If the requirements are incomplete, software practitioners end up building a software product that does not meet all of the customer and users needs. The customer will be dissatisfied (and go buy a car somewhere else) if their explicit requirements are not met. The customers satisfaction increases as more of their explicit requirements are met. When enough of their explicit requirements are met, the customer shifts from being dissatisfied with the product to being a satisfied customer. There is a basic level of quality requirements that a customer expects the product to have. These are requirements that are assumed by the customer and are typically not

explicitly stated. The entire basic line is in the dissatisfaction region. Absence of this level of quality requirements will increase a customers dissatisfaction. Exciting quality is the innovative requirements level and represents unexpected items. These are items that customers do not even know they want, but they love them when they see them. For example, remember when cup holders in cars were first introduced? Note that the entire excited quality line is in the satisfied region. It should be remembered, however, that todays innovations are tomorrows expectations. The expected quality requirements are the ones practitioners can elicit fairly easily if they talk to the products stakeholders. However, it is easy to miss both the basic and exciting quality requirements if they do not do a thorough job of detailed requirements elicitation and analysis. In addition, if practitioners miss a stakeholder group or if they do not get the users involved in the requirements process, they can end up with gaps even in their expected requirements. Requirements churn refers to changes in the requirements after they are initially agreed to and base lined. Some of this change is a part of refining developers understanding as they develop the software. Changes also occur because of changes in the environment or the users needs over time that occurs as a natural part of a project of any significant duration. If requirements are poorly defined, however, requirements churn occurs because of missing requirements that should have been included in the original specification or because of poorly written or ambiguous requirements. These are the types of requirements churn that good requirement engineering practices will help avoid. The requirements define the scope of the products that are being developed. Without a clear picture of that scope, estimates of the project schedule, cost, and quality will be less accurate.

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
(Technical documentation, check management)

Analysis & Negotiation

Phases of Requirement Engineering

(checking for consistency and completeness)

Verification & Validiation

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

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

Requirement Elicitation;

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 doesnt 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 same but environment is modified. engineering is dependent on new market needs. 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 stakeholders. This elicitation technique is good when stakeholders are too many. 5. Documentation Review: This is the process of obtaining requirements from written documentation such as manuals.

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 with 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 be identified and prioritize at the start of project.

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 and negotiation provides 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 analyze every requirement.

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 Organizational and Political Factors Change of Environment

Requirement 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, Systems Requirement Specifications. This Requirement 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

System Engineers

System Test Engineers

A good requirement document should describe the following: 1. Requirement Document should explain the services and functions that the system is expected to perform. 2. Requirement Document must give the details about the constraints under which system will operate.

3. 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 5. Index

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 prevention of potential bugs, which may cause in failure of the project.

Validation is a process of finding out if the product being built is right? i.e.
whatever the software product is being developed, it should do what the user expects it to do. The software product should functionally do what it is supposed to, it should satisfy all the functional requirements set by the user. Validation is done during or at 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 Metrics Configuration management

Three components of validation: Testing Metrics Quality assurance teams

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 systems 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 documented and controlled. Requirement management involves many sub activities; we will discuss all the activities which are involved in requirement management. The first activity involved in process of requirement management is categorizing the requirements. A simplified description of the requirements management process contains the following major steps: Establishing a requirements management plan Requirements elicitation Developing the Vision document Creating use cases Supplementary specification Creating test cases from use cases Creating test cases from the supplementary specification System design.