Chapter 4 Flashcards
Principle tasks during Phase B
Organise project team (hold "kick off") Clarify user requirements in detail Prepare detailed system requirements Prepare project master plan Review requirements and plan with customer
System definition
aims at achieving good understanding of what the end item must do to satisfy user requirements
during system definition, the translation of user requirements into technical requirements occurs
Project definition
aims at specifying what the project team must do in the project to produce the end item
during project definition, the project master plan and end-item requirements and specifications are defined
System requirements
address “what” the end-item of the project must do
Project master plan
describes “how” the project will deliver the end-item that meets system requirements and specifications
Project definition = detailed project planning
Details of specifications are defined
Master plan is expanded to reflect details
During expansion, project constraints, opportunities and resources are identified
This leads to revision of specifications
Thus, an iterative process
Common elements of Project Master Plan
- What?
- scope statement, charter or statement of work - What?
- detailed requirements - How?
- detailed work definition - Who?
- responsibility for work tasks - When?
- detailed schedules with milestones - How much?
- project budgets and cost accounts - What if?
- risk plan - How well, what, how?
- performance tracking and control - other elements of plan(as needed)
- work review and testing
- quality control
- documentation implementation
- communication/meetings
- procurement
- contracting and contract admin
Phased (rolling wave) project planning
at the start of the project, there are too many unknowns
thus, we develop the plan in phases
the initial plan is rough, but adequate enough to estimate project resources, time, and cost, and to explain it all to the customer
as the project progresses, the unknowns decrease, the details of the plan can be filled in
a more detailed plan is then created for the next, most immediate phase of the project
Problems with requirement definition
- incorrect requirements
- incorrect definition of needs
- shifting/vagueness of needs
- needs of wrong user
- conflicting needs of multiple users
- distortion of needs by experts - imprecise/ambiguous requirements
- human language
- deliberate imprecision for flexibility
- nebulous projects
- user’s lack of expertise
- project planner’s oversight - shifting requirements
- user’s change of mind
- obstacles that are too great to overcome
- new opportunities
- seeking perfection - over-specification of requirements
- initiative discouraged
- requirements ignored
- insufficient information - underspecification of results
- chaotic project planning resulting in cost and schedule overruns
Guideline for defining user requirements (in order to avoid previously mentioned problems)
- state each requirement clearly; have both user and project staff sign-off on it
- assume if a requirement can be misinterpreted, it will be misinterpreted
- accept that changes to project are inevitable and things will not go precisely as planned
- include pictures, graphs, models, and other non-verbal exhibits in requirements formulation
- carefully monitor changes to requirements once project has begun
- educate both user and project staff about problems associated with specifying requirements
Requirements definition: priority level
The relative importance of the requirement
Requirements definition: margin
Amount by which requirement can vary
Requirements breakdown structure (RBS) should include
every identified functional requirement
System specifications
- define the system requirements in more detail
- define the end-item and its subsystems, components and processes in sufficient depth
- system specifications are derived from system requirements, which are derived from user requirements
System (performance) specifications
address all areas of the project:
design, fabrication, installation, operation and maintenance
