De 201 Requirements Management

Requirements Management Education & Research

1

De 201 / De Bridge - Framework

2

2

Objectives • •

Understand the importance of requirements management Understand how to manage requirements – Change control – Version control – Requirements traceability and its importance

•

Know the tools available for requirements management

3

3

Requirements Management & CMM • •

CMM L2 : Requirements Management [SG 1] Manage Requirements – “Requirements are managed and inconsistencies with project plans and work products are identified”.

•

Practices – – – – –

[SP 1.1] Obtain an Understanding of Requirements Establishing Good Requirements [SP 1.2] Obtain Commitment to Requirements [SP 1.3] Manage Requirements Changes Controlling the Changes [SP 1.4] Maintain Bidirectional Traceability of Requirements Controlling the Implementation [SP 1.5] Identify Inconsistencies between Project Work and Requirements

(Maintaining Versions and Traceability)

4

4

Activities • • • • •

Controlling changes to requirements baseline Ensuring agreed changes are incorporated in to product/service Controlling version of each requirement and documents Maintaining traceability between requirements and products Tracking status of requirements in baseline

5

5

Change Control – Some drivers • • • • • •

Changes are going to be there Change has an Impact…could be complex Right people need to be involved in a change All changes should be tracked and closed Record of change is needed and in one place Uncontrolled changes lead to: – Project chaos – Schedule slips – Quality problems

•

Requirements documents should be able to accurately describe the delivered product

6

6

Change Management Process Activities ¾Log the change ¾Analyse the Impact with respect to Schedule, Cost, and Effort ¾Analyse Risks associated with the change ¾Present the Completed Change Assessment to customer ¾Get Sign off on the Change Request ¾Update Project plan, budget, and schedule accordingly ¾Implement the change as part of the project

+Define a threshold for pricing +Establish change control board, if needed +Include the amendment information in status report You can say “NO” to changes! 7

7

Negotiating Change Requests • • • • •

Relate the change to the objectives Assess complexity and risks; communicate. Assess work around possibilities Do not handle change as a quick fix! If you are unsure, then it is a needed change!

8

8

Adopting the changes • •

Obtain explicit signoff (or reverse signoff) To quickly identify the impacted deliverables: – Use traceability Matrix or RM tool – Do brainstorming with the team

• • •

Ensure that a given change does not contradict existing requirement When a request impacts a work product in progress, incorporate the change if it is pertinent to the work being done right then Otherwise, consider incorporating the change, after bringing the current module to a logical conclusion

9

9

Traceability • •

Bidirectional traceability between multiple levels of requirements, design, code and test plans What can go wrong if traceability is not maintained? – – – – – –

Incomplete translation of requirements to work products Incomplete impact analysis of a change Working on something which is not part of the requirement! Lack of visibility to common code/functions Impact on ability to prioritise tasks Impact on ability to negotiate change requests

10

10

Requirements Traceability Matrix

Use Case

Functional Requirement

Design Element

Code

Test Case

UC07-SortPrd Sort Product List

Module Product PrdSort(mode) PlaceOrder/#7 Maintain PlaceOrder/#8

UC08-AddSKU Accept SKU from user & add to db

Module Product AcceptSKU(p) SkuMaint/#12 Maintain ValidateSKU(p) SkuMaint/#13 SkuMaint/#14 AddSKU(p) SkuMaint/#15

11

11

Version Control • •

Unique identity for each version of a requirement Access to latest version

12

12

Version Control (Contd.) •

Attributes of a requirement – – – – – – – – –

Date the requirement was created Version number of the requirement Author who created it Priority or importance to the product Status of the requirement Origin or reasons which describes its need Subsystem to which the requirement is allocated Verification method or acceptance test criteria Version details • • • •

A revision history Revision date Individual who made the change Reasons for change

13

13

Tools for Requirement Management •

Necessity for a tool – – – – – –

•

Keeping up-to-date Communication of change Versioning Maintaining traceability Tracking the status Access/concurrency control

The different types of tools available are – Database-centric and document-centric

•

Detailed survey of commercial RM tools at: – http://www.paper-review.com/tools/rms/read.php

14

14

RM Tools •

•

Database-centric – –

Caliber-RM by Borland : http://www.borland.com/us/products/caliber/

– –

DOORS by Telelogic : http://www.telelogic.com/products/doorsers/

–

RTM Workshop by Integrated Chipware : http://www.inbis.com/software/rtm/rtm_workshop.htm

Document-centric – –

RequisitePro by IBM : http://www-306.ibm.com/software/rational/

15

15

Summary • • • • • •

Getting good requirement is both art and science Stakeholders management is very important component of requirements management Changes should undergo formal process You can negotiate a change request Traceability and versioning is needed to maintain consistency Tools can help you manage requirements well

16

16

Thank You

17

Need for change • •

Incomplete requirement articulation Scope creep

• • • •

Evolving requirement Business changes Better understanding of the need over time Constraints needing work around

18

18

Scope creep cases: 1. User Interface (UI) requirements Requirement: • Customer wanted to re-engineer their existing VB application to intranet. Vendor was asked to give a quote before prototyping of UIs. However vendor had the screen shots of customer’s VB application. To understand the relative complexity of intranet screens, vendor wanted to know whether customer wanted highly sophisticated UI interface or VB like look and feel would be enough. Customer confirmed to them that they are ok with VB look and feel. Scope assumed: • UI experience design was assumed to be simple and vendor did not budget time of any UI specialist for the job. Customer was told that screens layouts will resemble their existing screens. •

What could go wrong with this scope management?

19

19

Scope creep – Case studies

20

20

What all could get impacted by a change? Business Requirements

Security requirements Performance requirements

Business Req doc

Information Requirements

User Requirements

Reliability requirements

UI requirements System Requirements

Use-Case doc

Data Model

System Constraints

Functional Requirements

Non-functional requirements

Software Requirements Specification 21

21

What all could get impacted by a change?...2

Requirement

Impact

Design

Code

Integrated System

22

22

Change request – Example #1 Original request: • In the search functionality, selection of stream is a mandatory field which is a radio button. The records are displayed as line items based on the search criteria. Pagination and sorting is also a criteria. Change request: • Customer wanted to remove the stream selection criteria by removing the radio button. Impact Analyzed: • Remove the radio button • Change logic to fetch records unconditionally What could go wrong?

23

23

Cost of changes to requirement Requirements Time

0.1 - 0.2 0.5

Design

1

Coding Unit Test

2 5

Acceptance Test

20

Maintenance

Cost of fixing a requirement varies…who will pay for it? 24

24