Chapter Note

chapter32.pdf

Chapter 32 Software Requirements and Risk Management

1. Fundamentals of Software Risk Management

 Elements of Risk Management - Risk Assessment (identification, analysis,

prioritization) - Risk Avoidance - Control (Planning, Resolution, Monitoring)  Documenting the Risks: use of a template

1.1 An approach for Risk Management

1.2 Documenting Risks

2. Requirement Related Risks

Risks based on the sub-disciplines of elicitation, analysis, specification, validation and management.

2.1 Elicitation

 Vision and project scope: lack of clear understanding

 Time spent of requirement development : too tight schedule

 Completeness and correctness of requirements specification

 Requirements for highly innovative products

 Defining nonfunctional requirements : easy to neglect

 Customer agreement on product requirements

 Unstated requirements: implicit expectation of the customer

 Existing product used as the baseline: need reverse engineering

 Solution presented as needs: user-proposed solutions can mask the uders’ actual needs

2.2 Analysis

 Prioritizations : ensure every requirement is prioritized and allocated to a release

 Technically difficult features: evaluate the feasibility/difficult of each requirements

 Unfamiliar technologies, methods, languages, tools or hardware:

need time to learn all different issues

2.3 Specification

 Requirements understanding : make sure the stake-holders have same understanding of requirements

 Time pressure: to proceed without completing TBD areas

 Ambiguous terminology: create a glossary to define the terms

 Design included in requirements: can constrain inhibit creation of optimal design

2.4 Validation

 Un-validated requirements: include time and resource to do this activity, otherwise pressure may cause incomplete validation

 Inspection proficiency: need qualified inpectors

2.5 Management

 Changing Requirements: : reduce scope creep, reduce change modifications

 Requirements Change Process: risk related to the way changes to requirements are handled

 Unimplemented requirements: requirements traceability matrix can help to not to overlook any un-implemented requirement

 Expanding project scope: poorly defined requirements or vaguely specified will consume time and efforts.

E N D