“Requirement Management & Product Quality” in the context of managing development projects Grace Shi, MBA, PMP Sr. Project Manager VanQ Society, BCIT Campus,

“Requirement Management & Product Quality” in the context of managing development projects

Grace Shi, MBA, PMP

Sr. Project Manager

VanQ Society, BCIT Campus, Thurs Feb 22nd, 2007

ACS

Applied Concept Solutions Inc. 2

http://www.flickr.com/photos/osilla/80500328/

http://www.flickr.com/photos/osilla/80500328/


A Need

Requirements Design

Code Build

Test

Real Need? Right

req’ts?

right design? Same need?Problematic??


ACS


Agenda

To discuss about requirement management– What is it?– Why is it important?– Relation to product quality, i.e. QA– “as is” - Where we are at?– “to be” - Where we should go?

Key words – Requirement management– Product quality

ACSObjective


Agenda

1. What is requirement management?

2. Why do we need requirement management?

3. Why requirement management can impact product quality? and how?

4. What is the current status?

5. What is the desired future state?

6. Workshop and open discussion

ACSAgenda


Business wants IT as a supporting organization to do something to help – Increase resources productivity – lower cost– Increase production efficiency – lower cost– Assist delivery new products/services – competitive edge– Provide better services to the customers – sustain market share– Improve (automate, streamline) the business processes – lower cost

Examples– New product – innovation– A feature – what is needed is clearly defined (e.g. add a FAQ to an

online order system.)– Process improvement – only the outcome is defined, but may not be

quantitatively (e.g. website performance should be faster)

ACS1. What is requirement management?

Business definition


• In software engineering, a requirement is a description of what a system should do. Systems may have from dozens to thousands of requirements. http://en.wikipedia.org/wiki/requirements

ACS

System XYZ

A

B

C

In great details:– What the following should do:

• XYZ output and input• Components A, B, C• Interfaces between A, B, C

– When to do what– Under what circumstances– (Why and with Whom)

For large systems, the sum can be hundreds thousands


System definition

http://en.wikipedia.org/wiki/requirements


• Here come the challenges:

– How to translate the business need to system requirements precisely so that they both work in their own contexts systematically (the business need makes sense to business people and it is also aligned to the corporate goal and it is doable; the system requirements make sense to IT people and the impacts are manageable and it is feasible to implement technically)

– How to break down the system requirements to an appropriate level at which the business need can be validated.

ACS1. What is requirement management?

Challenges!


Agenda







ACSAgenda


• System requirements characteristics

– Correct

– Complete

– Testable

– Unambiguous

• Business needs characteristics

– There is no right or wrong

– Descriptive

– Drive is not mentioned nor obvious

– Big picture behind

– Multiple contexts

– Sometime the real need is not what is described

ACS2. Why requirement management?

A Chasm!


• Changes are inevitable!

– Market

– Competitor

– Technology

– Client initiated

– Mistaken requirements discovered later

• To simply lock up the requirements is not in the best interest of business

• Changes may occur any time in the lifecycle


Changes!


• Lifecycle requirement management Concept

– Gathered – analyzed – negotiated – modeled – verified – defined – documented - signed-off

– Linked

– Changed, tested, released

– Controlled, traced, and managed


Lifecycle Concept!


• Management offers a means of

– tracking

– monitoring,

– Updating

– Controlling

• To ensure

– First time right, remember the chasm?

– Changes over lifecycle

– Complexity and interdependency between phases and deliverables

• The conclusion: We need requirement management!


The Conclusion


• Techniques to make “first time right”

• Techniques to manage requirement changes

• Techniques to manage requirements in the project lifecycle

• Use tools to manage requirements

• Who owns of requirement management?

• Who is accountable for requirement management?

• What does a project manager need to do in requirement management?

• The qualifications of a competent Business Analyst

• Requirement management and product quality

• How requirement management can impact project on time delivery

• How requirement management can impact project on budget delivery


Areas of Discussions


Agenda







ACSAgenda


• Customers’ perception• Customers’ expectation against their own experiences of

– Of a known brand

– Of the same brand but different product

– Over competitors’ similar offerings

• Within the development picture– Quality is the degree to which the pre-defined requirements are met

– Defect is used as a measurement

ACS3. Requirement Management & Product Quality

What is quality?


• Defects

• The GOAL is to– Decrease the # of defects– Find as many defects as early as possible in work products while running

scenarios before the product is shipped out of the door

ACS

Defects found by the real users

shipment/release date

Fix or Defer

Defects found by QA

Release

ReworkCostly!

NegativeImpactWorse!

3. Requirement Management & Product Quality

Product Quality


• Defects breakdown:– Requirements management 62.5% – Design 11.3% – Coding 10% – Environment 4.9% – Test data or test scripts or execution errors 11.3%

• Requirement management defects breakdown: – Requirement Completeness 37.5% – Requirement Presentation 34.7% – Requirement Changes 11.2% – Requirement Incorrect 8.7%

• Requirement Completeness defects breakdown:– Incomplete Requirements 73.4% – Missing requirements 11.2% – Overly generalized requirements 4.6%

-- “Defect Prevention Techniques for High Quality and Reduced Cycle Time” http://www.iscn.ie/select_newspaper/measurement/motorola2.html


Defect Origins

http://www.iscn.ie/select_newspaper/measurement/motorola2.html


ACS

Defect Origins BreakdownRequirementCompleteness

RequirementPresentation

RequirementChanges

RequirementIncorrect

3. Requirement Management & Product Quality

Defect Origins Breakdowns


• Have we found all the defects?

– All requirements tested? If not, why not all?

– All changed requirements and affected requirements tested?

– How to make the tradeoff when required? What are the factors?

• Have we fixed all the found the defects?

– What to defer and what to fix?

– What are the factors (business, blocking issues)?

– How do we know the fixes are real? Have we retested all the fixed?

– How do we know the fixes don’t break something else? Have we regression-tested all the fixed?

– How to make the tradeoff when required? What are the factors?

• Have we implemented all the fixes? In which releases?

• Hidden defects?!


The Correlation


• A sub-project that contains all the components– Plan and analysis– Design and build– Test and integration

• Mostly derived from defects– Missing requirements– Incomplete requirements– Incorrect requirements

• New requirements• Changed requirements and affected requirements• Make the changes and integrate the changes into the system• How to plan testing – test coverage, regression test, scenario design


Change Requests



Systematic Approach

Test Execution

Req’t Mgmt Change Mgmt

Defect Mgmt Test Planning

Release MgmtReq’t repository CR repository

Scripts repositoryDefect repository

Defect fixing Team


Agenda

1. What is requirement management






ACSAgenda


ACTIVITIES “AS IS"

requirement gathering be told or be supplied with a list

requirement analyzing business impact, technology feasibility, time/cost constraints

requirement modelling very rare (needs analytical skill and IT knowledge)

requirement negotiating very rare (needs thorough understanding and real care)

change tracking some change requests are managed in some companies.

change tracing Rare

lifecycle linkage Rare

use of tools Word, Excel, occasionally Visio

documentation some do, mostly don't, no documentation management

accountability seems like no one is accountable?

ownership Business Analyst?

accessibility in different places, not everyone has access

QA manager not involved until later phases

Product manager mostly only involved at beginning, then hands-off.

The Client mostly only involved at beginning, then hands-off.

Business Analysts new profession; individual's capability varies greatly


ACTIVITIES “TO BE"

requirement gathering interactive, partnering with the client

requirement analyzing business impact, technology feasibility, time/cost constraints

requirement modelling prototype, storyboard, prove of concept, test of the design

requirement negotiating consultant mentality, honest about what is the best

change tracking change management, change control board

change tracing horizontally across the system, through phases

lifecycle linkage through phases

use of tools utilize the most compelling technology that suits the nature

documentation everything is documented and managed completely

accountability Every stakeholder

ownership Every stakeholder

accessibility Every stakeholder

QA manager Completely involved, end to end.

Product manager Completely involved, end to end.

The Client Completely involved, end to end.

Business Analysts a discipline; capable and competent


Agenda

• To discuss requirement management

– What is it? – first time right, lifecycle concept, manage change

– Why is it important? – project success

– “as is” - Where we are at? – not managed

– Impact on QA – high # of bugs, design change, change requests

– Impact on project – delay (then over budget)

– “to be” - Where we should go? – fully managed

• Key words

– Requirement Management

– Product Quality

ACSReview


Agenda







ACSAgenda


Agenda

• The project:The project MyHomeDVD is to deliver a simple web-based movie library management application for the family members who can browse their own records including the movies borrowed and the due dates for the borrowed movies.

• The project status:The coding phase is completed and the integration test is done. Based on the pre-defined test cases, 2 defects are found. After a thorough investigation, 1 of the 2 defects is not valid – the defect is caused by a missing requirement (e.g. forgot the Logoff button). After negotiating with the key stakeholders, it is agreed that it is critical to implement the missing requirement. As a result, CR101 is raised.

• The question:If you take over the project right at this moment, what are those key things that you would like to do?

• Your action items:Please discuss this with your group to come up with a summary. Then each group presents the summary to the audience.

• Hints:Focus on requirement change management, think of the requirement repository, affected requirements, test plan and test cases.

ACSWorkshop – Scenario #1

Documents

“Requirement Management & Product Quality” in the context of managing development projects Grace Shi, MBA, PMP Sr. Project Manager VanQ Society, BCIT Campus,