Requirement Engineering

Requirement EngineeringRequirement EngineeringRequirement EngineeringRequirement Engineering

Saranya.VAP/CSE,

Sri Vidya College of Engineering & Technology,Virudhunagar

1.1 Requirement Engineering1.1 Requirement Engineering 1.1.1 Introduction 1.1.2 Understanding Requirements 1.1.3 Requirements Engineering 1.1.4 Ground Work Establishment

1.1.4.1 Stakeholders Identification 1.1.4.2 Multiple Viewpoints Recognition 1.1.4.3 Collaboration 1.1.4.4 Requirements Elicitation 1.1.4.5 Building Use Cases 1.1.4.6 Negotiating Requirements 1.1.4.7 Validating Requirements

Requirement Engineering ProcessRequirement Engineering ProcessRequirement Engineering ProcessRequirement Engineering Process

Helps software engineer to better understand Helps software engineer to better understand the problem.the problem.

Participants involved:Participants involved: Software Engineers Managers Customers Users



1.1.1 Introduction1.1.1 Introduction1.1.1 Introduction1.1.1 Introduction

Range from Range from High level abstract statement High level abstract statement from from Detailed Mathematical SpecificationsDetailed Mathematical Specifications..



1.1.2 Understanding 1.1.2 Understanding RequirementsRequirements1.1.2 Understanding 1.1.2 Understanding RequirementsRequirements

Collecting needs from the customer.Collecting needs from the customer. Managing the Process.Managing the Process. Tasks involved:Tasks involved:

Inception Elicitation Elaboration Negotiation Specification Validation Requirements Management

During inception, the During inception, the requirements asks a set of requirements asks a set of questions to establish:questions to establish: Basic understanding of the

problem. Nature of the solution that is

desired. Requirements Engineers needs Requirements Engineers needs

to Identify the stakeholders, to Identify the stakeholders, recognize multiple viewpoints, recognize multiple viewpoints, work toward collaboration and work toward collaboration and initiate the communication.initiate the communication.

Inception (Beginning)

Eliciting requirements is difficult because ofEliciting requirements is difficult because of Problems of scope Problems of scope identify the boundaries of identify the boundaries of

the system.the system. Problems of understanding Problems of understanding domain , computing domain , computing

environment.environment. Problems of Volatility Problems of Volatility requirements may change requirements may change

over time.over time.

Elicitation may be accomplished through two Elicitation may be accomplished through two activities:activities:

Collaborative Requirements Gathering Quality Function Deployment.

Elicitation: (Extraction)

Takes the information obtained Takes the information obtained during inception and elicitation.during inception and elicitation.

Focuses on developing a refined Focuses on developing a refined model of software functions, model of software functions, features & Constraints. features & Constraints.

This is an This is an analyzing phaseanalyzing phase.. It defines the functional, It defines the functional,

informational and behavioral informational and behavioral constraints of the problem constraints of the problem domain. domain.

Elaboration (explanation)

Software engineer Software engineer reconciles the conflicts reconciles the conflicts between what the between what the customer wants and customer wants and what can be achieved.what can be achieved.

Requirements are ranked Requirements are ranked by the customer, users by the customer, users and other stakeholdersand other stakeholders..

Risks associated with Risks associated with each requirement are each requirement are identified.identified.

Negotiation (Cooperation)

Final work product produced by Final work product produced by the requirements engineer.the requirements engineer.

Form of Form of SRSSRS.. Serves as a foundationServes as a foundation.. It It formalizes the functional and formalizes the functional and

behavioral requirementsbehavioral requirements of the of the proposed software in both the proposed software in both the graphical and textual format.graphical and textual format.

Specifications

Specification is examined to Specification is examined to ensure that all the sw ensure that all the sw requirements have been requirements have been stated unambiguously.stated unambiguously.

Errors have been detected Errors have been detected and corrected.and corrected.

Members involved:Members involved: Software Engineers Customers Users Other stakeholders.

Validation

Project team performs a set of activities to identify, Project team performs a set of activities to identify, control and track requirements and changes to the control and track requirements and changes to the requirements at any times as the project proceeds.requirements at any times as the project proceeds.

Each requirement is assigned a Each requirement is assigned a unique identifierunique identifier.. Place the requirements into one or traceability Place the requirements into one or traceability

tables.tables. Tables may be stored in a database Tables may be stored in a database that relate that relate

features, sources, dependencies subsystems and features, sources, dependencies subsystems and

interfaces to the requirementsinterfaces to the requirements. .

Requirements Management

Types of RequirementsTypes of RequirementsTypes of RequirementsTypes of Requirements

Customer RequirementsCustomer Requirements Define the expectations in terms of Mission

Objectives, Environment, Constraints and Measures of Effectiveness and Suitability. (MOE/MOS)

Functional Requirements Functional Requirements Explain what has to be done. Identify the necessary action or activity and

task. Used as the top level functions for functional

analysis.

Non functional Requirements:Non functional Requirements: Specify criteria that can be used to Specify criteria that can be used to judge judge

the operationthe operation of a system rather than of a system rather than behaviors.behaviors.

Performance Requirements:Performance Requirements: Examine which a mission or function must Examine which a mission or function must

be executed. be executed. Measured in terms of quality, quantity, Measured in terms of quality, quantity,

timeliness or readiness.timeliness or readiness.

Design Requirements:Design Requirements: Build to, Code to, buy to. Use technical data packages

and technical manuals.

Derived Requirements:Derived Requirements: Implied or transformed from

higher level requirement.

Allocated Requirement:Allocated Requirement: Higher level : 100 Lower level : 70 and 30

Those who are involving in requirement Analysis:Requirement EngineerSystem AnalystSystem EngineerProject LeaderSystem Engineer



1.1.3 Requirement 1.1.3 Requirement EngineeringEngineering1.1.3 Requirement 1.1.3 Requirement EngineeringEngineering

Feasibility StudyFeasibility Study Find out the current user needs. Budget

Requirement AnalysisRequirement Analysis What the stakeholders require from the system.

Requirements DefinitionRequirements Definition Define the requirements in a form understandable to

the customer.

Requirements SpecificationRequirements Specification Define the requirements in detail.

Requirements Document:Requirements Document: Official Statement Include both a definition and specification Specify external system behavior Specify implementation constraints. Easy to change

Problems of Requirements AnalysisProblems of Requirements Analysis Stakeholders don’t know what they really want Stakeholders express requirements in their own terms Requirement change during the analysis process.



1.1.4 Ground Work 1.1.4 Ground Work EstablishmentEstablishment1.1.4 Ground Work 1.1.4 Ground Work EstablishmentEstablishment

Ground Work for Requirement Analysis consist of

Identifying stakeholders, Recognizing viewpoints, Establishing collaboration among the stakeholders

through conducting conversions and questionnaire among the stakeholders.



1.1.4.1 Stakeholders 1.1.4.1 Stakeholders IdentificationIdentification1.1.4.1 Stakeholders 1.1.4.1 Stakeholders IdentificationIdentification

Stakeholder may be a project team member, employee of Stakeholder may be a project team member, employee of the user organization or a Senior Manager.the user organization or a Senior Manager.

Stakeholder analysis is a technique to identify and analysis Stakeholder analysis is a technique to identify and analysis the stakeholders project.the stakeholders project.

Provides information on stakeholders and their Provides information on stakeholders and their relationships, interests and their expectations.relationships, interests and their expectations.

Stakeholder expectations and Interests:Stakeholder expectations and Interests: ““Guess Work”Guess Work”

Approaches:Approaches: Using checklist Plotting people in small models.

Stakeholder influence and Role in Stakeholder influence and Role in the projectthe projectStakeholder influence and Role in Stakeholder influence and Role in the projectthe project

Be activeBe active InvolvementInvolvement Vested interest.Vested interest. Stakeholder Categories:Stakeholder Categories:

Project Manager Team Members Team Leads Project Resource Manager Senior Managers, Executives or Sponsors



1.1.4.2 Multiple Viewpoint 1.1.4.2 Multiple Viewpoint RecognitionRecognition1.1.4.2 Multiple Viewpoint 1.1.4.2 Multiple Viewpoint RecognitionRecognition

Marketing GroupMarketing Group is interested in functions is interested in functions and features (easy to sell)and features (easy to sell)

Support engineers Support engineers may focus on may focus on maintainability of the software.maintainability of the software.

Business managers Business managers are interested in a are interested in a feature that will be ready to meet defined feature that will be ready to meet defined market windows.market windows.



1.1.4.3 Collaboration1.1.4.3 Collaboration1.1.4.3 Collaboration1.1.4.3 Collaboration

Each stakeholders has Each stakeholders has different opinion different opinion about the set of about the set of requirements.requirements.

Requirement engineer Requirement engineer must identify areas of must identify areas of commonalitycommonality..

Identify the area of Identify the area of inconsistencyinconsistency..

Reduce dependencies Reduce dependencies among engineersamong engineers..



1.1.1.4 Requirement 1.1.1.4 Requirement ElicitationElicitation1.1.1.4 Requirement 1.1.1.4 Requirement ElicitationElicitation

Discovering the requirement for the system.Discovering the requirement for the system. Identify the requirements by communicating with the customers, system Identify the requirements by communicating with the customers, system

users and other.users and other.

Requirements sources:Requirements sources: Domain Knowledge Stakeholders Operational Environment Organizational Environment.

Elicitation Techniques:Elicitation Techniques: Interviews Scenarios Facilitated Meeting Prototypes Observation



1.1.4.5 Building Use 1.1.4.5 Building Use CasesCases1.1.4.5 Building Use 1.1.4.5 Building Use CasesCases

Use cases Use cases describe the interactions describe the interactions between a user and a systembetween a user and a system..

Focusing on What the system Focusing on What the system DOESDOES for the for the user.user.

Describe the Describe the totality of the system totality of the system and and behavior of the system.behavior of the system.

Includes:Includes: Actors List Use case packages Use case diagrams Use case text Use case views.

Activities involved in use Activities involved in use casescasesActivities involved in use Activities involved in use casescases

Find actors Find actors Project Manager Architect End-users Customers Development Team

Find use casesFind use cases Describe the use case. Describe the use case.

Steps for developing use case Steps for developing use case diagramdiagramSteps for developing use case Steps for developing use case diagramdiagram

1.1. Use abstract ideaUse abstract idea

2.2. Define use case actorsDefine use case actors

3.3. Define use case actor goalsDefine use case actor goals

4.4. Identify reuse opportunity for use caseIdentify reuse opportunity for use case

5.5. Create use case indexCreate use case index

6.6. Identify the key componentsIdentify the key components

7.7. Name and briefly describe the use case.Name and briefly describe the use case.

8.8. Create use case basic viewCreate use case basic view

9.9. Create use case alternate flowsCreate use case alternate flows

10.10. Produce the use case documentProduce the use case document

11.11. Generate a use case model diagram. Generate a use case model diagram.

Sample Use case DiagramSample Use case DiagramSample Use case DiagramSample Use case Diagram

1.1.4.6 Negotiating Requirements 1.1.4.6 Negotiating Requirements (RN)(RN)1.1.4.6 Negotiating Requirements 1.1.4.6 Negotiating Requirements (RN)(RN)

Effective practices:Effective practices: Get the right stakeholder Establish team work mentality Plan team iteration Use Group Support System(GSS) Establish shared vocabulary Maintain list of requirements Record requirement attributes Manage by probabilities Select base decisions Select operational approach Plan more Re-plan before every release Find workable solution Provide training in the negotiation process Use trained facilitator Consider requirement, architecture and market place. Leverage the triple constraint (Cost Vs Time Vs Scope)

1.1.4.7 Validating 1.1.4.7 Validating RequirementsRequirements1.1.4.7 Validating 1.1.4.7 Validating RequirementsRequirements

Requirement ReviewsRequirement Reviews Prototyping (Model) Prototyping (Model) Model ValidationModel Validation Acceptance TestsAcceptance Tests

Education

Requirement Engineering