Get documents about "req eng mgmt
Document Sample
Software Requirements, 2nd Edition:
by Karl E. Wiegers
Chp 18: Requirements Management Principles and Practices
Chp 19: Change Happens
Chp 20: Links in the Requirements Chain
Chp 22: Improving Your Requirements
Chp 23: Software Requirements and Risk
Gregory (Greg) Maltby, PMP, BSCS
April 13, 2010
EECS 812
1
Software Requirements:
Chp 18: Requirements Management
Principles and Practices
2
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.
3
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.
4
Requirements Management Activities
5
Requirements Management Activities
• Change Control
– Proposing changes
– Analyzing impact
– Making decisions
– Updating requirements documents
– Updating plans
– Measuring requirements volatility
6
Requirements Management Activities
• Version Control
– Defining a version identification scheme
– Identifying requirements document versions
– Identifying individual requirement versions
7
Requirements Management Activities
• Requirements Status Tracking
– Defining possible requirements statuses
– Recording the status of each requirement
– Reporting the status distribution of all
requirements
8
Requirements Management Activities
• Requirements Tracing
– Defining links to other requirements
– Defining links to other system elements
9
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
10
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
11
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.
12
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
13
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.
14
Requirements Version Control
It'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 a
client. The contract team was perplexed—the system had passed all their
own 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, all
because of a version control problem.
15
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
16
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
17
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
18
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
19
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
20
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)
21
Tracking Requirements Status
Status 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.
22
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.
23
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
24
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
25
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
26
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.
27
Software Requirements:
Chp 19: Change Happens
28
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.
29
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.
30
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.
31
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.
32
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
33
The Change Control Process
• The key to a successful Change Control
Process –
– well documented
– as simple as possible
– above all — effective.
34
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.
35
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.
36
The Change Control Description
1. Introduction
– 1.1 Purpose
– 1.2 Scope
– 1.3 Definitions
2. Roles and Responsibilities
3. Change-Request Status
4. Entry Criteria
37
The Change Control Description
5. 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
38
The Change Request Lifecycle
39
Suggested Change Data Request Items
Item Description
Change Functional area that requested the change; possible groups include marketing,
Origin management, customer, software engineering, hardware engineering, and testing
Change- Identification tag or sequence number assigned to the request
Request ID
Change Type of change request, such as a requirement change, a proposed enhancement,
Type or a defect report
Date Date the originator submitted the change request
Submitted
Date Date the change request was most recently modified
Updated
Description Free-form text description of the change being requested
Implementa The relative importance of making the change as determined by the CCB: low,
-tion Priority medium, or high
Modifier Name of the person who is primarily responsible for implementing the change
40
Suggested Change Data Request Items
Item Description
Originator Name of the person who submitted this change request; consider
including the originator's contact information
Originator The relative importance of making the change from the originator's point
Priority of view: low, medium, or high
Planned Product release or build number for which an approved change is
Release 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
41
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.
42
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
43
The Change Control Board –
Roles and Responsibilities
Role Description and Responsibilities
CCB 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
44
The Change Control Board –
Roles and Responsibilities (continued)
Role Description and Responsibilities
Modifier 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 The person to whom new change requests are
Receiver submitted
Verifier The person who determines whether the change
was made correctly
45
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
46
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
47
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.
48
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)
49
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.
50
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.
51
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”.
52
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
53
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.
54
Chp 19: Change Happens – Summary (4)
• (Requested Change) Impact analysis - key aspect of
requirements management
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.
55
Software Requirements:
Chp 20: Links in the Requirements Chain
56
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.
57
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.
58
Four Types Requirements Traceability
59
Possible Requirements Traceability Links
60
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.
61
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.
62
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.
63
Requirements Traceability Matrix
User Functional Design Code Module Test Case
Requirement Requirement Element
UC-30 catalog.query.sort Class catalog catalog.sort() search.9
Search.10
UC-31 catalog.query.import Class catalog catalog.import() search.15
catalog.validate() Search.16
Search.17
64
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.
65
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.
66
Sources of Traceability Link Information
Link 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 Software Architect
Element
Functional Requirement Other Design Elements Designer or Developer
Design Element Code Developer
Business Rule Functional Requirement Requirements Analyst
67
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.
68
Requirements Traceability Procedure
4. 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.
69
Requirements Traceability Procedure
7. 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.
70
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.
71
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
72
Software Requirements:
Chp 22: Improving Your Requirements
73
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
74
Requirements Relationship to other Processes
75
• This slide is intentionally left blank
76
Requirements and various Stakeholders
77
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.
78
Process Improvement Lifecycle
79
Process Improvement Lifecycle -
Step 2: Plan Improvement Actions
80
Process Improvement Lifecycle:
Step 2: Plan Improvement - Action Items
Action 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.
81
Process Improvement Lifecycle:
Step 3: Create, Pilot, and Implement New
Processes
Suggestions 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.
82
Process Asset Documents
Type 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 of
behaviors, actions, and deliverables. Processes should enable
satisfaction of the policies.
83
Process Asset Documents
Type Description
Procedure A step-by-step description of the sequence of tasks that
accomplishes an activity. Describe the tasks to be performed
and identify the project roles that perform them. Don't include
tutorial information in a procedure. Guidance documents can
support a process or procedure with tutorial information and
helpful tips.
Process A documented definition of a set of activities performed for
Description some purpose. A process description might include the process
objective, key milestones, participants, communication steps,
input and output data, artifacts associated with the process, and
ways to tailor the process to different project situations.
84
Process Asset Documents
Type Description
Template A pattern to be used as a guide for producing a complete work
product. 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 the
template will help the document author use it effectively.
85
Requirements Engineering Process Assets
Requirements 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
86
Requirements Engineering Process Assets
Requirements 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
87
Requirements Process Improvement Road
Map
88
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
89
Software Requirements:
Chp 23: Software Requirements and Risk
90
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
91
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
92
Risk Management Plan
93
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
94
Elements of Risk Management
95
Risk Tracking Template / Risk Log
96
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
97
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
98
Requirements Related Risks
• Requirements Validation
– Unvalidated requirements
– Inspection proficiency
• Requirements Management
– Changing requirements
– Requirements change process
– Unimplemented requirements
– Expanding project scope
99
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
100
Related docs
Other docs by aG52zz
Home > Education and Research > Computer Training > CHCS > Nuggets ... - Get Now DOC
Views: 0 | Downloads: 0
