SE 313A Operating Systems Unit 1

UN0603Unit 5

Project Scope Management

Dr. J. Michael Bennett, P. Eng., PMP

UNENE, McMaster University, The University of Western Ontario

Version 2K6-IX-18

2K6-IX-18 Dr. J.M. Bennett, P.Eng., PMP UNENE UN06035-2

Unit 5 - Project Scope Management

Revisions

2K6-IX-18 Initial Creation



UN0603 Road MapUnit 1 Introduction to Project ManagementUnit 2 The Project Management ContextUnit 3 Project Management ProcessesUnit 4 Project Integration ManagementUnit 5 Project Scope ManagementUnit 6 Project Cost ManagementUnit 7 Project Time ManagementUnit 8 Project Quality ManagementUnit 9 Project Human Resource ManagementUnit 10 Project Communications ManagementUnit 11 Project Risk ManagementUnit 12 Project Procurement Management



5 Scope & Requirements

5.1 Project Scope Management

5.2 Requirements Management



Scope vs. Requirements

Project Scope – the work that must be done to deliver a product or service

Product Requirements – the features and functions that characterize a product or service



5.1 Scope Planning

5.2 Scope Definition

5.3 Create

WBS

5.4 Scope

Verification

4.4 D&M P. Execution

4.2 Develop

Prelim P. Scope

5.5 Scope Control

Organizational Process Assets

Enterprise Environmental

10.3 Perf Reporting

4.7 Close Project

4.1 Develop

Project Charter 4.3 Develop

PMP

4.6 Int Change

Control

Project Charter



5. Scope Management

5.1.1 Initiation

5.1.2 Scope Planning

5.1.3 Scope Definition

5.1.4 Scope Verification

5.1.5 Scope Change Control



Scope Management Processes

Scope Management

Scope Definition

Scope Verification

Scope Change Crl

Scope PlanningInitiation

5.0

5.55.45.35.25.1




Scope Management

Scope Definition

Scope Verification

Scope Change Crl


5.0

5.55.45.35.25.1

Initiation




Scope Management

Scope Definition

Scope Verification

Scope Change Crl


5.0

5.55.45.35.25.1

Scope Planning




Scope Management

Scope Verification

Scope Change Crl


5.0

5.55.45.35.25.1

Scope Definition




Scope Management

Scope Definition

Scope Verification

Scope Change Crl


5.0

5.55.45.35.25.1

Scope Verification




Scope Management

Scope Definition

Scope Verification

Scope Change Crl


5.0

5.55.45.35.25.1

Scope Change Crl



PMI Project Scope Management

1 Scope Planning.1 Inputs .1 Ent environmental factors .2 Org process assets .3 Charter .4 Prelim scope statement .5 PMP.2 T&T .1 Expert Judgment .2 Templates, forms, stnds.3 Outputs .1 Scope management plan

2 Scope Definition

.1 Inputs .1 Org process assets .2 Charter .3 Prelim scope statement .4 Scope management plan .5 Change requests.2 T&T .1 Product analysis .2 Alternatives id .3 Expert judgment .4 Stakeholder analysis.3 Outputs .1 Scope Statement .2 Requested changes .3 SMP updates

3 Scope Create WBS

.1 Inputs .1 Org process assets .2 Scope statement .3 Scope management plan .4 Approved CRs.2 T&T .1 WBS Templates .2 Decomposition.3 Outputs .1 Scope statement updates .2 WBS .3 WBS dictionary .4 Scope baseline .5 Scope man plan updates .6 Requested changes



PMI Project Scope Management cont.

4 Scope Verification

5 Scope Change Control

.1 Input .1 Scope statement .2m WBS ictionary .3 Scope man plan .4 Deliverables.2 T&T .1 Inspection.3 Output .1 Accepted deliverables .2 Requested changes

.3 Recommended corrective changes

.1 Input .1 Scope statement .2 WBS .3 WBS dictionary .4 Scope man plan .5 Performance reports .6 Approved change requests .7 Work performance info.2 T&T .1 Change control system .2 Variance analysis .3 Replanning .4 Config man system.3 Output .1 Scope statement updates .2 WBS updates .3 WBS dictionary updates .4 Scope baseline updates .5 Requested changes .6 Corrective action .7 Org proc ass updates .8 PMP updates



5.1.1 Initiation

Initiation isProcess of formally authorizing a new project

or

Authorizing that an existing project can continue to its next phase (gating)



In Some Organizations

You first do aNeeds assessment

Feasibility study

Preliminary plan

Some other similar analysis



Project are Authorized because of

A market demand

A business need

A customer request

A technological advance

A legal requirement

A social need



5.1 Scope Planning

1 Project Scope Man Plan

.1 Ent env factors

.2 Org process assets

.3 Project charter

.4 Pre scope statement

.5 PMP

.1 Expert judgment

.2 Templates, forms, standards



Inputs to Scope Planning

.1 Enterprise Environmental Factors

.2 Organizational Process Assets

.3 Preliminary Project Scope Statement

.4 Project Management Plan



.1 Enterprise Environmental Factors

Things that affect how project scope will be managed, such as:Organization’s cultureInfrastructureToolsHuman resourcesPersonnel policiesMarketplace conditions



.2 Organizational Process Assets

The SAM should be here

Formal and informal policies, procedures, guidelines that impact scope management

Org policies as they pertain to scope planning and management

Org procedures as they pertain to scope planning and management

Historical info from previous projects



Other Inputs Already Described

.3 Project Charter

.4 Preliminary Scope Statement

.5 Project Management Plan



Tools and Techniques for Scope Planning

.1 Expert Judgment

.2 Templates, Forms, Standards



.1 Expert Judgment

Use people who have managed equivalent projects to tell you how they did it; what worked; what did not



.2 Templates, Forms, Standards

WBS templates

Scope management plan templates

Project scope change control forms



Outputs from Scope Planning

.1 Project Scope Management Plan



.1 Project Scope Management Plan

Tells how PM team will handle these aspects of project scope:

Scope Definition

Scope Documentation

Scope Verification

Scope Management

Scope Control



PSMP defines Processes to:

Prepare a detailed project scope statement (based on Prelim scope stmt)Create the WBS from the detailed project scope statementSpecify how formal verification and acceptance of project deliverables will be obtainedDetail how change requests will be managed



5.2 Scope Definition

1 Scope stmt2 Changes3 SMP updates


.2 Charter

.3 Prelim scope statement

.4 Scope management plan

.5 Change requests

.1 Product analysis

.2 Alternatives id

.3 Expert judge’t

.4 Stakeholder ana



Inputs to Scope Planning

.1 Organizational process assets

.2 Charter

.3 Preliminary scope statement


.5 Change requests



Inputs to Scope Definition


.2 Charter

.3 Preliminary scope statement


.5 Change requests

Already covered. If Charter and/or SMP are not done, you must find comparable info.



T&T for Scope Planning

.1 Product Analysis

.2 Alternatives Identification

.3 Expert Judgment

.4 Stakeholder analysis



.1 Product Analysis

Develop a better understanding of the product of the project

Could use techniques such asProduct breakdown analysis

Systems engineering

Value engineering

Value analysis

Function analysis

Quality function deployment



.2 Alternatives Identification

Think of other ways of achieving the same ends

UseBrainstorming

Lateral thinking

Story telling

Scenario development



.3 Expert Judgment

As seen



.4 Stakeholder Analysis

What and/or who are Stakeholders?



Stakeholders Requirements

Requirements are refined expectations

Expectations come from Stakeholders

Stakeholders are individuals, groups, organizations that have an interest in the project and can mobilize resources to affect its outcome

PMI “individuals and organizations who are actively involved in the project or whose interests could be positively or negatively affected as a result of the project execution or completion”



Who are these Stakeholders?

Project manager

Team members

Functional members

Customers

Users

Project sponsor

PHB

Canadian taxpayers



What do they Want?

Scope, time, cost, quality

But from different perspectives

Normally different needs/different priorities

JPL examplesScientists want pix from Mars

Senators want reduced costs

US public wants little green men

USAF wants a remote spy station



What the PM Must Do

Clarify who they are

Personify them (who can act as a SH? Focus groups?)

Discover and align their expectations and impact on the project

Outline the Reqs ChM

Relate needs/expectations to risks

Flesh out SH communications plan



Use Cases

Pick a typical SH, say the end user

How would she react with the end product

What would she expect?

Refine these expectations into precise requirements



The SINNER Project

A fanciful project to redo the FedGov’s SIN number registry program (was actually done by RevCan)Idea was to do it via a Web interface into Ottawa’s massive SIN database“JAC” Joe Average Citizen (JMC: Jean Moyen Citoyen)“ADM” = Assistant Deputy Minister (BIIIIG PooBah!)“DORC” = Dept. of Redundancy Dept.



SINNER Example

JAC/JMC logs into the Web SiteWants to get a SIN number

What would make her happy?

ADM responsible for SIN NumbersWhat does she need in admin support?

What is done now?




RevCan directorWhat does he need in admin support?

What is done now?




A Formal Approach (L. Smith CrossTalk Dec 2000)

Identify project stakeholders

Identify SHs interests, impact and relative priority

Access SHs for importance and influence

Outline assumptions and risks

Define SHs participation



What would make them Happy?

List the expectations as completely as you can

Prioritize them

Weight according to Importance-Influence diagram



Map Expectations into Requirements

Formal Statements

Use diagrams if possible

Use state tables

Always try to have functional precisionMust process application within 5 seconds

Must handle 20 applications per minute on average

All screens in French and Anglais



SINNER Context Diagram

PROJECT

JAC/JMC

HRDCadm

Func Depts

OwnersTeamMems

DORC

Parliament

internal

external

RevCandir



SINNER: fill in the SHs

PROJECT

JAC/JMC

HDRCman

Func Depts

OwnersTeamMems

DORC

Parliament

internal

external

RevCan man



SH Importance/Impact/Priority

SH Interests P Impact P Import Priority



Outputs from Scope Planning

.1 Project Scope Statement

.2 Requested Changes

.3 Project Scope Management Plan - updates



.1 Project Scope Statement

The documented, detailed description of the project’s deliverables and the work required to create those deliverables

Provides a common view of the project that ALL stakeholders can see

Describes the project’s objectives

Defines the Boundary of In-scope, Otta-scope



PSS will include (or point to) at least

1. Project objectives2. Product requirements description3. Project requirements4. Project boundaries5. Project deliverables6. Product acceptance criteria7. Project constraints8. Project assumptions



PSS continued

09. Initial project organization10. Initial defined risks11. Schedule milestones12. Fund limitations13. Cost estimate14. Project CC requirements15. Project specifications16. Approval requirements



1. Project Objectives

PMBOK defines objectives as the measurable success criteria of the project

Can come from many areas such as:Cost

Schedule

Quality

Objectives themselves can have the above 3 attributes



SMART Objectives

Specific

Measurable

Agreed

Realistic

Time-constrained



Typical Objectives

Benefits of the project (ROI justification)

Operational improvements

Enhanced readiness

Productivity improvement

Market opportunities

Improved customer service



2. Product Requirements Description

Precisely defines the product characteristics (see last half of this unit)

Will be progressively elaborated

This will normally point to the Requirements Document as it can be really big

Windows-ME story



3. Project Requirements

The conditions that the project must meet to satisfy a contract, standard, specification

Stakeholders needs, wants, expectations of the project must be analyzed and mapped into prioritized project requirements



4. Project Boundaries

You must be able to answer the question “is in it scope or not?”

Vitally important for ICM and project restructuring if necessary



5. Project Deliverables

Defines precise project deliverablesIn-project (project management reports, EVA etc)

Out-of-project (things that get delivered as a document, service etc but are outside the project)



6. Product Acceptance Criteria

This is HUGE people.

For each deliverable, you must specify the conditions under which the deliverable HAS to be accepted

If you do not, the customer will not sign off out of pure naked FEAR!



7. Project Constraints

These are more detailed constraints than in the Charter

Anything that might be within scope

Pre-defined budget

Pre-defined time lines (such as Y2K)



8. Project Assumptions

List the assumptions as far as you can

For example, adequate funds will be released on time

The price of oil will remain constant

The Canadian dollar will not go above 90% of the US dollar



9. Initial Project Organization

Name team members

Name stakeholders

Detail the project organization (org chart good here)



10. Initial Defined Risks

Risk starts here

Identify the obvious risks



11. Schedule Milestones

Are there imposed dates? State them.

This will be vague at this stage and will be further elaborated as we progress



12. Fund Limitations

Specify any money limitations either on a phase basis or in total value



13. Cost Estimates

Estimate the cost at this point and an indication of the accuracy of this estimate and where it came from



14. Project CM Requirements

Describe the level of configuration management and change control that is to be used over the life of the project



15. Project Specifications

Identify the specification documents with which the project must comply (IEEE PMP for example)



16. Approval Requirements

Identify who will approve items such asProject objectives

Deliverables

Documents

Etc etc



.2 Requested Changes

In the development of the Scope Definition, changes may be required to the PMP and other plans

These go through ICC



.3 Scope Management Plan, updates

Changes accepted from ICC may require changes to the SMP



5.3 Create Work Breakdown Structure

The WBS decomposes the major project deliverables into smaller, more manageable components.

Organizes and defines the total scope of the project

Decomposition continues until the Risk is exposed

The Lowest WBS is the Work Package which now can be scheduled, cost-estimated, monitored and controlled

The WBS is the SKELETON of the project on which all else is hung



Consequences of Bad or Null WBS

Incomplete project definition leading to extensions

Unclear work assignments, goals, objectives, deliverables

Scope creep, massive scope changes

Budget overrun

Missed deadlines, timeline slippage

Unusable product

Failure to deliver some elements of project scope



WBS Relationship to other PM Tools

Project CharterProject Scope StatementProgram WBSResource Breakdown Structure (RBS)Organizational Breakdown Structure (OBS)WBS DictionaryProject Network DiagramProject Schedule



WBS and the Project Charter

Charter in the starting point for the WBS

WBS’s highest level element is Charter’s overall end-point product

Charter must define that clearly



WBS and the Project Scope Statement

High-level elements of the WBS should match word-for-word the Scope-defined outcomes

If the team has a problem in doing this, likely the scope statement is fatally flawed



WBS and the Program WBS

The PMO will have a collection of projects of which this is one

WBS must be able to be see as an elaboration of the Parent WBS

If the scope of the program changes, the impact on this project can easily be senn IF the two WBS’s are aligned



WBS and the RBS

Resource Breakdown StructureDescribes the Organization’s resource structureNeed this to map people onto the project teamUse the WBS and the RBS to allocate people to WPAll team members have appropriate WPsEvery WP has an owner (BIGGY)



RBS (RACI format)

RACI R= Responsible

A= Accountable

C= Consult

I= Inform

Ann Ron Carlos Dina Ed

Define A R I I I

Design I A R C C

Develop I A R C C

Test A I I R I

ActivityPerson



WBS and the OBS

Organizational Breakdown Structure

Graphically shows the Org’s hierarchy

WPs can be related to performing organizational units

OBS is organized by People

WBS is organized by deliverables



WBS and the WBS Dictionary

Contains information about each WPDetailed description of the work

Deliverables

Activities

Milestones

Maps WBS numbers to English names

Can indicate resources allocated, charge number, etc



WBS and the Project Network Diagram

ND is the temporal sequential arrangement of the WPs (e.g.; a Gantt Chart)

Can uncover WBS problems such asIncomplete decomposition

Assigning too much effort for a WP

More than 1 person responsible for a WP

Risks

Project dependencies



WBS & Project Schedule

WBS is mandatory to develop the schedule



5.3 Process to Create Work Breakdown Structure

.1 Scope updates

.2 WBS

.3 WBS dictionary

.4 Scope baseline

.5 SMP updates

.6 Requested changes

1 WBS templates2 Decomposition


.2 Scope statement

.3 Scope man plan

.4 Approved CRs



Inputs to Create WBS


.2 Scope statement

.3 Scope man plan

.4 Approved Change Requests

[ as already seen]



Tools and Techniques for WBS Creation

.1Work Breakdown Structures

.2 Decomposition



.1 Work Breakdown Structures

The WBS provides the foundation for integrating WP details and deliverables with all other aspects of project

InitiationPlanningExecutionMonitoring and controllingClosingRisking



Benefits of Deliverable-oriented WBS

Better communication with sponsors, stakeholders, team members

More accurate estimation of tasks, risks, costs, timelines

Increased confidence that 100% of the work is included



WBS Roles in Supporting Clarity

Decomposes project scope into deliverables

Supports the definition of the work effort required for effective management

Defines the scope in terms of deliverables that all can understand

Ties the WPs to the OBS (organizational breakdown structure) and RAM (responsibility assignment matrix)



WBS Roles in Supporting Clarity cont.

Permits the measurement of the project’s progress, status, projected performance

Supports tracking of problems to root causes for process improvement



WBS Levels

Is hierarchical

The depth is dependent upon the size and complexity of the project and on the level of detail needed



The 100% Rule (Haugan 2002)

The WBS included 100% of the work defined by the project scope and captures ALL deliverables

Internal

External

Interim

Applied to the WBS and to every WP



Example (PMBOK)

Project Managem’t

Data Air Vehicle Support Equipment

FacilitiesTraining

Support Equipment

SysEng Managem’t

Supporting PM Act’s

Equipment Training

Facilities Training

Services Training

Technical Orders

Engineering Data

Management Data

Mockups

Operational Test

Developmental Test

Org Level SE

Interme’ate SE

Depot Level SE

Test

Engine Communications

Navigation System

Fire Control

Airframe

Test and Evaluation



WBS Dictionary

The WBS is hierarchical in the sense that each subroot is a decomposition of a bigger item

Natural to number them showing the relationship such as

Project

1 2 3 4 5 6 7 major sublevels

1.1 1.2 1.3 sublevels of 1

Need a WBS dictionary to map numbers to names



Templates

Product-oriented organization

Phase-oriented organization

Function-oriented organization



Example (PMBOK)

1 3 4 5 62

Support Equipment

1.1

1.2

2.1

2.2

2.3

3.

3.2

3.3

7.1

7.2

7.3

5.

5.2

5.3

7.4

4.2 4.3 4.4 4.54.1

7



WBS Comments

Note that the spatial order from the first level to the second varies

Could use dotted links to show dependencies

Note too that we have exposed the WBS to TWO levels

1.1

1.1.1 1.1.2 1.1.3

1.1

1.1.1 1.1.2 1.1.3



Don’t Confuse WBS with other ACKs

CWBS – contract WBS (far less detail)

OBS is Org Breakdown Structure

BOM is Bill of Materials

RBS – Resource Breakdown Structure

PBS - Project Breakdown Structure is the same



PMBOK Example

Deliverable 3

Project

Phase 1 Phase 2

Subproject 2.2.2.1

Deliverable 2.2

Deliverable 2.2.1

Deliverable 4.1.2.1

Subproject n

Deliverable 2.1

Deliverable 2.3

Deliverable 2.2.2

WorkPackage 2.2.2.1

WorkPackage 2.2.2.2

WorkPackage 2.2.2.3

Subproject 4

WorkPackage 3.1

WorkPackage 3.2

WorkPackage 3.3

Deliverable 4.1

Deliverable 4.2

Subproject 2.2.2.2

Deliverable 4.1.1

Deliverable 4.1.2

Deliverable 4.1.2

Deliverable 4.1.2.2

Deliverable 4.1.2.3



.2 Decomposition

The subdivision of project deliverables into smaller, more manageable components



How to Do WBS Decomposition

Must break a deliverable into smaller, more manageable components

Continue until you expose enough structure to do estimation and resource allocation

Another criterion is until you can see the Risk Exposure



Decomposition’s Four Steps

1. ID the Major Deliverables of the projectLife cycle is a good place to start

2. Can the costs and times for this deliverable calculated now? If so, go to 4

3. Break it into its constituent components and go back to 2

4. Verify the correctness of the Decomposition



Each WP Must Have 6 Criteria Stated

1. Status/completion are measurable

2. Clearly defined start/end events

3. Activity has a deliverable

4. Time/cost easily estimated

5. Activity duration within acceptable limits

6. Work assignments are independent



Verification

Are the lower-level items both necessary and sufficient to complete the decomposed item?

Is each item clearly and completely defined?

Can each item be scheduled; costed; assigned to a OU to do; SOer IDed?



For EACH WBS item, you must

Indicate the Name and Function of it

Specify input criteria and output results

Show that EACH of the 6 criteria are met

Folks, this is CRITICAL!



5.1.4 Scope Verification

Must PROVE that the decomposition is necessary and sufficient to all stakeholdersNeed their signoffIf the project is terminated early, this determines the level of completionNote SV is concerned with acceptance of the work, NOT its correctness (that’s quality’s job)Normally done in parallel



5.4 Scope Verification

1 Formal acceptance

1 Work results2 Product documentation3 WBS4 Scope statement5 Project plan

1 Inspections



Inputs to Scope Verification

.1 Work Results

.2 Product Documentation (reqs, plans, specs, tech docs, drawings, users’ manuals etc.)

.3 WBS

.4 Scope Statement

.5 Project Plan



T&T for Scope Verification

Inspection can include activities such as measuring, examining, testing, etc

Can have other names (reviews, walkthroughs, audits, product review etc.)



Output from Scope Verification

SIGNOFF, SIGNOFF, SIGNOFF!

May be conditional (yuck)

HAS to be documented



5.1.5 Scope Change Control

Is concerned with1. Influencing the factors that can cause scope

changes and insure that the changes are agreed to

2. Determining that a scope change has occurred

3. Managing the actual changes when they happen

Has to be integrated with other control processes (schedule, cost, quality, risk)



WHY You Ask?

Is this not just another example of ICC?

Yes but it is SOOOO critical that we explicitly expose the process, just like we do for ICC on the Project Plan



5.5 Scope Change Control

1 Scope changes2 Corrective action3 Lessons learned4 Adjusted baselines

1 WBS2 Performance reports3 Change requests4 Scope management plan

1 Scope change control2 Performance measurement3 Additional planning



Input to Scope Change Control

.1 WBS

.2 Performance ReportsMay suggest the need for change

.3 Change RequestsSee next slide

.4 Scope Management Plans



Change Requests

Normally done with a template

Can also beOral

Direct or indirect

Internally or externally initiated

Legally mandated

Optional



Most are a result of

External event (change in government regulation)

Error or omission in product requirements

Error or omission in project scope

A value-added change (we need to change from glass TTYs to Windows)

Risk initiated



T&T for SCC

.1 Scope Change Control

.2 Performance MeasurementWe need to measure the effects of the changes on $ and τ

.3 Additional PlanningBecause of the change acceptance, we will likely need to change the PMP

Remember, “no plan survives first contact with the enemy”



Scope Change Control

The steps we need to do this

Specifies allPaperwork

Tracking systems

Authority to make the changes

Signoffs necessary

MUST be integrated with Integrated Configuration Management



Outputs from SCC

.1 Scope ChangeAny approved changes must go through the PMP cycle. Very likely we will increase $ and τ

.2 Corrective ActionDocumentation of anything necessary to bring future work in line with the original plan

.3 Lessons LearnedVery important to add these to the database (ie, why did we miss this?)

.4 Adjusted BaselinePMP and anything else must reflect the new reality



5.2 Requirements Road Map

5.2.1 Introduction to the Problem5.2.2 The Requirements Process5.2.3 Types of Requirements5.2.4 Characteristics of Good Requirements5.2.5 Expressing Requirements5.2.6 Reducing Requirements Defects5.2.7 The CMM Requirements KPA5.2.8 The Elicidation Process5.2.9 Case studies



Key Result Areas

In this section, you will learn about:the importance of requirements

qualities requirements should have

testing against requirements



5.2.1 Requirements Analysis

Why requirements are important

Qualities requirements should have

Functional vs. Non-Functional

Case Study



Why Requirements are Important

Verification and Validation

Auditing

Several studies show it to be the most $ phase

It can cost 200 times if reqs defect detected in maintenance instead of req phase



Studies Show

USAF 41% defects were in Reqs

DeMarco found 56%

Raytheon found 40% rework costs

Boeing up to 85%



Standish Questionnaire 1994 8000 Failures; Why did they fail?

Lo Requirements led all the rest! (39.2%)Incomplete requirements 15.%

lack of user involvement 12.4%

lack of resources 10.6%

unrealistic expectations 9.9% (reqs?)

lack of management support 9.3%

changing requirements 8.7%

lack of planning 8.1%

system no longer needed 7.5%



Why are Requirements Hard?

Users don’t know what they want

Users and developers don’t speak the same language

There is no good way to spec reqs

Natural language IS inherently ambiguous

It’s natural to start doing (coding)



5.2.2 Requirements Life Cycle

Develop the Requirements Document

Establish the Reqs Change Process

Monitor Reqs Management



Developing the Requirements Document

1 Form the Scope/Reqs Team2 Work out the WBS and Initial Reqs (Turn expectations into Reqs) in tandem3 Iterate through these 2 until Initial Doc is Baselined4 Try to build a prototype5 Have the users “use” it6 Go to 2 if corrections are necessary else7 Baseline it



Requirements Management

Requirements Elicidation & AnalysisProblem analysis

Problem description

Prototyping and testing

Requirements Definition and Specification



5.2.3 Types of Requirements

1. Physical Environment

2. Interfaces

3. User and Human Factors

4. Functionality



Types cont.

5. Documentation

6. Data

7. Resources

8. Security

9. Quality Assurance



Note the Interplay

Scope is general

Requirements are specific

The systems shall return a user’s SIN number when requested (S)

When the user hits the return key on screen 112, the SIN field will be displayed within 1 second ®



1 Physical Environment

Where is it to be?

How many locations

What environmental restrictions exist?temperature

humidity

magnetic interference

weight



2 Interfaces

Does input come form other systems?

Is the output going to external systems?

Must the data be formatted?

Is there a prescribed medium that must be used?



3 User and Human Factors

Who will use the system

Will there be several types of systems?

What skill level is needed?

What kind of training is necessary?

How easy is it to use the system?

How difficult will it be to misuse the system?



4 Functionality

What will the system do?

When will the system do it?

Are there several modes of operation?

How and when can the system be changed?

Are there constraints on execution speed, response time, through put



5 Documentation

How much documentation is required?

Modality of documentation?

To what audience is it addressed?



6 Data

What should the format be (I and O)?

How often will it be sent/received?

How accurate must it be?

To what degree of precision must the calculations be made?

How much data must flow through the system? Are there temporal patterns?

Must data be retained and if so for how long?



7 Resources

What materials, personnel, etc are required to build, use and maintain the system?

What skills must the developers have?

How much physical space will be taken up by the system?

What are the reqs for power, heating, air conditioning?



Resources cont.

Is there a timeline for development?

Is there a cost ceiling?



8 Quality Assurance

What are the requirements forreliability

availability

maintainability

security

other quality attributes



Quality Assurance cont.

How must the system characteristics be demonstrated to others?

Must the system detect and isolate faults?

What is the MTTF?

Is there a maximum restart time (after failure)



Quality Assurance cont.

How can the system incorporate design changes?

What efficiency measures will apply to resource usage and response times?

How easily can the system be moved to other locations?

How easily can the system be ported?



9 Security

Must access to the system information be controlled?

How can users' data be isolated?

How will user programs be isolated from other programs and the operating system,?

How often must the system be backed up?



Security cont.

Must the backup copies be stored in different locations?

Should precautions be taken against fire, water, theft, earthquakes, riots?



5.2.5 Major Characteristics of Good Requirements

1 Unambiguous

2 Measurable hence testable

3 Do not include “parenthood” expressions

4 Functional and non-functionals not mixed

5 Design directives not included

must ALWAYS be Numbered



Additional Characteristics of Good Requirements

Correct

Consistent

Complete

Realistic

Traceable



Functional vs. Non-Functional

Functionals are measurable

Non-Funcs are things likehigh quality

easy to maintain

easy to change

We always hope to turn non-funcs into funcs



Some Non-Functionals

Each team member is required to know the project goals, and their individual role throughout all project phasesFinancial sponsors assume that their money is being well-spentThey are reported to on a regular basisFunctional managers provide appropriate skills at appropriate stages (such as experts in cost and schedule estimation, data bases layout etc)



Reqs are Hierarchical

Lay out the hierarchy

For example, follow the PMBOK for the project plan



5.2.5 Expressing Requirements

Static

Dynamic



Getting Them Right the 1st Time

Use verbs like shall, perform, conduct, do, design, modify, erect, support

State each req precisely, simply, clearly

Review each with the customer

Model them with RAD, JAD



CSFs for Req management

Defined change process

Clear development process

Low risk approaches

Establish a trusting work atmosphere

Use pilots, RADs for show-and-tell

Get management commitment



Train testers to use reqs

Use req man tools

Convince team of usefulness

Track defect back to cause and eliminate it

Identify champion

Get external certification



5.2.6 Reducing Requirements Defects

Do not let scope CREEP

Talk to thine users

Build a Prototype and show to the SHs

Get SH sign-off from each



How to Let Scope Creep: A Creepy Problem

Include features that are not aligned with the project’s business drivers

Include features that do not have an adequate cost/benefit ratio

Include features that overtax the project’s budget and/or time constraints

Include features that add risk



5.2.7 The CMM Requirements KPA

1 Goals

2 Commitment to Perform

3 Ability to Perform

4 Activities Performed

5 Measurement and Analysis

6 Verifying Implementation



1 Goals

G1 System requirements allocated to software are controlled to establish a baseline

G2 Software plans, products and activities are kept consistent with the system requirements allocated to software



2 Commitment to Perform

C1 The project follows a written organizational policy for managing the systems requirements allocated to software

This policy typically specifies that:The allocated requirements are documented

The allocated requirements are reviewed by the Software managers Other related groups

The software plans, work products and activities are changed to be consistent with changes to the allocated requirements



3 Ability to Perform

AB1 For each project, responsibility is established for analyzing the system requirements and allocating items to hardware, software and other system componentsAB2 The allocated requirements are documentedAB3 Adequate resources and funding are provided for managing the allocated requirements



AB4 Members of the SEG and other software-related groups are trained to perform their requirements management activities



AB1 Establishing Responsibility

Managing and documenting the system requirements and their allocation throughout the project’s life

Effecting changes to the system requirements and their allocation



AB2 Documenting the Requirements

The nontechnical requirements that affect and determine the activities of the project

Products to be deliveredDelivery datesMilestonesConditions, agreements, contracts etc

The technical requirementsThe acceptance criteria that will be used to validate that the software products satisfy the allocated requirements



AB3 Adequate Resources

Individuals who have experience and expertise in the application domain and in software engineering are assigned to manage the allocated requirementsTools to support the activities for managing requirements are made available

SpreadsheetsTools for CMTools for traceabilityTools for text management



AB4 Training

Training inMethods, standards, procedures used in the project

The application domain



4 Activities Performed

A1 The SEG reviews the allocated requirements before they are incorporated into the software project

A2 The SEG uses the allocated requirements as the basis for software plans, work products and activities

A3 Changes to the allocated requirements are reviewed and incorporated into the software plan



A1 Basis for Plans etc

The allocated requirements are:Managed and controlled

The basis for the software development plans

The basis for developing the software requirements



A2 Reviewing Changes to Reqs

The impact to existing commitments is assessed and changes are negotiated as appropriateChanges that need to be made to the software plans, work products and activities resulting from changes to the allocated requirements are:

IdentifiedEvaluatedAssessed for riskDocumentedPlanned Communicated to affected groupsTracked to completion



A3 CCM

Changes to the allocated requirements are reviewed and incorporated into the software plan



5 Measurement and Analysis

Measurements are made and used to determine the status of the activities for managing the allocated resources



6 Verifying Implementation

V1 The activities are reviewed with senior management on a periodic basis

V2 The activities are reviewed with the Project Manager on a periodic and event-driven basis

V3 The SQAG reviews and/or audits the activities and work products for managing the allocated requirements and reports the results



V3 Audit

At a minimum, these reviews and/or audits verify that:

The allocated requirements are reviewed and problems resolved before the SEG commits to themThe software plans, work products and activities are appropriately revised when the allocated requirements are changedChanges to commitments resulting from changes to the allocated requirements are negotiated with the affected groups



8 Elicidation and Refinement

Possible techniques includeInterviewsQuestionnairesEthnomethodological studiesBrainstormingProblem-domain storyboardingPrototypingReadingResearchEvolutionary development



This leads to Feature Priority

Need to be triaged (likely). How to rank?

Davis suggests:1. Importance

2. Volatility

3. Estimate of cost

4. Use-dependency

5. Risk

6. Development-dependency among features

7. Inclusion flag



Feature Ranking

Importance

Cost

Effort (PM)

Risk



5.2.8 Case Studies

The Blazer

The elevator

The garage door opener



Expressing Requirements

Static

Dynamic



Static Descriptions

Time-invariantReqs are relationalFormal ways to express

Indirect ReferenceRecurrence RelationshipsAxiomatic DefinitionBNFData Abstraction



Indirect Reference

described by an indirect reference to problem and solution

write code that solves k equations in n variables

Note: solution may not exist

Describe informally in natural language



Recurrence Relationships

RRs define initial conditions and the steps to get to the next level

f(0)=f(1)=1; f(n+1)=f(n)+f(n-1) Fibonaccis

fac(0)=1; f(n+1)=nfac(n)



Axiomatic Definition

Axioms define basic system properties

build theorems from the axioms

useful in "expert" systems



Backus-Naur Form (BNF)<num> ::= <int>|<int>.|.<int>|

<int>.<int>

<int> ::= <digit>|<digit><int>

<digit> ::= 0|1|2|3|4|5|6|7|8|9



Data Abstraction

data is of a type object

objects belong to a class

any datum is an instance of a class

actions that can happen on data and data types are called methods



Abstract Class STUDENT

studentnumber credit-hours

compute tuition

InStateSTUDENT

studentnumber . in-state rate

compute tuition

OutofStateSTUDENT

studentnumber . credit-hours

compute tuition



Dynamic Descriptionshard; normally take the state approachthe system is in state n until a stimulus transitions it to state n+1ways to express include:

Decision TablesTransition DiagramsEvent TablesPetri Nets



Decision Tables

describe the system as a set of possible conditions and a set of rules that specify actions

T true F false X is action – don'tcare



Decision Table

p RULE1 RULE2 RULE3 RULE4 RULE5

High standardized exam scores T F F F F

High grades – T F F F

Outside activities – – T F F

Good recommendations – – T F

Send rejection letter – – X X X

Send acceptance forms X X



Decision Tables

note that the last 2 columns are redundant

tables can be large; 2n for n conditions

every possible set of conditions must lead to an action (complete)

check for consistency

eliminate conflicting cases



Functional Descriptions and Transition Diagrams

each state is named and a transition is labeled, showing the next state

f(Si,Cj) = Sk



Example of a State Diagram (no output)

S0 S1

S2

1

0

0

1

1

0



Transition Table for Previous SD

Curr S0 S0 S1 S1 S2 S2

Input 0 1 0 1 0 1

Next S1

S0

S1 S2

S0

S2



Which of these are accepted?

00100010

00001111110

10001110

10000010

101010101010



Example State D with output

S0 S1

S2

1

0

0

1

1

0

1 Start

1 More 1End of 1s



Transition Table for SDwithO

Curr S0 S0 S1 S1 S2 S2

Input 0 1 0 1 0 1

Next S1

S0

S1 S2

S0

S2

Out - - - 1 Start End of 1s 1 More 1

-



Assignment

Suppose that our Blazer thermometer has 2 buttons; on/off and F/C. Make up a state diagram describing the correct operations of the thermometer.

Modify the SDwithO to only accept a sequence of alternating 0s and 1s, beginning with a 1 and ending with 111.



Event Tables

vertical axis is set of states or conditions

horizontal are the events that can occur

fill in the table (0 means nothing)



Event Table

Mode Graphics Architecture Native

Event 1 Action 1 X 0

Event 2 Action 8 Actions 2/3 Action 4

Event 3 0 Actions 5/6 Actions 1,2,3

Event 4 X 0 Action 7



Petri Nets

used to model concurrent operations

when several conditions must be satisfied

each state of a PN is associated with a set of tokens

normal "firing rules; when all inputs have tokens, event can "fire" to next state



Firing Rules

before

after



Additional Requirements Notations

Hierarchical Techniques

Data Flow Diagrams

SREMs

SADT

Formal Specification Languages



Hierarchical Techniques

Warnier diagrams

Available

pharmaceuticals

Non-prescription drugs

Prescription drugs

Barbiturates (n1)Narcotics (n2)Steroids (n3)others



Data Flow Diagrams (IPO)

processdata in data out

processdata in data out

data store

data in



SREMs

Software Requirements Engineering Methodology

developed by TRW for real time



SADT

Structured Analysis and Design

Ross' work starting in 1977

Big in the US military

SA specs the reqs using 2 types of diagrams

DT explains how to interpret the results



SADT

Activity

Descriptioninput output

mechanism

control



Formal Specification Languages

Z

Estelle

FST

Lotos



5.9 Reducing Requirements Defects

Do not let scope CREEP

Talk to thine users

Build a Prototype and show to the SHs

Get SH sign-off from each

SE 313A Operating Systems Unit 1

Business

scope requirements

scope management plan

requirements project

pmi project scope management

scope statement updates

scope change control

scope planning project

scope management org