software engineering unit 3-requirements engineering processes

1/24/20091/24/2009 S.Sreenivasa RaoS.Sreenivasa Rao 11

33rdrd UnitUnitRequirements Engineering Requirements Engineering

ProcessesProcesses


ObjectivesObjectives To describe the principal requirements To describe the principal requirements

engineering activities and their relationshipsengineering activities and their relationships To introduce techniques for requirements To introduce techniques for requirements

elicitation and analysiselicitation and analysis To describe requirements validation and the To describe requirements validation and the

role of requirements reviewsrole of requirements reviews To discuss the role of requirements To discuss the role of requirements

management in support of other management in support of other requirements engineering processesrequirements engineering processes


Topics coveredTopics covered Feasibility studiesFeasibility studies Requirements elicitation and analysisRequirements elicitation and analysis Requirements validationRequirements validation Requirements managementRequirements management


Requirements engineering Requirements engineering processesprocesses

The processes used for RE vary widely The processes used for RE vary widely depending on the application domain, the depending on the application domain, the people involved and the organisation people involved and the organisation developing the requirements.developing the requirements. However, there are a number of generic However, there are a number of generic

activities common to all processesactivities common to all processes Requirements elicitation;Requirements elicitation; Requirements analysis;Requirements analysis; Requirements validation;Requirements validation; Requirements management.Requirements management.


The requirements engineering processThe requirements engineering process


Requirements engineeringRequirements engineering


Feasibility studiesFeasibility studies

A feasibility study decides whether or not A feasibility study decides whether or not the proposed system is worthwhile.the proposed system is worthwhile. A short focused study that checksA short focused study that checks

If the system contributes to organisational If the system contributes to organisational objectives;objectives;

If the system can be engineered using current If the system can be engineered using current technology and within budget;technology and within budget;

If the system can be integrated with other If the system can be integrated with other systems that are used.systems that are used.


Feasibility study implementationFeasibility study implementation

Based on information assessment (what is Based on information assessment (what is required), information collection and report writing.required), information collection and report writing. Questions for people in the organisationQuestions for people in the organisation

What if the system wasnWhat if the system wasnt implemented?t implemented? What are current process problems?What are current process problems? How will the proposed system help?How will the proposed system help? What will be the integration problems?What will be the integration problems? Is new technology needed? What skills?Is new technology needed? What skills? What facilities must be supported by the proposed What facilities must be supported by the proposed

system?system?


Requirement Elicitation and analysisRequirement Elicitation and analysis Sometimes called requirements elicitation or Sometimes called requirements elicitation or

requirements discovery.requirements discovery. Involves technical staff working with customers to Involves technical staff working with customers to

find out about the application domain, the services find out about the application domain, the services that the system should provide and the systemthat the system should provide and the systems s operational constraints.operational constraints. May involve endMay involve end--users, managers, engineers users, managers, engineers

involved in maintenance, domain experts, trade involved in maintenance, domain experts, trade unions, etc. These are called unions, etc. These are called stakeholders.stakeholders.


Problems of requirements Problems of requirements analysisanalysis

Stakeholders donStakeholders dont know what they really want.t know what they really want. Stakeholders express requirements in their own Stakeholders express requirements in their own

terms.terms. Different stakeholders may have conflicting Different stakeholders may have conflicting

requirements.requirements. Organisational and political factors may influence Organisational and political factors may influence

the system requirements.the system requirements. The requirements change during the analysis The requirements change during the analysis

process. New stakeholders may emerge and the process. New stakeholders may emerge and the business environment change.business environment change.


The requirements spiralThe requirements spiral


Process activitiesProcess activities Requirements discoveryRequirements discovery

Interacting with stakeholders to discover their Interacting with stakeholders to discover their requirements. Domain requirements are also discovered requirements. Domain requirements are also discovered at this stage.at this stage.

Requirements classification and organisationRequirements classification and organisation Groups related requirements and organises them into Groups related requirements and organises them into

coherent clusters.coherent clusters. Prioritisation and negotiationPrioritisation and negotiation

Prioritising requirements and resolving requirements Prioritising requirements and resolving requirements conflicts.conflicts.

Requirements documentationRequirements documentation Requirements are documented and input into the next Requirements are documented and input into the next

round of the spiral.round of the spiral.


Requirements discoveryRequirements discovery

The process of gathering information about The process of gathering information about the proposed and existing systems and the proposed and existing systems and distilling the user and system requirements distilling the user and system requirements from this information.from this information. Sources of information include Sources of information include

documentation, system stakeholders and documentation, system stakeholders and the specifications of similar systems.the specifications of similar systems.


ATM stakeholdersATM stakeholders Bank customersBank customers Representatives of other banksRepresentatives of other banks Bank managersBank managers Counter staffCounter staff Database administrators Database administrators Security managersSecurity managers Marketing departmentMarketing department Hardware and software maintenance engineersHardware and software maintenance engineers Banking regulatorsBanking regulators


ViewpointsViewpoints Viewpoints are a way of structuring the Viewpoints are a way of structuring the

requirements to represent the perspectives requirements to represent the perspectives of different stakeholders. Stakeholders may of different stakeholders. Stakeholders may be classified under different viewpoints.be classified under different viewpoints. This multiThis multi--perspective analysis is important perspective analysis is important

as there is no single correct way to analyse as there is no single correct way to analyse system requirements.system requirements.


Types of viewpointTypes of viewpoint Interactor viewpointsInteractor viewpoints

People or other systems that interact directly with the People or other systems that interact directly with the system. In an ATM, the customersystem. In an ATM, the customers and the account s and the account database are interactor VPs.database are interactor VPs.

Indirect viewpointsIndirect viewpoints Stakeholders who do not use the system themselves Stakeholders who do not use the system themselves

but who influence the requirements. In an ATM, but who influence the requirements. In an ATM, management and security staff are indirect viewpoints.management and security staff are indirect viewpoints.

Domain viewpointsDomain viewpoints Domain characteristics and constraints that influence Domain characteristics and constraints that influence

the requirements. In an ATM, an example would be the requirements. In an ATM, an example would be standards for interstandards for inter--bank communications.bank communications.


Viewpoint identificationViewpoint identification

Identify viewpoints usingIdentify viewpoints using Providers and receivers of system services;Providers and receivers of system services; Systems that interact directly with the system Systems that interact directly with the system

being specified;being specified; Regulations and standards;Regulations and standards; Sources of business and nonSources of business and non--functional functional

requirements.requirements. Engineers who have to develop and maintain Engineers who have to develop and maintain

the system;the system; Marketing and other business viewpoints.Marketing and other business viewpoints.


LIBSYS viewpoint hierarchyLIBSYS viewpoint hierarchy


InterviewingInterviewing

In formal or informal interviewing, the RE In formal or informal interviewing, the RE team puts questions to stakeholders about team puts questions to stakeholders about the system that they use and the system to the system that they use and the system to be developed.be developed. There are two types of interviewThere are two types of interview

Closed interviews where a preClosed interviews where a pre--defined set of defined set of questions are answered.questions are answered.

Open interviews where there is no preOpen interviews where there is no pre--defined defined agenda and a range of issues are explored with agenda and a range of issues are explored with stakeholders.stakeholders.


Interviews in practiceInterviews in practice

Normally a mix of closed and openNormally a mix of closed and open--ended ended interviewing.interviewing. Interviews are good for getting an overall Interviews are good for getting an overall

understanding of what stakeholders do and how understanding of what stakeholders do and how they might interact with the system.they might interact with the system. Interviews are not good for understanding domain Interviews are not good for understanding domain

requirementsrequirements Requirements engineers cannot understand specific Requirements engineers cannot understand specific

domain terminology;domain terminology; Some domain knowledge is so familiar that people find it Some domain knowledge is so familiar that people find it

hard to articulate or think that it isnhard to articulate or think that it isnt worth articulating.t worth articulating.


Effective interviewersEffective interviewers

Interviewers should be openInterviewers should be open--minded, willing minded, willing to listen to stakeholders and should not to listen to stakeholders and should not have prehave pre--conceived ideas about the conceived ideas about the requirements.requirements. They should prompt the interviewee with a They should prompt the interviewee with a

question or a proposal and should not question or a proposal and should not simply expect them to respond to a question simply expect them to respond to a question such as such as what do you wantwhat do you want. .


Requirements validationRequirements validation Concerned with demonstrating that the Concerned with demonstrating that the

requirements define the system that the requirements define the system that the customer really wants.customer really wants. Requirements error costs are high so Requirements error costs are high so

validation is very importantvalidation is very important Fixing a requirements error after delivery may Fixing a requirements error after delivery may

cost up to 100 times the cost of fixing an cost up to 100 times the cost of fixing an implementation error.implementation error.


Requirements checkingRequirements checking ValidityValidity. Does the system provide the functions . Does the system provide the functions

which best support the customerwhich best support the customers needs?s needs? ConsistencyConsistency. Are there any requirements . Are there any requirements

conflicts?conflicts? CompletenessCompleteness. Are all functions required by the . Are all functions required by the

customer included?customer included? RealismRealism. Can the requirements be implemented . Can the requirements be implemented

given available budget and technologygiven available budget and technology VerifiabilityVerifiability. Can the requirements be checked?. Can the requirements be checked?


Requirements validation Requirements validation techniquestechniques

Requirements reviewsRequirements reviews Systematic manual analysis of the Systematic manual analysis of the

requirements.requirements. PrototypingPrototyping

Using an executable model of the system to Using an executable model of the system to check requirements. Covered in Chapter 17.check requirements. Covered in Chapter 17.

TestTest--case generationcase generation Developing tests for requirements to check Developing tests for requirements to check

testability.testability.


Requirements reviewsRequirements reviews Regular reviews should be held while the Regular reviews should be held while the

requirements definition is being formulated.requirements definition is being formulated. Both client and contractor staff should be Both client and contractor staff should be

involved in reviews.involved in reviews. Reviews may be formal (with completed Reviews may be formal (with completed

documents) or informal. Good documents) or informal. Good communications between developers, communications between developers, customers and users can resolve problems customers and users can resolve problems at an early stage.at an early stage.


Review checksReview checks VerifiabilityVerifiability. Is the requirement realistically . Is the requirement realistically

testable?testable? ComprehensibilityComprehensibility. Is the requirement . Is the requirement

properly understood?properly understood? TraceabilityTraceability. Is the origin of the requirement . Is the origin of the requirement

clearly stated?clearly stated? AdaptabilityAdaptability. Can the requirement be . Can the requirement be

changed without a large impact on other changed without a large impact on other requirements?requirements?


Requirements managementRequirements management

Requirements management is the process of Requirements management is the process of managing changing requirements during the managing changing requirements during the requirements engineering process and system requirements engineering process and system development.development. Requirements are inevitably incomplete and Requirements are inevitably incomplete and

inconsistentinconsistent New requirements emerge during the process as New requirements emerge during the process as

business needs change and a better understanding of business needs change and a better understanding of the system is developed;the system is developed;

Different viewpoints have different requirements and Different viewpoints have different requirements and these are often contradictory.these are often contradictory.


Requirements changeRequirements change

The priority of requirements from different The priority of requirements from different viewpoints changes during the development viewpoints changes during the development process.process. System customers may specify System customers may specify

requirements from a business perspective requirements from a business perspective that conflict with endthat conflict with end--user requirements.user requirements. The business and technical environment of The business and technical environment of

the system changes during its development.the system changes during its development.


Requirements evolutionRequirements evolution


Requirements classificationRequirements classification

RequirementType

Description

Mutablerequirements

Requirements that change because of changes to the environment in which theorganisation is operating. For example, in hospital systems, the funding of patientcare may change and thus require different treatment information to be collected.

Emergentrequirements

Requirements that emerge as the customer's understanding of the system developsduring the system development. The design process may reveal new emergentrequirements.

Consequentialrequirements

Requirements that result from the introduction of the computer system. Introducingthe computer system may change the organisations processes and open up new waysof working which generate new system requirements

Compatibilityrequirements

Requirements that depend on the particular systems or b usiness processes within anorganisation. As these change, the compatibility requirements on the commissionedor delivered system may also have to evolve.


Requirements management Requirements management planningplanning

During the requirements engineering process, you During the requirements engineering process, you have to plan:have to plan: Requirements identificationRequirements identification How requirements are individually identified;How requirements are individually identified;

A change management processA change management process The process followed when analysing a requirements change;The process followed when analysing a requirements change;

Traceability policiesTraceability policies The amount of information about requirements relationships that The amount of information about requirements relationships that

is maintained;is maintained; CASE tool supportCASE tool support The tool support required to help manage requirements change;The tool support required to help manage requirements change;


TraceabilityTraceability

Traceability is concerned with the relationships Traceability is concerned with the relationships between requirements, their sources and the between requirements, their sources and the system designsystem design Source traceabilitySource traceability

Links from requirements to stakeholders who proposed Links from requirements to stakeholders who proposed these requirements;these requirements;

Requirements traceabilityRequirements traceability Links between dependent requirements;Links between dependent requirements;

Design traceabilityDesign traceability Links from the requirements to the design;Links from the requirements to the design;


A traceability matrixA traceability matrix

Req.id

1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 D R1.2 D D D1.3 R R2.1 R D D2.2 D2.3 R D3.1 R3.2 R


CASE tool supportCASE tool support

Requirements storageRequirements storage Requirements should be managed in a secure, Requirements should be managed in a secure,

managed data store.managed data store.

Change managementChange management The process of change management is a workflow The process of change management is a workflow

process whose stages can be defined and information process whose stages can be defined and information flow between these stages partially automated.flow between these stages partially automated.

Traceability managementTraceability management Automated retrieval of the links between requirements.Automated retrieval of the links between requirements.


Requirements change managementRequirements change management

Should apply to all proposed changes to the Should apply to all proposed changes to the requirements.requirements. Principal stagesPrincipal stages

Problem analysis. Discuss requirements Problem analysis. Discuss requirements problem and propose change;problem and propose change;

Change analysis and costing. Assess effects of Change analysis and costing. Assess effects of change on other requirements;change on other requirements;

Change implementation. Modify requirements Change implementation. Modify requirements document and other documents to reflect document and other documents to reflect change.change.


Change managementChange management

3rd UnitRequirements Engineering ProcessesObjectivesTopics coveredRequirements engineering processesThe requirements engineering processRequirements engineeringFeasibility studiesFeasibility study implementationRequirement Elicitation and analysisProblems of requirements analysisThe requirements spiralProcess activitiesRequirements discoveryATM stakeholdersViewpointsTypes of viewpointViewpoint identificationLIBSYS viewpoint hierarchyInterviewingInterviews in practiceEffective interviewersRequirements validationRequirements checkingRequirements validation techniquesRequirements reviewsReview checksRequirements managementRequirements changeRequirements evolutionRequirements classificationRequirements management planningTraceabilityA traceability matrixCASE tool supportRequirements change managementChange management

software engineering unit 3-requirements engineering processes

Documents