Measuring & Managing Requirement Change for Software Requirements Specifications, Slides of Software Project Management

The importance of measuring change activity in srs and identifies various metrics such as number of change requests, cumulative changes, and change origins. It also emphasizes the importance of traceability and organizing an srs for effective project management.

Typology: Slides

2011/2012

Uploaded on 10/24/2012

gaggan
gaggan 🇮🇳

4.4

(51)

111 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Measuring Change Activity
Is a way to assess the stability of the requirements
and to identify opportunities for process improvement
The following could be measured
The number of change requests received, open, and closed
The cumulative number of changes made including added,
deleted, and modified requirements
The number of change requests that originated from each
source
The number of changes proposed and made in each
requirement since it was base-lined
The total effort devoted to handling changes
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Measuring & Managing Requirement Change for Software Requirements Specifications and more Slides Software Project Management in PDF only on Docsity!

1

Measuring Change Activity

 Is a way to assess the stability of the requirements

and to identify opportunities for process improvement

 The following could be measured

  • The number of change requests received, open, and closed
  • The cumulative number of changes made including added, deleted, and modified requirements
  • The number of change requests that originated from each source
  • The number of changes proposed and made in each requirement since it was base-lined
  • The total effort devoted to handling changes

2 Requirement Change Activity

Weeks after SRS Baselined

Number of proposed changes Comment: Try to fit the slide in a single view/screen (without any scrolling), and kindly be extra careful while plotting the points

4

Traced

An SRS is traced if the origin of its

requirements is clear. That means that the

SRS includes references to earlier supportive

documents

5

Traceable

An SRS is traceable if it written in a manner

that facilitates the referencing of each

individual requirement stated therein

7 Motivation for Requirement Traceability  Certification  Change impact analysis  Maintenance  Project tracking  Reengineering  Reuse  Risk reduction  Testing

Functional Specifications Traceability Matrix Requirement/ Functional Specification Transactions Use Cases GUI Data Flow Diagram Module Test Case ID Estimated Time X Result Bug# Design Quality Assurance

Traceability Matrix

10

How to Organize an SRS?

 Clients/developers may have their own way of

organizing an SRS

 Standard templates developed by:

  • US Department of Defense
  • NASA
  • IEEE/ANSI Standard