re role scope2 sinvolvement elictechnique

8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique

1/77

REQUIREMENTS ENGINEERING PROCESS

vROLE OF THE PROFESSIONAL FOR

REQUIREMENTS

ENGINEERING

vCHARACTERISTICS OF REQUIREMENTS

ENGINEERING


2/77

Role of the Professional for RequirementsEngineering

Gathering Client business requirementsGathering Client business requirements

The information received from clients may include:The information received from clients may include:

Business needs or objectivesBusiness needs or objectives Mission objectivesMission objectives Functional requirementsFunctional requirements NonNon--functional requirementsfunctional requirements Application requirements, including reporting requirementsApplication requirements, including reporting requirements

System constraints, operation and performance requirementsSystem constraints, operation and performance requirements System architecture requirementsSystem architecture requirements System verification requirementsSystem verification requirements


3/77

Role of the Professional for Requirements

EngineeringGathering Client business requirementsGathering Client business requirements

The information received from clients may include:The information received from clients may include:

Solution focus areas, application scope, and system boundarySolution focus areas, application scope, and system boundary

Business process requirementsBusiness process requirements External interface requirementsExternal interface requirements Usability requirementsUsability requirements Estimates of volume and growthEstimates of volume and growth CostCost

Data RequirementsData Requirements Modularity, Flexibility, Location, LanguageModularity, Flexibility, Location, Language


4/77


EngineeringGathering Client business requirementsGathering Client business requirements

The needs of stakeholders (such as clients, end users, suppliers,The needs of stakeholders (such as clients, end users, suppliers,

builders, and testers) are thebuilders, and testers) are the basis for determining client businessbasis for determining client business

requirementsrequirements. Frequently, these needs are. Frequently, these needs are poorly identifiedpoorly identified ororconflictingconflicting..

The needs, expectations, constraints, interfaces, operationalThe needs, expectations, constraints, interfaces, operationalconcepts, and product concepts must be identified, analyzed,concepts, and product concepts must be identified, analyzed,

harmonized, refined, and elaborated for translation into a set of clientharmonized, refined, and elaborated for translation into a set of client

business requirements.business requirements.

Needs must be understood and translated intoNeeds must be understood and translated intoa more specific set of qualitative or quantitative client businessa more specific set of qualitative or quantitative client business

requirements. An understanding of the client business requirements byrequirements. An understanding of the client business requirements by

both your organization and the client is critical to build and deliver whatboth your organization and the client is critical to build and deliver what

the client desiresthe client desires


5/77


EngineeringClient business requirements differ from system requirements and can beClient business requirements differ from system requirements and can be

identified by the followingidentified by the following characteristicscharacteristics::

They support a business scope or objective (or both), usually reviewed byThey support a business scope or objective (or both), usually reviewed byexecutivesexecutives

They have a business purpose and focusThey have a business purpose and focus They state "what" needs to be accomplished using business languageThey state "what" needs to be accomplished using business language They are nonThey are non--technicaltechnical


6/77


Key questions to ask when reviewing business requirementsKey questions to ask when reviewing business requirements:: What am I solving with this business requirement?What am I solving with this business requirement? Is this business requirement feasible?Is this business requirement feasible? What scope or objective (or both) is this business requirement addressing?What scope or objective (or both) is this business requirement addressing? What is the acceptance criterion for this business requirement?What is the acceptance criterion for this business requirement?

How do I measure the acceptance criteria?How do I measure the acceptance criteria?

For example, a business requirement may be:For example, a business requirement may be:

The system shall support sales to individuals, small businesses, and largeThe system shall support sales to individuals, small businesses, and largeenterprises.enterprises.

The system shall support the above sales in all geographies worldwide.The system shall support the above sales in all geographies worldwide. The system shall respond to the buyer in less than 6 seconds for allThe system shall respond to the buyer in less than 6 seconds for all

combinations of buyers, up to a maximum of 1000 buyers.combinations of buyers, up to a maximum of 1000 buyers.


7/77


Stakeholder ManagementStakeholder Management Stakeholders may affect or be affected by the project's outcome or process,Stakeholders may affect or be affected by the project's outcome or process,

and may include:and may include:

-- Active stakeholders (such as systems, databases, organizations andActive stakeholders (such as systems, databases, organizations andindividuals) that will actively interact with the systemindividuals) that will actively interact with the system

-- Passive stakeholders (such as organizations, individuals, standards,Passive stakeholders (such as organizations, individuals, standards,

protocols, regulations, and internal and external guidelines) that will impactprotocols, regulations, and internal and external guidelines) that will impactthe overall success of deployed solutionsthe overall success of deployed solutions


8/77


Perform Technical Performance Measurements (TPM)Perform Technical Performance Measurements (TPM)

The technical performance measurement (TPM) activity is a key feature inThe technical performance measurement (TPM) activity is a key feature in

project risk reduction. TPMs track design and development progress towardsproject risk reduction. TPMs track design and development progress towards

meeting client requirements and expectations. TPMs are critical systemmeeting client requirements and expectations. TPMs are critical system

technical parameters that are tracked throughout the project's life cycle totechnical parameters that are tracked throughout the project's life cycle toenable the project team to focus on meeting the key client requirements.enable the project team to focus on meeting the key client requirements.


9/77



In defining and tracking the project's TPMs, the team will:In defining and tracking the project's TPMs, the team will:

Identify the TPMs, which are the few critical system parameters:Identify the TPMs, which are the few critical system parameters: FunctionalFunctional -- Capabilities that must be providedCapabilities that must be provided

NonfunctionalNonfunctional -- Throughput, Network or Data Latency, Data Integrity,Throughput, Network or Data Latency, Data Integrity,Security, Availability, User or Data Volumes, User or System ResponseSecurity, Availability, User or Data Volumes, User or System ResponseTime, Recovery TimesTime, Recovery Times

Establish interim milestones to assess progress in meeting the TPMsEstablish interim milestones to assess progress in meeting the TPMs Validate design and key assumptionsValidate design and key assumptions


10/77



In defining and tracking the project's TPMs, the team will:In defining and tracking the project's TPMs, the team will:

Consider alternativesConsider alternatives Define decision points for the alternativesDefine decision points for the alternatives

Develop engineering metrics that can be measured or estimated periodicallyDevelop engineering metrics that can be measured or estimated periodicallyduring the design and development processduring the design and development process Trace the TPMs to the client, system, and component requirementsTrace the TPMs to the client, system, and component requirements Trace the TPMs to the designTrace the TPMs to the design Trace the TPMs to the test cases and acceptance criteriaTrace the TPMs to the test cases and acceptance criteria Feed TPM risks to the project's risk management activities.Feed TPM risks to the project's risk management activities.


11/77


Define Requirement Traceability:Define Requirement Traceability:Requirements traceability is defined as the ability to describe and follow the lifeRequirements traceability is defined as the ability to describe and follow the life

of a requirement through life cycle phases in both a forward and backwardof a requirement through life cycle phases in both a forward and backward

direction. Each system requirement must be fully implemented by the defineddirection. Each system requirement must be fully implemented by the defined

set of component requirements. The component requirements must beset of component requirements. The component requirements must be

traceable to and from the system requirements, which are in turn traceable totraceable to and from the system requirements, which are in turn traceable toand from the client requirements. Acceptance criteria for the requirements areand from the client requirements. Acceptance criteria for the requirements are

documented and will eventually be used as a system measurement during thedocumented and will eventually be used as a system measurement during the

Test Phase. To trace these requirements to their documentation and buildTest Phase. To trace these requirements to their documentation and build

components, those affected elements are also recorded. During testing, testcomponents, those affected elements are also recorded. During testing, test

cases and test results are documented and will eventually bring the traceabilitycases and test results are documented and will eventually bring the traceability

to its completion. Vertical traceability must also be established to show howto its completion. Vertical traceability must also be established to show how

requirements are implemented across interfaces.requirements are implemented across interfaces.


12/77


Define Requirement Traceability:Define Requirement Traceability:During the Solution Design and Solution Outline Phases of a project, projectDuring the Solution Design and Solution Outline Phases of a project, project

participants gather client business requirements. These requirements consist ofparticipants gather client business requirements. These requirements consist of

business processes and technical requirements. They are translated into systembusiness processes and technical requirements. They are translated into system

requirements that must be verified and traced back to the client businessrequirements that must be verified and traced back to the client business

requirements. When system requirements are identified, their acceptancerequirements. When system requirements are identified, their acceptancecriteria are determined, and will be used as a system measurement during thecriteria are determined, and will be used as a system measurement during the

Test Phase.Test Phase.


13/77


Define Requirement Traceability:Define Requirement Traceability:During the Macro Design Phase of a project, system requirements are furtherDuring the Macro Design Phase of a project, system requirements are further

defined into component requirements. Component requirements must bedefined into component requirements. Component requirements must be

verified and traced back to system requirements (just as the systemverified and traced back to system requirements (just as the system

requirements were verified and traced back to the client businessrequirements were verified and traced back to the client business

requirements). When component requirements are identified, their acceptancerequirements). When component requirements are identified, their acceptancecriteria are determined, and will be used as a system measurement during thecriteria are determined, and will be used as a system measurement during the

Test Phase. Component requirements are system requirements allocated to aTest Phase. Component requirements are system requirements allocated to a

component (for example, a software or hardware component of a systemcomponent (for example, a software or hardware component of a system

requirement, or requirement allocated to a particular application). This level ofrequirement, or requirement allocated to a particular application). This level of

detail may be combined with the system requirements documents or may notdetail may be combined with the system requirements documents or may not

be necessary for small or less complex projects (Refer to Section 5 Tailoring).be necessary for small or less complex projects (Refer to Section 5 Tailoring).


14/77


Define Requirement Traceability:Define Requirement Traceability:During the Development Phase of a project, design documents and buildDuring the Development Phase of a project, design documents and build

components are created, based on, and traced back to the system andcomponents are created, based on, and traced back to the system and

component requirements. The Development Team is responsible for recordingcomponent requirements. The Development Team is responsible for recording

the affected elements that are used to trace these requirements to theirthe affected elements that are used to trace these requirements to their

documentation and build components.documentation and build components.

During the Test Phase of a project, thorough testing needs to be done to verifyDuring the Test Phase of a project, thorough testing needs to be done to verify

each requirement. Each component and system requirement will need to meeteach requirement. Each component and system requirement will need to meet

the agreedthe agreed--to acceptance criteria identified in earlier phases of the project. Theto acceptance criteria identified in earlier phases of the project. The

results of these tests and the test case IDs are then recorded and traced backresults of these tests and the test case IDs are then recorded and traced back

to the system and component requirements. The Test Team is responsible forto the system and component requirements. The Test Team is responsible for

entering the test case and the test result that will eventually bring theentering the test case and the test result that will eventually bring the

traceability to its completion.traceability to its completion.


15/77


Define Requirement Traceability:Define Requirement Traceability:

This traceability is documented with the use of a Requirements TraceabilityThis traceability is documented with the use of a Requirements Traceability

Matrix (created manually with theMatrix (created manually with the requirements traceability andrequirements traceability and

verification matrixverification matrixor with a Requirements Tool). This integrated matrixor with a Requirements Tool). This integrated matrix

shows a mapping from the Client Business Requirements to the Systemshows a mapping from the Client Business Requirements to the SystemRequirements to the Component Requirements (as necessary), to the AffectedRequirements to the Component Requirements (as necessary), to the Affected

Elements, to the Acceptance Criteria, and to the Test Type and Test Methods,Elements, to the Acceptance Criteria, and to the Test Type and Test Methods,

which show that each System Requirement and Component Requirement iswhich show that each System Requirement and Component Requirement is

tested (Test Case and Test Results) to verify it meets the Client Businesstested (Test Case and Test Results) to verify it meets the Client Business

Requirement.Requirement.

Each requirement should have one or more corresponding requirements at theEach requirement should have one or more corresponding requirements at the

preceding level (if that level exists) and at the succeeding level (if that levelpreceding level (if that level exists) and at the succeeding level (if that level

exists). If these corresponding requirements do not exist for a requirementexists). If these corresponding requirements do not exist for a requirement

when those levels are defined, the requirement is extraneous.when those levels are defined, the requirement is extraneous.


16/77


Identify the Requirement Status:Identify the Requirement Status:

TheThe requirements traceability and verification matrixrequirements traceability and verification matrix has a status column thathas a status column that

can provide status of each requirement 'at a glance'. This column can providecan provide status of each requirement 'at a glance'. This column can provide

detail on each requirement and summarize the status that is otherwisedetail on each requirement and summarize the status that is otherwise

expressed in multiple columns across the spreadsheet.expressed in multiple columns across the spreadsheet.

This field is provided to track the status of each requirement and may beThis field is provided to track the status of each requirement and may be

updated on an eventupdated on an event--driven (for example, upon each approved change requestdriven (for example, upon each approved change request

or after each test cycle) or on a timeor after each test cycle) or on a time--driven basis, or both, as needed.driven basis, or both, as needed.

If the status column is used, examination of the remaining columns is notIf the status column is used, examination of the remaining columns is not

necessary to determine the status of a requirement. The remaining columns,necessary to determine the status of a requirement. The remaining columns,

however, must be completed in conjunction with the status column, to keephowever, must be completed in conjunction with the status column, to keep

these pieces of information in sync. If not using the status column, delete itthese pieces of information in sync. If not using the status column, delete it

from the spreadsheet and use the other columns to record and determinefrom the spreadsheet and use the other columns to record and determine

status.status.


17/77


Identify the Requirement Status:Identify the Requirement Status:

Some recommended status values are:Some recommended status values are:

Design completeDesign complete Build completeBuild complete

Test verified (indicating specific level of testing)Test verified (indicating specific level of testing) Pending Approval (identified in development or testing & change requestPending Approval (identified in development or testing & change requestawaiting approval)awaiting approval)

Withdrawn (removed after requirements were baselined)Withdrawn (removed after requirements were baselined)

When the scope of a project changes and requirements are removed, theWhen the scope of a project changes and requirements are removed, the

reference to the withdrawn requirement is retained in the documentation,reference to the withdrawn requirement is retained in the documentation,along with its change in status. This information is then retained foralong with its change in status. This information is then retained forhistorical purposes.historical purposes.


18/77


Define & Agree on Acceptance CriteriaDefine & Agree on Acceptance Criteria::

Acceptance Criteria is the definition of the results expected from the test casesAcceptance Criteria is the definition of the results expected from the test cases

to be performed. The product must meet these criteria before implementationto be performed. The product must meet these criteria before implementation

can be approved. Acceptance criteria must be verifiable, attainable,can be approved. Acceptance criteria must be verifiable, attainable,

unambiguous, as well as understandable to both the project team and theunambiguous, as well as understandable to both the project team and theclient.client.

It is considered most effective to write acceptance criteria at the same timeIt is considered most effective to write acceptance criteria at the same time

requirements are being written, and it is included in the document and matrixrequirements are being written, and it is included in the document and matrix

created or updated during the appropriate phase of requirements. Gatheringcreated or updated during the appropriate phase of requirements. Gathering

requirements is typically an interactive and iterative process; establishing andrequirements is typically an interactive and iterative process; establishing and

clarifying acceptance criteria is part of that process.clarifying acceptance criteria is part of that process.


19/77


Define & Agree on Acceptance CriteriaDefine & Agree on Acceptance Criteria ::

When included in theWhen included in the requirements traceability and verification matrixrequirements traceability and verification matrix,,

it simplifies the documentation and increases consistency and accuracy duringit simplifies the documentation and increases consistency and accuracy during

requirements traceability. The information may be maintained on the matrixrequirements traceability. The information may be maintained on the matrix

and crossand cross--referenced on the document, if desired, to avoid duplication ofreferenced on the document, if desired, to avoid duplication ofinformation.information.


20/77


Define Test typesDefine Test types

TheThe requirements traceability and verification matrixrequirements traceability and verification matrixincludes test typesincludes test types

representing typical tests done through the life cycle of a project. When usingrepresenting typical tests done through the life cycle of a project. When using

this matrix, these test types may be customized by an organization tothis matrix, these test types may be customized by an organization to

represent their standard tests. For example, Functional Verification Test,represent their standard tests. For example, Functional Verification Test,Component Verification Test, Translation Verification Test, System IntegrationComponent Verification Test, Translation Verification Test, System Integration

Test, Performance and Stress Test, User Acceptance Test, Pre Production andTest, Performance and Stress Test, User Acceptance Test, Pre Production and

Pilot Test.Pilot Test.


21/77


Define Test typesDefine Test types

If a particular Test Type is needed to verify the specified requirement, then theIf a particular Test Type is needed to verify the specified requirement, then the

intersection of a Test Type column and System or Component Requirement rowintersection of a Test Type column and System or Component Requirement row

is populated with a Test Method. Every System Requirement and Componentis populated with a Test Method. Every System Requirement and Component

Requirement must be tested with at least one Test Type and one Test MethodRequirement must be tested with at least one Test Type and one Test Methodor the matrix is not complete. A client business requirement is satisfied whenor the matrix is not complete. A client business requirement is satisfied when

all of its derived System and Component requirements are satisfied.all of its derived System and Component requirements are satisfied.

For ease of use ofFor ease of use ofrequirements traceability and verification matrixrequirements traceability and verification matrix, Test, Test

Type cells may be grayType cells may be gray--shaded to show that they will not be used to test ashaded to show that they will not be used to test acertain requirement.certain requirement.


22/77


Define Test methods:Define Test methods:

A number of methods may be used to determine if requirements are met. TheA number of methods may be used to determine if requirements are met. The

following test methods are reflected on thefollowing test methods are reflected on the requirements traceability andrequirements traceability and

verification matrixverification matrix, along with their definitions:, along with their definitions:

AnalysisAnalysis: A systematic appraisal of a requirement and its derivations to: A systematic appraisal of a requirement and its derivations to

definitively demonstrate the validity of a requirement, design, or test.definitively demonstrate the validity of a requirement, design, or test.

DemonstrationDemonstration: A presentation of the physical realization of a requirement: A presentation of the physical realization of a requirement

involving active use in real or simulated conditions. This would apply to theinvolving active use in real or simulated conditions. This would apply to the

validation of Human Factors aspects, maintainability, and removal routes.validation of Human Factors aspects, maintainability, and removal routes.


23/77


Define Test methods:Define Test methods:

InspectionInspection: A visual review of documentation, materials or mechanical: A visual review of documentation, materials or mechanical

features associated with the product.features associated with the product.

Simulation / ModelingSimulation / Modeling: A representation of the design (either physically by a: A representation of the design (either physically by amockup, or by means of a computermockup, or by means of a computer--generated simulation which can begenerated simulation which can be

validated as representative) through which performance characteristics of thevalidated as representative) through which performance characteristics of the

design (or elements of it) can be accurately assessed .design (or elements of it) can be accurately assessed .

TestTest: A repeatable test with defined pre: A repeatable test with defined pre--test conditions and quantifiable passtest conditions and quantifiable pass

or fail criteria. Tests may be conducted or repeated at different stages of theor fail criteria. Tests may be conducted or repeated at different stages of the

design and integration process to verify required operation.design and integration process to verify required operation.


24/77


Prioritizing requirements :Prioritizing requirements :

Prioritizing requirements helps the project team understand the true needs ofPrioritizing requirements helps the project team understand the true needs of

the client and allows them to prioritize work in case all of the businessthe client and allows them to prioritize work in case all of the business

requirements cannot be satisfied within the project time frame. The meaning ofrequirements cannot be satisfied within the project time frame. The meaning of

each priority must be agreed to with the client and the following standardeach priority must be agreed to with the client and the following standarddefinitions (sourced from the IEEE Standards Collection, Std 830definitions (sourced from the IEEE Standards Collection, Std 830--1998*) are1998*) are

used:used:

Essential:Essential: This implies that the software will not be acceptable unless theseThis implies that the software will not be acceptable unless these

requirements are provided in an agreed manner.requirements are provided in an agreed manner.Conditional:Conditional: This implies that these are requirements that would enhance theThis implies that these are requirements that would enhance the

software product, but would not make it unacceptable if they are absent.software product, but would not make it unacceptable if they are absent.

Optional:Optional: This implies a class of functions that may or may not be worthwhile.This implies a class of functions that may or may not be worthwhile.

..


25/77

REQUIREMENTS ELICITATION

vDEFINE SCOPE AND CONTEXT

vSTAKEHOLDER INVOLVEMENT

vELICITATION TECHNIQUES


26/77

Requirements

Elicitation


27/77

REQUIREMENTS ANALYSIS

vNECESSITY CHECKING

vFEASIBILITY CHECKING

vDEVELOPING USE-CASESvBUILDING THE ANALYSIS MODEL


28/77

Requirement

Anal i


29/77

REQUIREMENTS NEGOTIATION

vREQUIREMENTS DISCUSSION

vREQUIREMENTS PRIORITIZATI

vREQUIREMENTS AGREEMENT


30/77

Requirements Negotiations

During many points of your life you may be faced with a needDuring many points of your life you may be faced with a need

to negotiate for something.to negotiate for something.

Whether it be a promotion, a sales contract or toWhether it be a promotion, a sales contract or to setset

ExpectationsExpectations

There are some basic things that may make you moreThere are some basic things that may make you more

successful. This post does not seek to go into all of thesuccessful. This post does not seek to go into all of the

advanced negotiation tactics, merely to provide practicaladvanced negotiation tactics, merely to provide practical

guidelines.guidelines.


31/77


Important Points:Important Points:

Preparation is of the utmost importance. Do not enter aPreparation is of the utmost importance. Do not enter anegotiation unprepared.negotiation unprepared.

Perform due diligence on your position as well as thePerform due diligence on your position as well as theother party's. This will help you understand what youother party's. This will help you understand what youneed, what the other party is looking for and perhapsneed, what the other party is looking for and perhapswhat the other party thinks you are looking for.what the other party thinks you are looking for.

Understanding their rationale will offer you insights intoUnderstanding their rationale will offer you insights intotheir negotiation tactics.their negotiation tactics.

Know the minimum you will settle for. This is yourKnow the minimum you will settle for. This is yourmeasuring stick for proposals.measuring stick for proposals.


32/77



Be open, flexible and willing to talk.Be open, flexible and willing to talk. Be calm. Always try to be more patient than the otherBe calm. Always try to be more patient than the other

party.party.

If you are losing control, take a break. People make poorIf you are losing control, take a break. People make poordecisions when they are angry.decisions when they are angry. Clarify your terms.Clarify your terms. If you think someone is bluffing, ask for proof to supportIf you think someone is bluffing, ask for proof to support

their position.their position.

Stress the common goals.Stress the common goals. Use activeUse active--listening to ensure understanding.listening to ensure understanding. Concentrate on one issue at a time.Concentrate on one issue at a time.


33/77



Do not think a negotiation is a winDo not think a negotiation is a win--lose proposition andlose proposition andthat you will only succeed if youthat you will only succeed if you screwscrew the other party.the other party.Ponder this, if you feel you got screwed the last time youPonder this, if you feel you got screwed the last time younegotiated with someone; do you think the next time younegotiated with someone; do you think the next time younegotiate with them you will try to get even? You may benegotiate with them you will try to get even? You may beestablishing a longestablishing a long--term relationship, you do not needterm relationship, you do not needcarrycarry--over animosity.over animosity.

Once you have gotten an acceptable offer, try to close theOnce you have gotten an acceptable offer, try to close thedeal immediately. Do not allow the other party to rethinkdeal immediately. Do not allow the other party to rethink

things.things.


34/77

Requirements Discussions

Discussion SummaryDiscussion Summary A requirements analyst can use aA requirements analyst can use a discussion summarydiscussion summary

to summarize information gathered during elicitationto summarize information gathered during elicitationand validate it through a review.and validate it through a review.

Notes gathered during the elicitation should fit intoNotes gathered during the elicitation should fit intothe discussion summary templatethe discussion summary template

The discussion summary outline can serve as a guideThe discussion summary outline can serve as a guidefor a novice requirements analyst in leadingfor a novice requirements analyst in leadinginterviews and meetingsinterviews and meetings


35/77


Discussion Summary outlineDiscussion Summary outline1.1. Project backgroundProject background

-- Purpose of projectPurpose of project-- Scope of projectScope of project

-- Other background informationOther background information2.2. PerspectivesPerspectives-- Who will use the system?Who will use the system?-- Who can provide input about the system?Who can provide input about the system?

3.3. Project ObjectivesProject Objectives-- Known business rulesKnown business rules

-- System information and/or diagramsSystem information and/or diagrams-- Assumptions and dependenciesAssumptions and dependencies-- Design and implementation constraintsDesign and implementation constraints


36/77


Discussion SummaryDiscussion Summary

4.4. Risks & IssuesRisks & Issues5.5. Known future enhancementsKnown future enhancements

6.6. ReferencesReferences7.7. Open, unresolved or To Be Decided / Done (TBD)Open, unresolved or To Be Decided / Done (TBD)issuesissues


37/77

Requirements Prioritazion

Where will the system be used? How will the system accomplish its mission objective? What are the critical system parameters to accomplish the

mission?

How are the various system components to be used? How effective or efficient must the system be in performing its

mission?

How long will the system be in use by the user? What environments will the system be expected to operate in

an effective manner?


38/77

Requirements Prioritazion

Incremental requirements determined from continualcommunication with customers and stakeholders :

Activities required to upgrade a system Benchmark the modified requirements for the upgrade and the

entire system

Perform functional analysis and allocation on the requirements Assess the system capability and performance before the

upgrade

Identify and manage cost and risk factors Develop and evaluate alternatives for the modified system

Prototype the chosen alternative

Verify the improved performance and new functionality.


39/77

Requirements Agreement

Review the system requirements specificationReview the system requirements specification

Review theReview the system requirements specificationsystem requirements specification andand

system/component architecturesystem/component architecture documents with thedocuments with the

Client to gain agreement between the project and theClient to gain agreement between the project and the

client that the system requirements fully meet the clientclient that the system requirements fully meet the client

business requirements, and the architecture fullybusiness requirements, and the architecture fully

supports the requirements.supports the requirements.

The results of this review are recorded in theThe results of this review are recorded in the systemsystem

requirements review resultsrequirements review results document. The reviewdocument. The review

includes the Project Manager and other relevantincludes the Project Manager and other relevant

stakeholders, as appropriate. Where a requirementstakeholders, as appropriate. Where a requirement

cannot be satisfied, an agreement must be made withcannot be satisfied, an agreement must be made with

the client that the requirement is not within the scope ofthe client that the requirement is not within the scope of

the current project.the current project. If the client insists the requirementIf the client insists the requirement

must be satisfied, then an issue exists that must bemust be satisfied, then an issue exists that must be

resolved.resolved.


40/77


Review the system requirements specificationReview the system requirements specification

Conduct a joint review of theConduct a joint review of the TaskTask "Consolidate Client"Consolidate Client

Business Requirements", if a review (or BRR) is not heldBusiness Requirements", if a review (or BRR) is not held

separately for the clientseparately for the client

Business Requirements, the document(s) are reviewedBusiness Requirements, the document(s) are reviewed

at this point, along with the system requirements andat this point, along with the system requirements and

architecture.architecture. This step then creates a formal approvalThis step then creates a formal approval

and baseline for the client business requirements, inand baseline for the client business requirements, in

addition to the system requirements and architecture.addition to the system requirements and architecture.


41/77

Requirements AgreementTrack, manage and resolveTrack, manage and resolve

Ensure that defects, issues, risks, and actions items from theEnsure that defects, issues, risks, and actions items from thereview are tracked, managed and resolved, including periodicreview are tracked, managed and resolved, including periodic

status updates for all project stakeholders.status updates for all project stakeholders.

Obtain the clients Agreement and the Organization's signObtain the clients Agreement and the Organization's sign--offoff

When allWhen all defects, issues, risks and actions itemsdefects, issues, risks and actions items that maythat may

prevent a signprevent a sign--off are addressed or resolved, obtain the clientsoff are addressed or resolved, obtain the clients

agreement and the Organization's signagreement and the Organization's sign--off, to establish theoff, to establish the

system requirements and architecture baseline. Once thissystem requirements and architecture baseline. Once this

baseline is established, it can only be changed in accordancebaseline is established, it can only be changed in accordancewith thewith the Task Baseline and track requirements.Task Baseline and track requirements. TheseThese

requirements will be traced and tracked throughout therequirements will be traced and tracked throughout the

development lifecycle and will become the basis fordevelopment lifecycle and will become the basis for

verification and testing activities.verification and testing activities.


42/77


Place the approved documents under version controlPlace the approved documents under version control

Allocate component requirements or baseline and trackAllocate component requirements or baseline and trackrequirementsrequirements

Proceed to the next task,Proceed to the next task, TaskTask "Allocate component"Allocate componentrequirements", only if separate component requirementsrequirements", only if separate component requirementsneed to be defined (allocated from system requirements).need to be defined (allocated from system requirements).Proceeds to the TaskProceeds to the Task "Baseline and track requirements","Baseline and track requirements",skipping the component level activities, only if separateskipping the component level activities, only if separatecomponent requirements are not necessary.component requirements are not necessary.

This decision was made in theThis decision was made in the TaskTask "Allocate system"Allocate systemrequirements".requirements".


43/77

REQUIREMENTS DOCUMENT

vCONTENTS OF SOFTWARE REQUIREMENT

SPECIFICATION

vATTRIBUTES OF REQUIREMENTSvVIEWS OF REQUIREMENTS


44/77

Contents of Software Requirements Specification

Table of Contents

1 INTRODUCTION

1.1 Scope

1.2 Management

Summary1.3 Revision History

1.4 Stakeholder Approvers

1.5 Reviewers

1.6 System Objectives / Overview

1.7 < Project Name > Definitions

2 REFERENCES

2.1 CustomerDocuments

2.2 Non-CustomerDocuments

2.3 Updating this Specification


45/77


Table of Contents3REQUIREMENTS

3.1 Functional Requirements

3.1.1 Functional Requirement1 -

3.1.2 Functional Requirement2-

3.2 Usability Requirements

3.2.1 Usability Requirement1 - 3.2.2 Usability Requirement2-

3.3 Non-Function Requirements

3.4 System External Interface Requirements

3.4.1 Interface Identification andDiagrams

3.5 OtherRequirements

3.5.1 User Support Specifications3.5.2 Data Migration Specifications

3.5.3 Report Specifications

3.5.4 Change Cases

3.6 Priority of requirements

3.7 Assumptions, Issues and Constraints


46/77


Table of Contents

4ACCEPTANCE CRITERIA

5APPENDIXA -

6APPENDIX Z - NON FUNCTIONAL REQUIREMENTS CONSIDERATIONS


47/77

Software Requirements Specification

ScopeScope

In this section summarize projects scope.In this section summarize projects scope. This is usually extracted from the scope or project definitionThis is usually extracted from the scope or project definition

document.document. Describe the customer's needs / opportunities for the projectDescribe the customer's needs / opportunities for the project Provide a high level overview of the Project which includesProvide a high level overview of the Project which includes

The purpose of the system,The purpose of the system,

Stakeholders including sponsor,Stakeholders including sponsor,

Geographies / Areas to be covered and where this system is going toGeographies / Areas to be covered and where this system is going to

be installed.be installed.


48/77


Revision HistoryRevision History

Date of RevisionDate of Revision Section RevisedSection Revised Nature of RevisionNature of Revision

Mm/dd/yyyyMm/dd/yyyy Entire document Entire document Initial releaseInitial release

Mm/dd/yyyyMm/dd/yyyy Section 4.5Section 4.5 IncorporatedIncorporatedadditionaladditionalrequirements for userrequirements for userentry screenentry screen


49/77


Stakeholders ApprovalsStakeholders Approvals

StakeholderStakeholder

ApproversApprovers

Representing AreaRepresenting Area Date ApprovedDate Approved

StoreStore Mm/dd/yyyyMm/dd/yyyy

Middle management Middle management Mm/dd/yyyyMm/dd/yyyy


50/77


System ObjectivesSystem Objectives Provide a brief description of the system objectives and constrainsProvide a brief description of the system objectives and constrainsincludingincluding legacy systemslegacy systems that may exist and influence the system.that may exist and influence the system.

Provide a system context diagram which isProvide a system context diagram which isused to graphically summarize the scope of the systemused to graphically summarize the scope of the system

Stand-alone

System1

Stand-alone

System 2

On-Line

User1

On-Line

User2

System

Name

Input 3 Output 4

Output2Input 6

Batch

Output

Interface

Batch Input

Interface

Input 4 Output 5

Output1

Input 1

Input 5

Output3


51/77


System OverviewSystem Overview

Provide brief overview of the architecture.Provide brief overview of the architecture. Summarize the description of the main conceptual elements andSummarize the description of the main conceptual elements and

relationships in architecture, which frequently include candidaterelationships in architecture, which frequently include candidate

subsystems, components, nodes, connections, data stores, userssubsystems, components, nodes, connections, data stores, usersand external systems.and external systems.

Provide reference to the Architectural Overview Diagram workProvide reference to the Architectural Overview Diagram workproduct, which should be treated as a living document on theproduct, which should be treated as a living document on theproject.project.


52/77


Other DetailsOther Details Provide Project / System specific definitionsProvide Project / System specific definitions Provide specific Customer document references:Provide specific Customer document references:

Statement of work / document of understandingStatement of work / document of understanding

Architectural standardsArchitectural standards

Top level requirementsTop level requirements Business rules catalogueBusiness rules catalogue

Coding standards, naming conventionsCoding standards, naming conventions

Data Security and Privacy rules (PI / SPI)Data Security and Privacy rules (PI / SPI)

Provide non customer document references:Provide non customer document references:

Use case modelsUse case models Architectural decisionsArchitectural decisions

User ProfileUser Profile

User interface design guidelinesUser interface design guidelines


53/77


RequirementsRequirements The purpose of this section is toThe purpose of this section is to specify the system levelspecify the system levelrequirementsrequirements, which are the characteristics of the system that are, which are the characteristics of the system that areconditions for its acceptance.conditions for its acceptance.

Each requirement is assigned a unique identifier (reference) toEach requirement is assigned a unique identifier (reference) tosupport testing and traceability and it is stated in such a way thatsupport testing and traceability and it is stated in such a way that

an objective test can be defined for it.an objective test can be defined for it. Each requirement shall be annotated / explained with aEach requirement shall be annotated / explained with a

qualification / acceptance method(s)qualification / acceptance method(s)

Requirements are identified by the following categories:Requirements are identified by the following categories:

FunctionalFunctional

UsabilityUsability

NonNon--functionalfunctional

External InterfaceExternal Interface

OtherOther


54/77


RequirementsRequirements The degree of detail to be provided shall be guided by theThe degree of detail to be provided shall be guided by thefollowing rule:following rule:

Include those characteristics of the system that are condition forInclude those characteristics of the system that are condition forsystem acceptance,system acceptance,

Defer to design descriptions those characteristics that the customer isDefer to design descriptions those characteristics that the customer iswilling to leave up to the developer.willing to leave up to the developer.

If there are no requirements in a given paragraph, the paragraph shallIf there are no requirements in a given paragraph, the paragraph shallso state.so state.

If a given requirement fits into more than one paragraph, it may beIf a given requirement fits into more than one paragraph, it may bestated once and referenced from the other paragraphs.stated once and referenced from the other paragraphs.


55/77


Functional RequirementsFunctional Requirements The purpose of this section is to identify the system capabilities.The purpose of this section is to identify the system capabilities. A functional requirement is a business function or capability to beA functional requirement is a business function or capability to be

included in the solution to be developed.included in the solution to be developed.

Functional requirements should be summarized as "verbs" thatFunctional requirements should be summarized as "verbs" thatspecify a required behavior of the system.specify a required behavior of the system.

A good functional requirement should be unambiguous andA good functional requirement should be unambiguous andtestable.testable.

Attributes that make a good set of functional requirements are:Attributes that make a good set of functional requirements are: Being Unambiguous, Understandable, Concise, Traceable, Unique,Being Unambiguous, Understandable, Concise, Traceable, Unique,

Complete, Consistent, Comparable, Modifiable, Attainable (achievable)Complete, Consistent, Comparable, Modifiable, Attainable (achievable)and Design Independent.and Design Independent.


56/77


Usability RequirementsUsability Requirements The purpose of this section is to identify the usability requirementsThe purpose of this section is to identify the usability requirementsthat define the usability attributes and measurable requirementsthat define the usability attributes and measurable requirementsthat facilitate easethat facilitate ease--ofof--use with the system. These include theuse with the system. These include theattributes of interaction (e.g., navigation), display (e.g., screenattributes of interaction (e.g., navigation), display (e.g., screenlayout), affective (e.g., aesthetic) as well as measurablelayout), affective (e.g., aesthetic) as well as measurable

requirements for user performance or productivity (e.g., 2 minutesrequirements for user performance or productivity (e.g., 2 minutesto complete a transaction)to complete a transaction)

Also included shall be the human factors engineeringAlso included shall be the human factors engineeringrequirements, if any, imposed on the system. These requirementsrequirements, if any, imposed on the system. These requirementsshall include, as applicable, considerations for the capabilities andshall include, as applicable, considerations for the capabilities andlimitations of humans, foreseeable human errors, and specificlimitations of humans, foreseeable human errors, and specific

areas where the effects of human error would be particularlyareas where the effects of human error would be particularlyserious. Examples include requirements for adjustableserious. Examples include requirements for adjustable--heightheightworkstations, color and duration of error messages, physicalworkstations, color and duration of error messages, physicalplacement of critical indicators or buttons, and use of auditory,placement of critical indicators or buttons, and use of auditory,signals.signals.


57/77


NonNon--Function RequirementsFunction Requirements The purpose of this section is to identify the nonThe purpose of this section is to identify the non--functionalfunctionalrequirements which address those aspects of the systemrequirements which address those aspects of the systemthat, while not directly affecting the functionality of thethat, while not directly affecting the functionality of thesystem as seen by the users, can have a profound effect onsystem as seen by the users, can have a profound effect onhow that business system is accepted by both the users andhow that business system is accepted by both the users and

the people responsible for supporting that system.the people responsible for supporting that system.


58/77

Software Requirements SpecificationNonNon--Function RequirementsFunction Requirements

The nonThe non--functional aspects of a business system cover afunctional aspects of a business system cover abroad range of themes. The major nonbroad range of themes. The major non--functional themesfunctional themesidentified by the Application Enabling Design (AED) Technicalidentified by the Application Enabling Design (AED) TechnicalCouncil are listed below:Council are listed below:

Performance (including Capacity)Performance (including Capacity)

Scalability (to meet the future needs)Scalability (to meet the future needs) Availability (including Recoverability and Reliability)Availability (including Recoverability and Reliability)

Maintainability (including Flexibility and Portability)Maintainability (including Flexibility and Portability)

Security (Accessibility, Privacy, Protection)Security (Accessibility, Privacy, Protection)

ManageabilityManageability

Environmental (including Safety)Environmental (including Safety) Data Integrity (including Currency, Locality of Updating, DataData Integrity (including Currency, Locality of Updating, Data

Retention)Retention)


59/77


NonFunctionalRequirementsconsiderationsNonFunctionalRequirementsconsiderations

The purpose of the following listif to provide alist of nonThe purpose of the following listif to provide alist of nonfunctionalrequirementsthatare usually consideredinbothfunctionalrequirementsthatare usually consideredinbothinternalandexternalprojects. Notice thatthislistisnotinternalandexternalprojects. Notice thatthislistisnotcomplete.complete.

Nonfunctionalrequirementstoconsider:Nonfunctionalrequirementstoconsider:

PerformancePerformance, they are usually a combination of four separate sets of, they are usually a combination of four separate sets ofsubsub--requirements:requirements:

A) Response Time RequirementsA) Response Time Requirements. They are related to the response. They are related to the responsetimes to complete specific processes. It is important to focus on thetimes to complete specific processes. It is important to focus on therequirements of the business when setting response time targets, ratherrequirements of the business when setting response time targets, rather

than getting seduced by the apparent nirvana of sub second ITthan getting seduced by the apparent nirvana of sub second ITtransaction response. For example: the end to end response timetransaction response. For example: the end to end response timeassociated with a specific userassociated with a specific user--system interaction, e.g. the time betweensystem interaction, e.g. the time betweena user selecting the process button within a desktop window, and thea user selecting the process button within a desktop window, and theresult set data from the associated query being displayed back to theresult set data from the associated query being displayed back to theuser.user.


60/77


NonFunctionalRequirementsconsiderationsNonFunctionalRequirementsconsiderations B)B) ThroughputRequirementsThroughputRequirements(Dynamic Volumetric Requirements).(Dynamic Volumetric Requirements).

They are related to the ability of the business system to execute a givenThey are related to the ability of the business system to execute a givennumber of businesses or system related processes within a given unit ofnumber of businesses or system related processes within a given unit oftime. For example: The number of new orders processed per day etc.time. For example: The number of new orders processed per day etc.

C)C) UtilizationRequirementsUtilizationRequirements. They are related to the maximum. They are related to the maximumacceptable loading of the nodes on which the business system is to beacceptable loading of the nodes on which the business system is to beimplemented when running the Design Point workload. In someimplemented when running the Design Point workload. In somesituations, the contract will stipulate that one or more of the deliveredsituations, the contract will stipulate that one or more of the deliveredsystem components should not exceed a certain utilization thresholdsystem components should not exceed a certain utilization thresholdwhen supporting the Design Point workload. For example, the networkwhen supporting the Design Point workload. For example, the networkbandwidth utilization shall not exceed 20%, or the database server shallbandwidth utilization shall not exceed 20%, or the database server shall

be no more than 60% utilized.be no more than 60% utilized.

StaticVolumetricRequirementsStaticVolumetricRequirements . They are related to the volumetric. They are related to the volumetricfor the data entities that exist within the target system that, althoughfor the data entities that exist within the target system that, althoughrelatively static, are likely to have a significant effect on the overall sizingrelatively static, are likely to have a significant effect on the overall sizingof the target system. For example, the number of business system usersof the target system. For example, the number of business system usersby type, number of different user locations, number of customers, etc.by type, number of different user locations, number of customers, etc.


61/77


NonFunctionalRequirementsconsiderationsNonFunctionalRequirementsconsiderations ScalabilityScalability is usually related to the ability for a system to continue tois usually related to the ability for a system to continue to

function well as it (or its context) is changed in size or volume in order tofunction well as it (or its context) is changed in size or volume in order tomeet a user need.meet a user need.

CapacityCapacity refers to the systems ability to maintain TBD storage for therefers to the systems ability to maintain TBD storage for theusers datausers data

AvailabilityAvailability refers to a system or component that is continuouslyrefers to a system or component that is continuouslyoperational for a desirably long length of time. Availability can beoperational for a desirably long length of time. Availability can bemeasured relative to "100% operational" or "never failing." A widelymeasured relative to "100% operational" or "never failing." A widely--heldheldbut difficultbut difficult--toto--achieve standard of availability for a system or product isachieve standard of availability for a system or product isknown as "five 9s" (99.999% percent) availability.known as "five 9s" (99.999% percent) availability.

ReliabilityReliability refers to the systems ability to remain operational underrefers to the systems ability to remain operational underabnormal conditionsabnormal conditions RecoverabilityRecoverability refers to the systems ability to recover from a disasterrefers to the systems ability to recover from a disaster

with minimal loss of time or datawith minimal loss of time or data


62/77


NonFunctionalRequirementsconsiderationsNonFunctionalRequirementsconsiderations MaintainabilityMaintainability (including Flexibility and Portability) refers to the(including Flexibility and Portability) refers to the

systems ability to be serviced after initial configuration, setup, andsystems ability to be serviced after initial configuration, setup, andstartup tasks have been completed.startup tasks have been completed.

ServiceabilityServiceability refers to the systems ability to support hardware andrefers to the systems ability to support hardware andsoftware upgrades once the system has been deployed.software upgrades once the system has been deployed.

SecuritySecurity is related to legal, regulatory, privacy and securityis related to legal, regulatory, privacy and securityconsiderations. For example, policies and procedures that system shallconsiderations. For example, policies and procedures that system shallfollow, compliance with privacy act in different Geo., audits, etc.follow, compliance with privacy act in different Geo., audits, etc.

RegulatoryRegulatory refers to the systems ability to meet countryrefers to the systems ability to meet country--specific (orspecific (orrelated) statutes and regulationsrelated) statutes and regulations


63/77


NonFunctionalRequirementsconsiderationsNonFunctionalRequirementsconsiderations ManageabilityManageability is related to management procedures defined for theis related to management procedures defined for the

following environmentsfollowing environments -- development, testing, staging, deployment, lifedevelopment, testing, staging, deployment, lifecycle etc. It usually addresses roles and responsibilities, configurationcycle etc. It usually addresses roles and responsibilities, configurationand change control, monitoring and controlling activities (such as reportsand change control, monitoring and controlling activities (such as reportsthat need to be produced), etc.that need to be produced), etc.

EnvironmentalEnvironmental(including Safety) requirements usually describe(including Safety) requirements usually describedifferent environments, their configuration and other constrains such asdifferent environments, their configuration and other constrains such ascost, schedule and resources.cost, schedule and resources.

Development environment (i.e. hardware and software constrains such asDevelopment environment (i.e. hardware and software constrains such asoperating systems and hardware to use in this environment. Use ofoperating systems and hardware to use in this environment. Use ofcustomercustomer -- fumished property, use of particular design or constructionsfumished property, use of particular design or constructionsstandards, use of particular data standards, use of a particularstandards, use of particular data standards, use of a particularprogramming language etc.)programming language etc.)

Testing environment (i.e. hardware and software constrains such asTesting environment (i.e. hardware and software constrains such asoperating systems and hardware to use in this environment, etc.)operating systems and hardware to use in this environment, etc.)


64/77


NonFunctionalRequirementsconsiderationsNonFunctionalRequirementsconsiderations PhysicalcharacteristicsPhysicalcharacteristicsof the system in terms of hardware, software,of the system in terms of hardware, software,

data communication etc. (i.e. Hardware examples are weight limits, size,data communication etc. (i.e. Hardware examples are weight limits, size,power etc. Software examples are number of users or volumes expected.power etc. Software examples are number of users or volumes expected.Data communication examples are medium to use, the amount of data /Data communication examples are medium to use, the amount of data /network capacity to handle etc.).network capacity to handle etc.).

Costs (i.e. project budgets)Costs (i.e. project budgets) ScheduleSchedule Human ResourcesHuman Resources DataIntegrityDataIntegrity (including Currency, Locality of Updating, Data(including Currency, Locality of Updating, Data

Retention)Retention)

UsabilityUsability refers to the systems ability to provide a User Interface that isrefers to the systems ability to provide a User Interface that issimple to use.simple to use.

InteroperabilityInteroperability refers to the systems ability to interrefers to the systems ability to inter--operate withoperate withrelated systems.related systems.


65/77

Software Requirements SpecificationSystem ExternalInterface RequirementsSystem ExternalInterface Requirements

The purpose ofthissectionisto identifythe ExternalInterfaceThe purpose ofthissectionisto identifythe ExternalInterfacerequirements.requirements.

Ifthe externalsysteminterfacesare complex, theymaybeIfthe externalsysteminterfacesare complex, theymaybealternativelydefined inaSystem Interface Requirementsalternativelydefined inaSystem Interface Requirements

Specification(SIRS) document.Specification(SIRS) document.


66/77


Interface IdentificationandDiagramsInterface IdentificationandDiagramsThe identificationshall state which entitieshave fixedinterfaceThe identificationshall state which entitieshave fixedinterface

characteristics(andtherefore impose interface requirementsoncharacteristics(andtherefore impose interface requirementson

interfacing entities) andwhich are beingdevelopedormodified(thusinterfacing entities) andwhich are beingdevelopedormodified(thus

havinginterface requirementsimposedonthem).havinginterface requirementsimposedonthem).

One ormore interface diagramsshall be providedtodepicttheOne ormore interface diagramsshall be providedtodepicttheinterfaces. Use table todocumentexternal interfaces.interfaces. Use table todocumentexternal interfaces.

ExternalExternal

interfaceinterface

InputInput OutputsOutputs RequirementRequirementFrequencyFrequency SizeSize


67/77

UserSupportSpecifications:UserSupportSpecifications:

The UserSupportSpecificationsare specificationsoftheThe UserSupportSpecificationsare specificationsofthe

-- ContentContent-- StructureStructure

-- AudienceAudience

-- MediaMedia

-- FormatFormat

The specificationsare the work descriptionsforthe developmentofThe specificationsare the work descriptionsforthe developmentof

the variousunitsofuserdocumentation.the variousunitsofuserdocumentation.


Of the documentation ofOf the documentation of

the system to be usedthe system to be used

by the users.by the users.


68/77

Data MigrationInterfaces:Data MigrationInterfaces:

The Data MigrationSpecificationsare specificationsthatdefine aThe Data MigrationSpecificationsare specificationsthatdefine a

transferofdatafrom one reference toanother.transferofdatafrom one reference toanother.

The data movement(ormigration) may be manual orautomatic, andThe data movement(ormigration) may be manual orautomatic, and

itmay occuronce (datainitialization) oronanongoing basis.itmay occuronce (datainitialization) oronanongoing basis.



69/77

ReportSpecifications:ReportSpecifications:

ReportSpecificationsdescribe new reportsand enhancementstoReportSpecificationsdescribe new reportsand enhancementsto

existing reportsto be produced by the system.existing reportsto be produced by the system.

ReportSpecificationsmay be defined separately inthissectionorReportSpecificationsmay be defined separately inthissectionor

they may be included inthe Functional Requirementsorthe Usabilitythey may be included inthe Functional Requirementsorthe Usability

RequirementssectionsRequirementssections



70/77

Change Cases:Change Cases:

Change Casesdocument future changesto:Change Casesdocument future changesto:

The system capabilitiesand propertiesThe system capabilitiesand properties The way the system isusedThe way the system isused The system operatingand support environmentsThe system operatingand support environments Changesare relevant and deserve to be included if they affectChangesare relevant and deserve to be included if they affect

the architecture and designnowthe architecture and designnow



71/77

PriorityofRequirements:PriorityofRequirements:

Thissectionshall specifythe priorityofthe requirements,Thissectionshall specifythe priorityofthe requirements,

The orderofprecedence , Criticality, orassigned weightsindicatingThe orderofprecedence , Criticality, orassigned weightsindicating

The relative importance ofthe requirementsinthisspecificationThe relative importance ofthe requirementsinthisspecification

The actual priorityofthe requirementscanbe defined here orThe actual priorityofthe requirementscanbe defined here or

documented elsewhere (forexample, inthe requirementsdefinitiondocumented elsewhere (forexample, inthe requirementsdefinition

orinthe RequirementsTraceabilityand VerificationMatrix),orinthe RequirementsTraceabilityand VerificationMatrix),

butall requirementsmustbe prioritized.butall requirementsmustbe prioritized.



72/77

Some importantdefinitionstoprioritize requirements:Some importantdefinitionstoprioritize requirements:

EssentialEssential : Thisimpliesthatthe software will notbe acceptable unless: Thisimpliesthatthe software will notbe acceptable unless

these requirementsare providedinanthese requirementsare providedinanagreedmanneragreedmanner..

ConditionalConditional : Thisimpliesthatthese are requirementsthatwould: Thisimpliesthatthese are requirementsthatwould

enhance the software product, butwouldnotmake the productenhance the software product, butwouldnotmake the product

unacceptable ifthey are absent.unacceptable ifthey are absent.

OptionalOptional : Thisimpliesa classoffunctionsthatmay ormay notbe: Thisimpliesa classoffunctionsthatmay ormay notbe

worthwhileworthwhile

These definitionsmustbe agreedwith customerThese definitionsmustbe agreedwith customer



73/77

Assumptions, IssuesandConstraints:Assumptions, IssuesandConstraints:

Thissectionshall recordall critical Assumptions, IssuesandThissectionshall recordall critical Assumptions, Issuesand

Constraintsunderwhich the systemarchitecture isdesigned.Constraintsunderwhich the systemarchitecture isdesigned.

Itshouldalsorecordimplicationsforeach.Itshouldalsorecordimplicationsforeach.

Forexample if the constraintisaboutnetwork speed,the possibleForexample if the constraintisaboutnetwork speed,the possible

implicationforresponse time may be discussedimplicationforresponse time may be discussed



74/77

Acceptance Criteria:Acceptance Criteria:

Complete the acceptance criteria underthe Requirements TraceabilityComplete the acceptance criteria underthe Requirements Traceability

and VerificationMatrixtemplate.and VerificationMatrixtemplate.

This deliverable shall be completed before aSRR (SystemThis deliverable shall be completed before aSRR (System

Requirements Review).Requirements Review).

Acceptance criteriais incorporated into the Requirements TraceabilityAcceptance criteriais incorporated into the Requirements Traceability

and VerificationMatrixtemplate to simplify this documentandand VerificationMatrixtemplate to simplify this documentand

increase consistency and accuracy during requirements traceability.increase consistency and accuracy during requirements traceability.



75/77

Acceptance Criteria:Acceptance Criteria:

As a guidance, itis considered mosteffective to write acceptanceAs a guidance, itis considered mosteffective to write acceptance

criteriaatthe same time requirements are being written.criteriaatthe same time requirements are being written.

This is also aniterative process thathelps getting requirementsThis is also aniterative process thathelps getting requirements

clearly stated.clearly stated.

If acceptance criteriaare documented inSRS document, thenitisIf acceptance criteriaare documented inSRS document, thenitis

usually bestto documentthe acceptance criteria with the definitionofusually bestto documentthe acceptance criteria with the definitionof

the requirement.the requirement.



76/77

REQUIREMENTS VERIFICATION

vREQUIREMENTS REVIEW

vREQUIREMENTS SIGN OFF


77/77

What is the requirements engineering process?What is the requirements engineering process?

The processes used for requirements engineering varyThe processes used for requirements engineering varywidely depending on the application domain, the peoplewidely depending on the application domain, the peopleinvolved and the organization developing theinvolved and the organization developing therequirementsrequirements

However, there are a number of generic activitiesHowever, there are a number of generic activitiescommon to all processescommon to all processes

Requirements elicitationRequirements elicitation

Requirements analysisRequirements analysis

Requirements validationRequirements validation

Requirements managementRequirements management