Chp 11. 2 Developmental Psychology Chp 13 Comparative Psychology.
1 Software Requirements, 2 nd Edition: by Karl E. Wiegers Chp 18: Requirements Management Principles...
-
date post
22-Dec-2015 -
Category
Documents
-
view
249 -
download
5
Transcript of 1 Software Requirements, 2 nd Edition: by Karl E. Wiegers Chp 18: Requirements Management Principles...
1
Software Requirements, 2nd Edition: by Karl E. Wiegers Chp 18: Requirements Management Principles and Practices Chp 19: Change HappensChp 20: Links in the Requirements ChainChp 22: Improving Your Requirements
Chp 23: Software Requirements and Risk
Gregory (Greg) Maltby, PMP, BSCSApril 13, 2010
EECS 812
2
Software Requirements:
Chp 18: Requirements Management Principles and Practices
3
Requirements Development
• Requirements development involves eliciting, analyzing, specifying, and validating a software project's requirements.
• Typical requirements development deliverables, for a software project, include:– a vision and scope document – use-case documents – a software requirements specification – a data dictionary – associated analysis models
• Once reviewed and approved, these artifacts define the requirements baseline.
4
Requirements Management
• The requirements agreement is the bridge between requirements development and requirements management.
• Requirements management includes all activities that maintain the integrity, accuracy, and currency of the requirements agreement as the project progresses.
5
Requirements Management Activities
6
Requirements Management Activities
• Change Control – Proposing changes– Analyzing impact– Making decisions– Updating requirements documents– Updating plans– Measuring requirements volatility
7
Requirements Management Activities
• Version Control – Defining a version identification scheme– Identifying requirements document versions– Identifying individual requirement versions
8
Requirements Management Activities
• Requirements Status Tracking – Defining possible requirements statuses– Recording the status of each requirement – Reporting the status distribution of all
requirements
9
Requirements Management Activities
• Requirements Tracing – Defining links to other requirements– Defining links to other system elements
10
Requirements Change Control • Accepting newly proposed requirements changes
(modifications to existing requirements or additional requirements) may impact existing schedule and quality commitments.
• The project can respond to new or changed requirements in various ways:– Defer lower-priority requirements – Obtain additional staff – Mandate overtime work, preferably with pay, for a short
time – Slip the schedule to accommodate the new functionality – Let quality suffer in the press to ship by the original date
11
Requirements Change Control
• Accept the reality of adjusting expectations and commitments.
• Prior to baselining, the requirements are still evolving, so there's no point in imposing unnecessary process overhead on those modifications
12
Requirements Baseline• The requirements baseline is the set of functional and
nonfunctional requirements that the development team has committed to implement in a specific release.
• The baseline gives the project stakeholders a shared understanding of the capabilities and properties they can expect to see in the release.
• At the time the requirements are baselined —typically following formal review and approval — they are placed under configuration management.
• Subsequent changes can be made only through the project's defined change-control process.
13
Requirements Version Control
• Begin practicing version control as soon as you create a preliminary draft of a document.
• Uniquely identify different versions of each requirements document.– Unique ID or Name / Date-Stamp
14
Requirements Version Control
• Version control is an essential aspect of managing requirements specifications and other project documents.
• Changes must be clearly documented and communicated to everyone affected.
15
Requirements Version ControlIt's Not a Bug; It's a Feature!
A contract development team received a flood of defect reports from the people testing the latest release of a system they had just delivered to aclient. The contract team was perplexed—the system had passed all theirown tests. After considerable investigation, it turned out that the client had been testing the new software against an obsolete version of the software requirements specification. What the testers were reporting as bugs truly were features.
Much of the testing effort was wasted because the testers were looking for the wrong system behaviors. The testers spent considerable time rewriting the tests against the correct version of the SRS and retesting the software, allbecause of a version control problem.
16
Requirements Version Control
• Each circulated version of the requirements documents should include:– revision history identifying the changes made – date of each change – name of individual who made the change – reason for each change
17
Requirements Management Procedures
• Tools, techniques, and conventions for controlling versions of the various requirements documents and of individual requirements
• How the requirements are baselined • The requirement statuses that you will use
and who may change them • Requirement status-tracking procedures
18
Requirements Management Procedures (continued)
• The ways that new requirements, and changes to existing ones, are proposed, processed, negotiated, and communicated to all affected stakeholders
• How to analyze the impact of a proposed change
• How the project's plans and commitments will reflect requirements changes
19
Requirements Attributes
• Think of each requirement as an object with properties that distinguish it from other requirements.– Textual description– Several supporting pieces of information or
attributes associated with it
20
Requirements Attributes - Examples
• Date the requirement was created • Its current version number • Author who wrote the requirement • Person who is responsible for ensuring that the
requirement is satisfied • Owner of the requirement or a list of stakeholders
(to make decisions about proposed changes) • Requirement status • Origin or source of the requirement
21
Requirements Attributes – Examples (continued)• The rationale behind the requirement • Subsystem (or subsystems) to which the requirement
is allocated • Product release number to which the requirement is
allocated • Verification method to be used or acceptance test
criteria • Implementation priority • Stability (an indicator of how likely it is that the
requirement will change in the future)
22
Tracking Requirements StatusStatus Definition
Proposed The requirement has been requested by an authorized source.
Approved The requirement has been analyzed, its impact on the project has been estimated, and it has been allocated to the baseline for a specific release. The key stakeholders have agreed to incorporate the requirement, and the software development group has committed to implement it.
Implemented The code that implements the requirement has been designed, written, and unit tested. The requirement has been traced to the pertinent design and code elements.
Verified The correct functioning of the implemented requirement has been confirmed in the integrated product. The requirement has been traced to pertinent test cases. The requirement is now considered complete.
Deleted An approved requirement has been removed from the baseline. Include an explanation of why and by whom the decision was made to delete it.
Rejected The requirement was proposed but is not planned for implementation in any upcoming release. Include an explanation of why and by whom the decision was made to reject it.
23
Requirements Management Effort
• As with requirements development, your project plan should include tasks and resources for the requirements management activities.
• Requirements Management helps to ensure that the effort you invest in gathering, analyzing, and documenting requirements isn't squandered.
24
Requirements Management Effort
• Requirements Management Activities /Effort– Submitting requirements changes and proposing
new requirements – Evaluating proposed changes, including
performing impact analysis – Change control board activities
25
Requirements Management Effort
• Requirements Management Activities /Effort (continued)– Updating the requirements documents or
database – Communicating requirements changes to affected
groups and individuals – Tracking and reporting requirements status – Collecting requirements traceability information
26
Requirements Management Principles and Practices - Summary (1)
• Requirements Management includes all activities that maintain the integrity, accuracy, and currency of the requirements agreement as the project progresses.– Change Control– Version Control– Requirements Status Tracking– Requirements Tracing
27
Requirements Management Principles and Practices - Summary (2)
• Requirements Baseline is the set of functional and nonfunctional requirements that the development team has committed to implement in a specific release.
• Think of each requirement as an object with properties that distinguish it from other requirements
• As with requirements development, your project plan should include tasks and resources for the requirements management activities.
28
Software Requirements:
Chp 19: Change Happens
29
Change Happens• It's virtually impossible to define all of a product's
requirements up front, and the world changes as development progresses.
• An organization that's serious about managing its software projects must ensure that – Proposed requirements changes are carefully evaluated
before being committed to. – The appropriate individuals make informed business
decisions about requested changes. – Approved changes are communicated to all affected
participants. – The project incorporates requirements changes in a
consistent fashion.
30
Managing Scope Creep
• Creeping requirements include new functionality and significant modifications that are presented after the project requirements have been baselined.
• Late changes have a big impact on work already performed.
• Some requirements evolution is legitimate, unavoidable, and even advantageous.
• Uncontrolled scope creep, in which the project continuously incorporates new functionality without adjusting resources, schedules, or quality goals, is more dangerous.
31
Ways to Manage Scope Creep
• Document the vision, scope, and limitations of the new system as part of the business requirements.
• Evaluate every proposed requirement or feature against the business objectives, product vision, and project scope.
• Engaging customers in elicitation reduces the number of requirements that are overlooked.
• Effective techniques for controlling scope creep.– Prototyping– Using short development cycles.
32
Ways to Manage Scope Creep
• The most effective technique for controlling scope creep is being able to say “no”.
• Nice way to say no – say “not now”.
• Including every feature that customers, marketing, product management, and developers request leads to missed commitments, slipshod quality, burned-out developers, and bloatware.
33
The Change Control Process
• A change-control process lets the project's leaders:– make informed business decisions that will
provide the greatest customer and business value– control the product's life cycle costs– track the status of all proposed changes– (helps) ensure that suggested changes aren't lost
or overlooked
34
The Change Control Process
• The key to a successful Change Control Process – – well documented – as simple as possible– above all — effective.
35
The Change Control Policy (Statements)
• All requirements changes shall follow the process. If a change request is not submitted in accordance with this process, it won't be considered.
• No design or implementation work other than feasibility exploration shall be performed on unapproved changes.
• Simply requesting a change doesn't guarantee that it will be made. The project's Change Control Board (CCB) will decide which changes to implement.
36
The Change Control Policy (Statements)• The contents of the change database shall be visible
to all project stakeholders. • The original text of a change request shall not be
modified or deleted. • Impact analysis shall be performed for every change. • Every incorporated requirement change shall be
traceable to an approved change request. • The rationale behind every approval or rejection of a
change request shall be recorded.
37
The Change Control Description
1. Introduction – 1.1 Purpose– 1.2 Scope– 1.3 Definitions
2. Roles and Responsibilities 3. Change-Request Status4. Entry Criteria
38
The Change Control Description5. Tasks – 5.1 Evaluate Request – 5.2 Make Decision – 5.3 Make Change – 5.4 Notify All Affected Parties
6. Verification – 6.1 Verify Change – 6.2 Install Product
7. Exit Criteria 8. Change-Control Status Reporting Appendix: Data Items Stored for Each Request
39
The Change Request Lifecycle
40
Suggested Change Data Request ItemsItem Description
Change Origin
Functional area that requested the change; possible groups include marketing, management, customer, software engineering, hardware engineering, and testing
Change-Request ID
Identification tag or sequence number assigned to the request
Change Type
Type of change request, such as a requirement change, a proposed enhancement, or a defect report
Date Submitted
Date the originator submitted the change request
Date Updated
Date the change request was most recently modified
Description Free-form text description of the change being requested
Implementa-tion Priority
The relative importance of making the change as determined by the CCB: low, medium, or high
Modifier Name of the person who is primarily responsible for implementing the change
41
Suggested Change Data Request ItemsItem Description
Originator Name of the person who submitted this change request; consider including the originator's contact information
Originator Priority
The relative importance of making the change from the originator's point of view: low, medium, or high
Planned Release
Product release or build number for which an approved change is scheduled
Project Name of the project in which a change is being requested
Response Free-form text of responses made to the change request; multiple responses can be made over time; do not change existing responses when entering a new one
Status The current status of the change request
Title One-line summary of the proposed change
Verifier Name of the person who is responsible for determining whether the change was made correctly
42
The Change Control Board• The Change Control Board (also known as the
Configuration Control Board) has been identified as a best practice for software development.
• The CCB is the body of people (one person or a group), who decides which proposed requirement changes and newly suggested features to accept for inclusion in the product.
• The CCB also decides which reported defects to correct and when to correct them.
• A CCB reviews and approves changes to any baselined work product on a project, of which the requirements documents are only one example.
43
Change Control Board - Participants
• Project or program management • Product management or requirements analyst • Development • Testing or quality assurance • Marketing or customer representatives • User documentation • Technical support or help desk • Configuration management
44
The Change Control Board – Roles and Responsibilities
Role Description and ResponsibilitiesCCB Chair Chair Chairperson of the change control board;
generally has final decision-making authority if the CCB does not reach agreement.
CCB The group that decides to approve or reject proposed changes for a specific project.
Evaluator The person whom is asked to analyze the impact of a proposed change; could be a technical person, a customer, a marketing person, or a combination
45
The Change Control Board – Roles and Responsibilities (continued)
Role Description and ResponsibilitiesModifier The person responsible for making changes in a
work product in response to an approved change request.
Originator Someone who submits a new change request.
Request Receiver
The person to whom new change requests are submitted
Verifier The person who determines whether the change was made correctly
46
Change Control Tool Features • Define the data items included in a change request • Define a state-transition model for the change-
request life cycle• Enforce the state-transition model, allowing only
authorized users to make status changes • Record the date of every status change and the
identity of the person who made it • Define who receives automatic e-mail notification
when an originator submits a new request or when a request's status is updated
• Produce Reports and Charts
47
Change Isn’t Free – Impact Analysis • Impact analysis - key aspect of requirements
management
• Provides an understanding of the implications of a proposed change
• Helps the team make informed business decisions about which proposals to approve
48
Impact Analysis • Impact analysis has three aspects:
1. Understand the possible implications of making the change.
2. Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.
49
Impact Analysis – Questions / Checklists
• A checklist of questions designed to help the impact analyst understand the implications of accepting a proposed change. (handout)
• A checklist of possible software elements affected by a proposed change (handout)
• Change Effort Estimate worksheet (handout)
50
Impact Analysis Procedure 1. Work through the Impact Analysis Checklist.
2. Work through the Possible Software Elements Affected Checklist, using available traceability information.
3. Use the Change Effort Estimate worksheet to estimate the effort required for the anticipated tasks.
4. Total the effort estimates.
5. Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
51
Impact Analysis Procedure 6. Determine whether the change is on the project's critical
path.
7. Estimate the impact of the proposed change on the project's schedule and cost.
8. Evaluate the change's priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
9. Report the impact analysis results to the CCB so that they can use the information to help them decide whether to approve or reject the change request.
52
Chp 19: Change Happens – Summary (1)
• It's virtually impossible to define all of a product's requirements up front, and the world changes as development progresses.
• Some requirements evolution is legitimate, unavoidable, and even advantageous.
• The most effective technique for controlling scope creep is being able to say “no”.– Nice way to say no – say “not now”.
53
Chp 19: Change Happens – Summary (2)
• Effective techniques for controlling scope creep.– Prototyping– Using short development cycles
• A change-control process lets the project's leaders:– make informed business decisions that will provide the
greatest customer and business value– control the product's life cycle costs– track the status of all proposed changes– it helps ensure that suggested changes aren't lost or
overlooked
54
Chp 19: Change Happens – Summary (3)
• The key to a successful Change Control Process – well documented – as simple as possible– above all — effective
• The Change Control Board is the body of people (one person or a group), who decides which proposed requirement changes and newly suggested features to accept for inclusion in the product.
55
Chp 19: Change Happens – Summary (4)
• (Requested Change) Impact analysis - key aspect of requirements management1. Understand the possible implications of making the
change. 2. Identify all the files, models, and documents that might
have to be modified if the team incorporates the requested change.
3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.
56
Software Requirements:
Chp 20: Links in the Requirements Chain
57
Tracing Requirements• Requirements tracing documents the dependencies and
logical links between individual requirements and other system elements.
• System elements include other requirements of various types:– Business Rules– Architecture and other design components– Source Code Modules– Test cases– Help files
• Traceability information facilitates impact analysis by helping identify all the work products you might have to modify, to implement a proposed requirement change.
58
Tracing Requirements (continued)• To permit traceability, each requirement must
be uniquely and persistently labeled so that it can be (uniquely ) identified.
• Write the requirements in a fine-grained fashion, rather than creating large paragraphs containing many individual functional requirements that lead to an explosion of design and code elements.
59
Four Types Requirements Traceability
60
Possible Requirements Traceability Links
61
Benefits of Tracing Requirements• Certification - for a safety-critical product, can use
traceability information to demonstrate that all requirements were implemented.
• Change impact analysis – without traceability information, there's a high probability of overlooking a system element that would be affected if you add, delete, or modify a particular requirement.
• Maintenance - Reliable traceability information facilitates making changes correctly and completely, which improves your productivity. A table that shows where each applicable business rule was implemented in the functional requirements, designs, and code makes it easier to make the necessary changes properly.
62
Benefits of Tracing Requirements• Project tracking - recording traceability data during
development, will provide an accurate record of the implementation status of planned functionality.– Missing links indicate work products that have not yet been created.
• Reengineering - listing the functions in a legacy system you're replacing and recording where they were addressed in the new system's requirements and software components.– Defining traceability links is a way to capture some of what you learn
through reverse engineering of an existing system.
• Reuse - identifies packages of related requirements, designs, code, and tests.
63
Benefits of Tracing Requirements
• Risk reduction - Documenting the component interconnections reduces the risk if a key team member with essential knowledge about the system leaves the project.
• Testing - When a test yields an unexpected result, the links between tests, requirements, and code point you toward likely parts of the code to examine for a defect. – Knowing which tests verify which requirements can save time by
letting you eliminate redundant tests.
64
Requirements Traceability Matrix
User Requirement
Functional Requirement
Design Element
Code Module Test Case
UC-30 catalog.query.sort Class catalog catalog.sort() search.9Search.10
UC-31 catalog.query.import Class catalog catalog.import()catalog.validate()
search.15Search.16Search.17
65
Requirements Traceability Matrix
• Fill in the information as the work gets done, not as it gets planned. – Enter "catalog.sort()" in the Code Module column
of the first row of the matrix only when the code in that function has been written, has passed its unit tests, and has been integrated into the source code baseline for the product.
66
Requirements Traceability Matrix
• Nonfunctional requirements such as performance goals and quality attributes don't always trace directly into code. – A response-time requirement might dictate the use of certain
hardware, algorithms, database structures, or architectural choices.– A portability requirement could restrict the language features that the
programmer uses but might not result in specific code segments that enable portability.
– Integrity requirements for user authentication lead to derived functional requirements that are possibly implemented passwords or biometrics functionality.
• Where possible trace the corresponding functional requirements backward to their parent nonfunctional requirement and forward into down stream deliverables as usual.
67
Sources of Traceability Link InformationLink Source Object Type Link Target Object Type Information Source
System Requirement Software Requirement Systems Engineer
Use Case Functional Requirement Requirements Analyst
Functional Requirement Functional Requirement Requirements Analyst
Functional Requirement Test Case Test Engineer
Functional Requirement Software Architecture Element
Software Architect
Functional Requirement Other Design Elements Designer or Developer
Design Element Code Developer
Business Rule Functional Requirement Requirements Analyst
68
Requirements Traceability Procedure
1. Select the link relationships you want to define from the possible Requirements Traceability links (slide 60).
2. Determine the format of the traceability matrix (slide 64 ). - Select a mechanism for storing the data: a table in a text document, a spreadsheet, or a requirements management tool.
3. Identify the parts of the product for which you want to maintain traceability information. - Start with the critical core functions, the high-risk portions, or the portions that you expect to undergo the most maintenance and evolution over the product's life.
69
Requirements Traceability Procedure4. Modify your development procedures and checklists to
remind developers to update the links after implementing a requirement or an approved change.- The traceability data should be updated as soon as someone completes a task that creates or changes a link in the requirements chain.
5. Define the tagging conventions you will use to uniquely identify all system elements so that they can be linked together.
6. Identify the individuals who will supply each type of link information and the person who will coordinate the traceability activities and manage the data.
70
Requirements Traceability Procedure7. Educate the team about the concepts, objectives, and
importance of requirements tracing, where the traceability
data is stored, and the techniques for defining the links. -Make sure all participants commit to their responsibilities.
8. As development proceeds, have each participant provide the requested traceability information as they complete small
bodies of work.
9. Audit the traceability information periodically to make sure it's being kept current.
71
Chp 20: Links in the Requirements Chain – Summary (1)• Requirements tracing documents the dependencies
and logical links between individual requirements and other system elements.
• Traceability information facilitates impact analysis by helping identify all the work products you might have to modify, to implement a proposed requirement change.
• Implement, communicate and follow a Requirements Traceability Procedure.
72
Chp 20: Links in the Requirements Chain – Summary (2)• Benefits of Tracing Requirements (helps with):– Certification– Change impact analysis– Maintenance– Project Tracking– Reengineering– Reuse– Risk Reduction– Testing
73
Software Requirements:
Chp 22: Improving Your Requirements
74
Improving the Requirement Process
• The ultimate objective of software process improvement is to reduce the cost of creating and maintaining software. There are several ways to accomplish this: – Correcting problems encountered on previous or current
projects that arose from process shortcomings – Anticipating and preventing problems that you might
encounter on future projects – Adopting practices that are more efficient than the
practices currently being used
75
Requirements Relationship to other Processes
76
• This slide is intentionally left blank
77
Requirements and various Stakeholders
78
Process Improvement Fundamentals
1. Process improvement should be evolutionary, continuous, and cyclical.
2. People and organizations change only when they have an incentive to do so.
3. Process changes should be goal-oriented. Before you begin the journey to superior processes, make sure that you know where you're headed.
4. Treat your improvement activities as mini projects.
79
Process Improvement Lifecycle
80
Process Improvement Lifecycle - Step 2: Plan Improvement Actions
81
Process Improvement Lifecycle:Step 2: Plan Improvement - Action ItemsAction Items for Requirements Management Improvements
1. Draft a requirements change-control procedure. 2. Review and revise the change-control procedure. 3. Pilot the change-control procedure with Project “A”. 4. Revise the change-control procedure based on feedback from
the pilot. 5. Evaluate problem-tracking tools, and select one to support
the change-control procedure. 6. Procure the problem-tracking tool, and customize it to
support the change-control procedure. 7. Roll out the new change-control procedure and tool to the
organization.
82
Process Improvement Lifecycle: Step 3: Create, Pilot, and Implement New ProcessesSuggestions for Pilot Initiatives: • Select pilot participants who will give the new approaches a
fair try and provide helpful feedback.. • To make the outcome easy to interpret, quantify the criteria
the team will use to evaluate the pilot. • Identify the stakeholders who need to be kept informed of
what the pilot is about and why it is being performed. • Consider piloting portions of the new processes on different
projects. This engages more people in trying new approaches, which increases awareness, feedback, and buy-in.
• As part of the evaluation, ask pilot participants how they would feel if they had to go back to their former ways of working.
83
Process Asset DocumentsType Description
Checklist A list that enumerates activities, deliverables, or other items to be noted or verified. Checklists are memory joggers. They help ensure that busy people don't overlook important details.
Example A representative of a specific type of work product. Accumulate good examples as your project teams create them.
Plan An outline of how an objective will be accomplished and what is needed to accomplish it.
Policy A guiding principle that sets a management expectation ofbehaviors, actions, and deliverables. Processes should enablesatisfaction of the policies.
84
Process Asset DocumentsType Description
Procedure A step-by-step description of the sequence of tasks thataccomplishes an activity. Describe the tasks to be performedand identify the project roles that perform them. Don't includetutorial information in a procedure. Guidance documents cansupport a process or procedure with tutorial information andhelpful tips.
Process Description
A documented definition of a set of activities performed forsome purpose. A process description might include the processobjective, key milestones, participants, communication steps, input and output data, artifacts associated with the process, andways to tailor the process to different project situations.
85
Process Asset DocumentsType Description
Template A pattern to be used as a guide for producing a complete workproduct. Templates for key project documents remind you to ask questions that you might otherwise overlook. A well-structured template provides many "slots" for capturing and organizing information. Guidance text embedded in thetemplate will help the document author use it effectively.
86
Requirements Engineering Process AssetsRequirements Development Process Assets
• Requirements Development Process • Requirements Allocation Procedure• Requirements Prioritization Procedure• Vision and Scope Template • Use-Case Template • Software Requirements Specification Template• SRS and Use-Case Defect Checklists
87
Requirements Engineering Process AssetsRequirements Management Process Assets
• Requirements Management Process• Change-Control Process• Requirements Status-Tracking Procedure• Requirements Traceability Procedure• Change Control Board Charter• Requirements Change Impact Analysis Checklist and Template
88
Requirements Process Improvement Road Map
89
Chp 22: Improving Your Requirements– Summary • Objective of software process improvement is
to reduce the cost of creating and maintaining software.
• Process Improvement Fundamentals - Slide 78
• Requirements Development Process Assets - Slide 86
• Requirements Management Process Assets - Slide 87
90
Software Requirements:
Chp 23: Software Requirements and Risk
91
Software Requirements & Risk Management• Risk - A risk is a future, uncertain condition that could cause
some loss or otherwise threaten the success of a project.
• If something problematic has already happened on your project, it's an issue or a problem, not a risk.
• Risk management – the process of identifying, evaluating, and controlling risks
before they damage your project – application of tools and procedures to contain project risk
within acceptable limits – provides a standard approach to identify and document
risk factors, evaluate their potential severity, and propose strategies for mitigating them
92
Goals of Risk Management• Address risks proactively using generally accepted
techniques• Evaluate and prioritize risks so scarce resources can
manage them• Plan Risk Management activities• Assign Responsibilities for risk management
functions• Report the status of risks to management on a timely
basis• Develop and actively manage mitigation and
contingency strategies for the most significant risks
94
Sources of Risk • Historical project data• Current project planning data • Interviewing personnel with experience in similar
projects • Interviewing personnel with experience with the
client
• General Categories of Risk: – Staffing – Project Definition– Project Management– Technical
95
Elements of Risk Management
96
Risk Tracking Template / Risk Log
97
Requirements Related Risks• Requirements Elicitation– Product Vision and Product Scope– Time spent on requirements development– Completeness and correctness of requirements
specifications– Requirements for highly innovative products– Defining nonfunctional requirements– Customer agreement on product requirements– Unstated requirements– Existing product used as the requirements baseline– Solutions presented as needs
98
Requirements Related Risks• Requirements Analysis– Requirements prioritization– Technically difficult features– Unfamiliar technologies, methods, languages,
tools, or hardware – Requirements understanding– Time pressure to proceed despite TBDs– Ambiguous terminology– Design Included in requirements
99
Requirements Related Risks• Requirements Validation– Unvalidated requirements – Inspection proficiency
• Requirements Management – Changing requirements – Requirements change process– Unimplemented requirements– Expanding project scope
100
Chp 23: Software Requirements and Risk – Summary (1)• Goals of Risk Management - Slide 92• Requirements Elicitation Related Risks
- Slide 97• Requirements Analysis Related Risks - Slide 98• Requirements Validation Risks - Slide 99• Requirements Management Risks - Slide 99