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


• Change Control – Proposing changes– Analyzing impact– Making decisions– Updating requirements documents– Updating plans– Measuring requirements volatility

7


• Version Control – Defining a version identification scheme– Identifying requirements document versions– Identifying individual requirement versions

8


• Requirements Status Tracking – Defining possible requirements statuses– Recording the status of each requirement – Reporting the status distribution of all

requirements

9


• 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


• 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


• 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 Activities /Effort– Submitting requirements changes and proposing

new requirements – Evaluating proposed changes, including

performing impact analysis – Change control board activities

25


• 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


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


• 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


• 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


• (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


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


• 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


• 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


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


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


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


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

93

Risk Management Plan

http://www.shamsherhaider.com/site_imgs/risk_process.jpg

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