re role scope2 sinvolvement elictechnique
TRANSCRIPT
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
1/77
REQUIREMENTS ENGINEERING PROCESS
vROLE OF THE PROFESSIONAL FOR
REQUIREMENTS
ENGINEERING
vCHARACTERISTICS OF REQUIREMENTS
ENGINEERING
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
4/77
Role of the Professional for Requirements
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
5/77
Role of the Professional for Requirements
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
6/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
7/77
Role of the Professional for RequirementsEngineering
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/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
8/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
9/77
Role of the Professional for RequirementsEngineering
Perform Technical Performance Measurements (TPM)Perform Technical Performance Measurements (TPM)
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
10/77
Role of the Professional for RequirementsEngineering
Perform Technical Performance Measurements (TPM)Perform Technical Performance Measurements (TPM)
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
11/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
12/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
13/77
Role of the Professional for RequirementsEngineering
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).
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
14/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
15/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
16/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
17/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
18/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
19/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
20/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
21/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
22/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
23/77
Role of the Professional for RequirementsEngineering
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
24/77
Role of the Professional for RequirementsEngineering
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.
..
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
25/77
REQUIREMENTS ELICITATION
vDEFINE SCOPE AND CONTEXT
vSTAKEHOLDER INVOLVEMENT
vELICITATION TECHNIQUES
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
26/77
Requirements
Elicitation
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
27/77
REQUIREMENTS ANALYSIS
vNECESSITY CHECKING
vFEASIBILITY CHECKING
vDEVELOPING USE-CASESvBUILDING THE ANALYSIS MODEL
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
28/77
Requirement
Anal i
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
29/77
REQUIREMENTS NEGOTIATION
vREQUIREMENTS DISCUSSION
vREQUIREMENTS PRIORITIZATI
vREQUIREMENTS AGREEMENT
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
31/77
Requirements Negotiations
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
32/77
Requirements Negotiations
Important Points:Important Points:
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
33/77
Requirements Negotiations
Important Points:Important Points:
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
35/77
Requirements Discussions
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
36/77
Requirements Discussions
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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?
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
40/77
Requirements Agreement
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
42/77
Requirements Agreement
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".
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
43/77
REQUIREMENTS DOCUMENT
vCONTENTS OF SOFTWARE REQUIREMENT
SPECIFICATION
vATTRIBUTES OF REQUIREMENTSvVIEWS OF REQUIREMENTS
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
45/77
Contents of Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
46/77
Contents of Software Requirements Specification
Table of Contents
4ACCEPTANCE CRITERIA
5APPENDIXA -
6APPENDIX Z - NON FUNCTIONAL REQUIREMENTS CONSIDERATIONS
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
48/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
49/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
50/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
51/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
52/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
53/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
54/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
55/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
56/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
57/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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)
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
59/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
60/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
61/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
62/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
63/77
Software Requirements Specification
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.)
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
64/77
Software Requirements Specification
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
66/77
Software Requirements Specification
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
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
Software Requirements Specification
Of the documentation ofOf the documentation of
the system to be usedthe system to be used
by the users.by the users.
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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.
Software Requirements Specification
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
76/77
REQUIREMENTS VERIFICATION
vREQUIREMENTS REVIEW
vREQUIREMENTS SIGN OFF
-
8/8/2019 RE Role Scope2 Sinvolvement ElicTechnique
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