UN0603 Unit 5

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
2
Revisions

• 2K6-IX-18 Initial Creation

3
UN0603 Road Map

• Unit 1 Introduction to Project Management
• Unit 2 The Project Management Context
• Unit 3 Project Management Processes
• Unit 4 Project Integration Management
• Unit 5 Project Scope Management
• Unit 6 Project Cost Management
• Unit 7 Project Time Management
• Unit 8 Project Quality Management
• Unit 9 Project Human Resource Management
• Unit 10 Project Communications Management
• Unit 11 Project Risk Management
• Unit 12 Project Procurement Management

4
5 Scope Requirements

• 5.1 Project Scope Management
• 5.2 Requirements Management

5
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

6
5.1 Scope Planning
Project Charter

7
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

8
Scope Management Processes
5.0
5.5
5.4
5.3
5.2
5.1
Initiation
9
Scope Management Processes
5.0
5.5
5.4
5.3
5.2
5.1
Initiation
Initiation
10
Scope Management Processes
5.0
5.5
5.4
5.3
5.2
5.1
Initiation
11
Scope Management Processes
5.0
5.5
5.4
5.3
5.2
5.1
Initiation
12
Scope Management Processes
5.0
5.5
5.4
5.3
5.2
5.1
Initiation
13
Scope Management Processes
5.0
5.5
5.4
5.3
5.2
5.1
Scope Change Crl
Initiation
14
PMI Project Scope Management
15
PMI Project Scope Management cont.
5 Scope Change Control
.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 TT .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
4 Scope Verification
.1 Input .1 Scope statement .2m WBS
ictionary .3 Scope man plan .4
Deliverables .2 TT .1 Inspection .3 Output
.1 Accepted deliverables .2 Requested changes
.3 Recommended corrective changes
16
5.1.1 Initiation

• Initiation is
• Process of formally authorizing a new project
• or
• Authorizing that an existing project can continue
  to its next phase (gating)

17
In Some Organizations

• You first do a
• Needs assessment
• Feasibility study
• Preliminary plan
• Some other similar analysis

18
Project are Authorized because of

• A market demand
• A business need
• A customer request
• A technological advance
• A legal requirement
• A social need

19
5.1 Scope Planning
.1 Expert judgment .2 Templates, forms,
standards
.1 Ent env factors .2 Org process assets .3
Project charter .4 Pre scope statement .5 PMP
1 Project Scope Man Plan
20
Inputs to Scope Planning

• .1 Enterprise Environmental Factors
• .2 Organizational Process Assets
• .3 Preliminary Project Scope Statement
• .4 Project Management Plan

21
.1 Enterprise Environmental Factors

• Things that affect how project scope will be
  managed, such as
• Organizations culture
• Infrastructure
• Tools
• Human resources
• Personnel policies
• Marketplace conditions

22
.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

23
Other Inputs Already Described

• .3 Project Charter
• .4 Preliminary Scope Statement
• .5 Project Management Plan

24
Tools and Techniques for Scope Planning

• .1 Expert Judgment
• .2 Templates, Forms, Standards

25
.1 Expert Judgment

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

26
.2 Templates, Forms, Standards

• WBS templates
• Scope management plan templates
• Project scope change control forms

27
Outputs from Scope Planning

• .1 Project Scope Management Plan

28
.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

29
PSMP defines Processes to

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

30
5.2 Scope Definition
.1 Org process assets .2 Charter .3 Prelim scope
statement .4 Scope management plan .5 Change
requests
1 Scope stmt 2 Changes 3 SMP updates
31
Inputs to Scope Planning

• .1 Organizational process assets
• .2 Charter
• .3 Preliminary scope statement
• .4 Scope management plan
• .5 Change requests

32
Inputs to Scope Definition

• .1 Organizational process assets
• .2 Charter
• .3 Preliminary scope statement
• .4 Scope management plan
• .5 Change requests
• Already covered. If Charter and/or SMP are not
  done, you must find comparable info.

33
TT for Scope Planning

• .1 Product Analysis
• .2 Alternatives Identification
• .3 Expert Judgment
• .4 Stakeholder analysis

34
.1 Product Analysis

• Develop a better understanding of the product of
  the project
• Could use techniques such as
• Product breakdown analysis
• Systems engineering
• Value engineering
• Value analysis
• Function analysis
• Quality function deployment

35
.2 Alternatives Identification

• Think of other ways of achieving the same ends
• Use
• Brainstorming
• Lateral thinking
• Story telling
• Scenario development

36
.3 Expert Judgment

• As seen

37
.4 Stakeholder Analysis

• What and/or who are Stakeholders?

38
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

39
Who are these Stakeholders?

• Project manager
• Team members
• Functional members
• Customers
• Users
• Project sponsor
• PHB
• Canadian taxpayers

40
What do they Want?

• Scope, time, cost, quality
• But from different perspectives
• Normally different needs/different priorities
• JPL examples
• Scientists want pix from Mars
• Senators want reduced costs
• US public wants little green men
• USAF wants a remote spy station

41
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

42
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

43
The SINNER Project

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

44
SINNER Example

• JAC/JMC logs into the Web Site
• Wants to get a SIN number
• What would make her happy?
• ADM responsible for SIN Numbers
• What does she need in admin support?
• What is done now?
• What would make her happy?

45

• RevCan director
• What does he need in admin support?
• What is done now?
• What would make her happy?

46
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

47
What would make them Happy?

• List the expectations as completely as you can
• Prioritize them
• Weight according to Importance-Influence diagram

48
Map Expectations into Requirements

• Formal Statements
• Use diagrams if possible
• Use state tables
• Always try to have functional precision
• Must process application within 5 seconds
• Must handle 20 applications per minute on average
• All screens in French and Anglais

49
SINNER Context Diagram
internal
Parliament
external
50
SINNER fill in the SHs
internal
Parliament
external
51
SH Importance/Impact/Priority
52
Outputs from Scope Planning

• .1 Project Scope Statement
• .2 Requested Changes
• .3 Project Scope Management Plan - updates

53
.1 Project Scope Statement

• The documented, detailed description of the
  projects deliverables and the work required to
  create those deliverables
• Provides a common view of the project that ALL
  stakeholders can see
• Describes the projects objectives
• Defines the Boundary of In-scope, Otta-scope

54
PSS will include (or point to) at least

• Project objectives
• Product requirements description
• Project requirements
• Project boundaries
• Project deliverables
• Product acceptance criteria
• Project constraints
• Project assumptions

55
PSS continued

• 09. Initial project organization
• 10. Initial defined risks
• 11. Schedule milestones
• 12. Fund limitations
• 13. Cost estimate
• 14. Project CC requirements
• 15. Project specifications
• 16. Approval requirements

56
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

57
SMART Objectives

• Specific
• Measurable
• Agreed
• Realistic
• Time-constrained

58
Typical Objectives

• Benefits of the project (ROI justification)
• Operational improvements
• Enhanced readiness
• Productivity improvement
• Market opportunities
• Improved customer service

59
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

60
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

61
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

62
5. Project Deliverables

• Defines precise project deliverables
• In-project (project management reports, EVA etc)
• Out-of-project (things that get delivered as a
  document, service etc but are outside the project)

63
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!

64
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)

65
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

66
9. Initial Project Organization

• Name team members
• Name stakeholders
• Detail the project organization (org chart good
  here)

67
10. Initial Defined Risks

• Risk starts here
• Identify the obvious risks

68
11. Schedule Milestones

• Are there imposed dates? State them.
• This will be vague at this stage and will be
  further elaborated as we progress

69
12. Fund Limitations

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

70
13. Cost Estimates

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

71
14. Project CM Requirements

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

72
15. Project Specifications

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

73
16. Approval Requirements

• Identify who will approve items such as
• Project objectives
• Deliverables
• Documents
• Etc etc

74
.2 Requested Changes

• In the development of the Scope Definition,
  changes may be required to the PMP and other
  plans
• These go through ICC

75
.3 Scope Management Plan, updates

• Changes accepted from ICC may require changes to
  the SMP

76
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

77
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

78
WBS Relationship to other PM Tools

• Project Charter
• Project Scope Statement
• Program WBS
• Resource Breakdown Structure (RBS)
• Organizational Breakdown Structure (OBS)
• WBS Dictionary
• Project Network Diagram
• Project Schedule

79
WBS and the Project Charter

• Charter in the starting point for the WBS
• WBSs highest level element is Charters overall
  end-point product
• Charter must define that clearly

80
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

81
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
  WBSs are aligned

82
WBS and the RBS

• Resource Breakdown Structure
• Describes the Organizations resource structure
• Need this to map people onto the project team
• Use the WBS and the RBS to allocate people to WP
• All team members have appropriate WPs
• Every WP has an owner (BIGGY)

83
RBS (RACI format)
Person
Activity
84
WBS and the OBS

• Organizational Breakdown Structure
• Graphically shows the Orgs hierarchy
• WPs can be related to performing organizational
  units
• OBS is organized by People
• WBS is organized by deliverables

85
WBS and the WBS Dictionary

• Contains information about each WP
• Detailed description of the work
• Deliverables
• Activities
• Milestones
• Maps WBS numbers to English names
• Can indicate resources allocated, charge number,
  etc

86
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 as
• Incomplete decomposition
• Assigning too much effort for a WP
• More than 1 person responsible for a WP
• Risks
• Project dependencies

87
WBS Project Schedule

• WBS is mandatory to develop the schedule

88
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 templates 2 Decomposition
.1 Org process assets .2 Scope statement .3 Scope
man plan .4 Approved CRs
89
Inputs to Create WBS

• .1 Organizational process assets
• .2 Scope statement
• .3 Scope man plan
• .4 Approved Change Requests
• as already seen

90
Tools and Techniques for WBS Creation

• .1Work Breakdown Structures
• .2 Decomposition

91
.1 Work Breakdown Structures

• The WBS provides the foundation for integrating
  WP details and deliverables with all other
  aspects of project
• Initiation
• Planning
• Execution
• Monitoring and controlling
• Closing
• Risking

92
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

93
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)

94
WBS Roles in Supporting Clarity cont.

• Permits the measurement of the projects
  progress, status, projected performance
• Supports tracking of problems to root causes for
  process improvement

95
WBS Levels

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

96
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

97
Example (PMBOK)
Test and Evaluation
98
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

99
Templates

• Product-oriented organization
• Phase-oriented organization
• Function-oriented organization

100
Example (PMBOK)
7
101
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

102
Dont 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

103
PMBOK Example
104
.2 Decomposition

• The subdivision of project deliverables into
  smaller, more manageable components

105
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

106
Decompositions Four Steps

• ID the Major Deliverables of the project
• Life cycle is a good place to start
• Can the costs and times for this deliverable
  calculated now? If so, go to 4
• Break it into its constituent components and go
  back to 2
• Verify the correctness of the Decomposition

107
Each WP Must Have 6 Criteria Stated

• Status/completion are measurable
• Clearly defined start/end events
• Activity has a deliverable
• Time/cost easily estimated
• Activity duration within acceptable limits
• Work assignments are independent

108
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?

109
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!

110
5.1.4 Scope Verification

• Must PROVE that the decomposition is necessary
  and sufficient to all stakeholders
• Need their signoff
• If the project is terminated early, this
  determines the level of completion
• Note SV is concerned with acceptance of the work,
  NOT its correctness (thats qualitys job)
• Normally done in parallel

111
5.4 Scope Verification
1 Work results 2 Product documentation 3 WBS 4
Scope statement 5 Project plan
1 Inspections
1 Formal acceptance
112
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

113
TT for Scope Verification

• Inspection can include activities such as
  measuring, examining, testing, etc
• Can have other names (reviews, walkthroughs,
  audits, product review etc.)

114
Output from Scope Verification

• SIGNOFF, SIGNOFF, SIGNOFF!
• May be conditional (yuck)
• HAS to be documented

115
5.1.5 Scope Change Control

• Is concerned with
• Influencing the factors that can cause scope
  changes and insure that the changes are agreed to
• Determining that a scope change has occurred
• Managing the actual changes when they happen
• Has to be integrated with other control processes
  (schedule, cost, quality, risk)

116
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

117
5.5 Scope Change Control
1 Scope change control 2 Performance
measurement 3 Additional planning
1 Scope changes 2 Corrective action 3 Lessons
learned 4 Adjusted baselines
1 WBS 2 Performance reports 3 Change requests 4
Scope management plan
118
Input to Scope Change Control

• .1 WBS
• .2 Performance Reports
• May suggest the need for change
• .3 Change Requests
• See next slide
• .4 Scope Management Plans

119
Change Requests

• Normally done with a template
• Can also be
• Oral
• Direct or indirect
• Internally or externally initiated
• Legally mandated
• Optional

120
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

121
TT for SCC

• .1 Scope Change Control
• .2 Performance Measurement
• We need to measure the effects of the changes on
  and t
• .3 Additional Planning
• Because of the change acceptance, we will likely
  need to change the PMP
• Remember, no plan survives first contact with
  the enemy

122
Scope Change Control

• The steps we need to do this
• Specifies all
• Paperwork
• Tracking systems
• Authority to make the changes
• Signoffs necessary
• MUST be integrated with Integrated Configuration
  Management

123
Outputs from SCC

• .1 Scope Change
• Any approved changes must go through the PMP
  cycle. Very likely we will increase and t
• .2 Corrective Action
• Documentation of anything necessary to bring
  future work in line with the original plan
• .3 Lessons Learned
• Very important to add these to the database (ie,
  why did we miss this?)
• .4 Adjusted Baseline
• PMP and anything else must reflect the new
  reality

124
5.2 Requirements Road Map

• 5.2.1 Introduction to the Problem
• 5.2.2 The Requirements Process
• 5.2.3 Types of Requirements
• 5.2.4 Characteristics of Good Requirements
• 5.2.5 Expressing Requirements
• 5.2.6 Reducing Requirements Defects
• 5.2.7 The CMM Requirements KPA
• 5.2.8 The Elicidation Process
• 5.2.9 Case studies

125
Key Result Areas

• In this section, you will learn about
• the importance of requirements
• qualities requirements should have
• testing against requirements

126
5.2.1 Requirements Analysis

• Why requirements are important
• Qualities requirements should have
• Functional vs. Non-Functional
• Case Study

127
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

128
Studies Show

• USAF 41 defects were in Reqs
• DeMarco found 56
• Raytheon found 40 rework costs
• Boeing up to 85

129
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

130
Why are Requirements Hard?

• Users dont know what they want
• Users and developers dont speak the same
  language
• There is no good way to spec reqs
• Natural language IS inherently ambiguous
• Its natural to start doing (coding)

131
5.2.2 Requirements Life Cycle

• Develop the Requirements Document
• Establish the Reqs Change Process
• Monitor Reqs Management

132
Developing the Requirements Document

• 1 Form the Scope/Reqs Team
• 2 Work out the WBS and Initial Reqs (Turn
  expectations into Reqs) in tandem
• 3 Iterate through these 2 until Initial Doc is
  Baselined
• 4 Try to build a prototype
• 5 Have the users use it
• 6 Go to 2 if corrections are necessary else
• 7 Baseline it

133
Requirements Management

• Requirements Elicidation Analysis
• Problem analysis
• Problem description
• Prototyping and testing
• Requirements Definition and Specification

134
5.2.3 Types of Requirements

• 1. Physical Environment
• 2. Interfaces
• 3. User and Human Factors
• 4. Functionality

135
Types cont.

• 5. Documentation
• 6. Data
• 7. Resources
• 8. Security
• 9. Quality Assurance

136
Note the Interplay

• Scope is general
• Requirements are specific
• The systems shall return a users SIN number when
  requested (S)
• When the user hits the return key on screen 112,
  the SIN field will be displayed within 1 second

137
1 Physical Environment

• Where is it to be?
• How many locations
• What environmental restrictions exist?
• temperature
• humidity
• magnetic interference
• weight

138
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?

139
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?

140
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

141
5 Documentation

• How much documentation is required?
• Modality of documentation?
• To what audience is it addressed?

142
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?

143
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?

144
Resources cont.

• Is there a timeline for development?
• Is there a cost ceiling?

145
8 Quality Assurance

• What are the requirements for
• reliability
• availability
• maintainability
• security
• other quality attributes

146
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)

147
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?

148
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?

149
Security cont.

• Must the backup copies be stored in different
  locations?
• Should precautions be taken against fire, water,
  theft, earthquakes, riots?

150
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

151
Additional Characteristics of Good Requirements

• Correct
• Consistent
• Complete
• Realistic
• Traceable

152
Functional vs. Non-Functional

• Functionals are measurable
• Non-Funcs are things like
• high quality
• easy to maintain
• easy to change
• We always hope to turn non-funcs into funcs

153
Some Non-Functionals

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

154
Reqs are Hierarchical

• Lay out the hierarchy
• For example, follow the PMBOK for the project plan

155
5.2.5 Expressing Requirements

• Static
• Dynamic

156
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

157
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

158

• 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

159
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

160
How to Let Scope Creep A Creepy Problem

• Include features that are not aligned with the
  projects business drivers
• Include features that do not have an adequate
  cost/benefit ratio
• Include features that overtax the projects
  budget and/or time constraints
• Include features that add risk

161
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

162
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

163
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

164
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 components
• AB2 The allocated requirements are documented
• AB3 Adequate resources and funding are provided
  for managing the allocated requirements

165

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

166
AB1 Establishing Responsibility

• Managing and documenting the system requirements
  and their allocation throughout the projects
  life
• Effecting changes to the system requirements and
  their allocation

167
AB2 Documenting the Requirements

• The nontechnical requirements that affect and
  determine the activities of the project
• Products to be delivered
• Delivery dates
• Milestones
• Conditions, agreements, contracts etc
• The technical requirements
• The acceptance criteria that will be used to
  validate that the software products satisfy the
  allocated requirements

168
AB3 Adequate Resources

• Individuals who have experience and expertise in
  the application domain and in software
  engineering are assigned to manage the allocated
  requirements
• Tools to support the activities for managing
  requirements are made available
• Spreadsheets
• Tools for CM
• Tools for traceability
• Tools for text management

169
AB4 Training

• Training in
• Methods, standards, procedures used in the
  project
• The application domain

170
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

171
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

172
A2 Reviewing Changes to Reqs

• The impact to existing commitments is assessed
  and changes are negotiated as appropriate
• Changes that need to be made to the software
  plans, work products and activities resulting
  from changes to the allocated requirements are
• Identified
• Evaluated
• Assessed for risk
• Documented
• Planned
• Communicated to affected groups
• Tracked to completion

173
A3 CCM

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

174
5 Measurement and Analysis

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

175
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

176
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 them
• The software plans, work products and activities
  are appropriately revised when the allocated
  requirements are changed
• Changes to commitments resulting from changes to
  the allocated requirements are negotiated with
  the affected groups

177
8 Elicidation and Refinement

• Possible techniques include
• Interviews
• Questionnaires
• Ethnomethodological studies
• Brainstorming
• Problem-domain storyboarding
• Prototyping
• Reading
• Research
• Evolutionary development

178
This leads to Feature Priority

• Need to be triaged (likely). How to rank?
• Davis suggests
• Importance
• Volatility
• Estimate of cost
• Use-dependency
• Risk
• Development-dependency among features
• Inclusion flag

179
Feature Ranking

• Importance
• Cost
• Effort (PM)
• Risk

180
5.2.8 Case Studies

• The Blazer
• The elevator
• The garage door opener

181
Expressing Requirements

• Static
• Dynamic

182
Static Descriptions

• Time-invariant
• Reqs are relational
• Formal ways to express
• Indirect Reference
• Recurrence Relationships
• Axiomatic Definition
• BNF
• Data Abstraction

183
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

184
Recurrence Relationships

• RRs define initial conditions and the steps to
  get to the next level
• f(0)f(1)1 f(n1)f(n)f(n-1) Fibonaccis
• fac(0)1 f(n1)n?fac(n)

185
Axiomatic Definition

• Axioms define basic system properties
• build theorems from the axioms
• useful in "expert" systems

186
Backus-Naur Form (BNF)

• ltnumgt ltintgtltintgt..ltintgtltintgt.ltintgt
• ltintgt ltdigitgtltdigitgtltintgt
• ltdigitgt 0123456789

187
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

188
Abstract Class
189
Dynamic Descriptions

• hard normally take the state approach
• the system is in state n until a stimulus
  transitions it to state n1
• ways to express include
• Decision Tables
• Transition Diagrams
• Event Tables
• Petri Nets

190
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

191
Decision Table
192
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

193
Functional Descriptions and Transition Diagrams

• each state is named and a transition is labeled,
  showing the next state
• f(Si,Cj) Sk

194
Example of a State Diagram (no output)
0
0
1
1
0
1
195
Transition Table for Previous SD
196
Which of these are accepted?

• 00100010
• 00001111110
• 10001110
• 10000010
• 101010101010

197
Example State D with output
1 Start
0
0
1
1
0
1
End of 1s
1 More 1
198
Transition Table for SDwithO
199
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.

200
Event Tables

• vertical axis is set of states or conditions
• horizontal are the events that can occur
• fill in the table (0 means nothing)

201
Event Table
202
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

203
Firing Rules
before
after
204
Additional Requirements Notations

• Hierarchical Techniques
• Data Flow Diagrams
• SREMs
• SADT
• Formal Specification Languages

205
Hierarchical Techniques

• Warnier diagrams

Non-prescription drugs
Available pharmaceuticals
Barbiturates (n1)
Narcotics (n2)
Prescription drugs
Steroids (n3)
others
206
Data Flow Diagrams (IPO)
data store
data in
207
SREMs

• Software Requirements Engineering Methodology
• developed by TRW for real time

208
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

209
SADT
control
Activity Description
input
output
mechanism
210
Formal Specification Languages

• Z
• Estelle
• FST
• Lotos

211
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