Lecture 3: Structured Project Management1: Introduction

1
Lecture 3 Structured Project Management(1)
Introduction

• Project Management may seem a commonsense
  topic, and it arguably is, however
• There many (often competing) techniques and
  supporting tools and toolsets for managing I.T.
  projects
• Some techniques in common use can overwhelm the
  unwary but arguably they should not, i.e. they
  should be tailored to the organisations business
  needs (in the jargon used in an agile manner)
• Modern techniques emphasise structured
  approaches, i.e. the processes undertaken are
  defined and documented, e.g. the workflows,
  activities, tasks, in particular their inputs and
  outputs
• Planning, however tedious and inexact, is the
  fundamental problem solving tool
• Configuring a technique (or method or
  methodology) is problematic, e.g. needs
  comprehensive knowledge of business itself,
  management technique(s) used, tool/toolset,
  software developers
• Mature software development organisations
  recognise intrinsic value of projects that have
  been effectively managed, i.e. the knowledge
  gained and documented has value in its own right
  

2
Structured Project Management(2)

• Structured project management requires a software
  project management plan
• 2. Software Project is
• The combination of all technical and managerial
  activities that enable a clients deliverables to
  be developed.
• Software projects have a defined duration,
  consume resources and produce work products.
• Forms of work to be managed during a software
  project include Tasks, Activities and Functions
• Simple example of project components

3
Structured Project Management(3)

• Another, more realistic example of project
  components

4
Structured Project Management(4)

• A project has States

5
Structured Project Management(5)

• 3. Software project management plan is a
• reference document for controlling a software
  project.
• Specifies both technical and managerial
  approaches to obtaining software product
• Is allied to requirements analysis document
• Plan is as important as requirements
  documentation
• Change in either document may require change in
  the other document, i.e. documents have a
  dependency relationship
• The Software project management plan may be part
  of the Project Agreement.
• 4. Project Agreement
• Document written for a client that defines
• Scope, duration, cost and deliverables for
  project.
• Exact items, quantities, delivery dates, delivery
  location.
• Client Individual or organization that specifies
  requirements and accepts project deliverables.
• Can be contract, statement of work, business
  plan, or a project charter.
• Deliverables Work Products that will be
  delivered to the client
• Documents
• Demonstrations of function
• Demonstration of nonfunctional requirements
• Demonstrations of subsystems

6
Structured Project Management(6)

• There are standards for Software Project
  Management Plans, e.g. IEEE Std 1058 Standard
  for Software Project Management Plans (SPMP)
• Standard
• Specifies format and contents of software project
  management plans.
• Provides standard set of abstractions for project
  manager or whole organization to construct own
  set (c.f. agile tailored to organisations
  business needs) of practices and procedures for
  developing software project management plans
• Abstractions include Project, Function,
  Activities, Tasks
• Standard does NOT
• Specify procedures or techniques to be used in
  development of plan
• Provide examples

7
Structured Project Management(7)

• Example template for software project management
  plan
• 0. Front Matter
• Title Page
• Revision sheet (update history)
• Preface Scope and purpose
• Tables of contents, figures, tables
• 1. Introduction
• 1.1 Project Overview
• Executive summary description of project,
  product summary
• 1.2 Project Deliverables
• All items to be delivered, including delivery
  dates and location
• 1.3 Evolution of the SPMP
• Plans for anticipated and unanticipated change
• 1.4 Reference Materials
• Complete list of materials referenced in SPMP
• 1.5 Definitions and Acronyms
• 2. Project Organization
• 3. Managerial Process
• 4. Technical Process

8
Structured Project Management(8)

• 2. Project Organisation
• 2.1 Process Model
• Relationships among project elements
• 2.2 Organizational Structure
• Internal management, organization chart
• Example organisation chart

9
Structured Project Management(9)

• 2.3 Organizational Interfaces
• Relations with other entities (subcontractors,
  commercial software)
• 2.4 Project Responsibilities
• Major functions and activities nature of each
  whos in charge
• Matrix of project functions/activities versus
  responsible individuals
• 3. Managerial Process
• 3.1 Management Objectives and Priorities
• Describes management philosophy, priorities
  among requirements, schedule and budget
• 3.2 Assumptions, Dependencies and Constraints
• External events the project depends on,
  constraints under which the project is to be
  conducted
• 3.3 Risk Management
• Identification and assessment of risk factors,
  mechanism for tracking risks, implementation of
  contigency plans
• 3.4 Staffing Plan
• Numbers and types of personnel required to
  conduct the project
• 3.5 Monitoring and Controlling Mechanisms
• Frequency and mechanisms for reporting

10
Structured Project Management(10)

• Example Risk Factors
• Contractual risks
• e.g. What does vendor do if client becomes
  bankrupt and vice versa
• Size of the project
• Action plan for over-large project
• Complexity of the project
• Action plan for requirements creep
• Personal
• Plan for staff recruitment and retention
• Client acceptance
• Plan if client rejects system

11
Structured Project Management(11)

• 4. Technical Process
• 4.1 Methods, Tools and Techniques
• Specifies methods, tools and techniques to be
  used during project
• 4.2 Software Documentation
• Describes documentation plan
• 4.3 Project Support Functions
• Plans for (at least) three project support
  functions.
• To ensure quality assurance
• Configuration management plan (e.g. IEEE Std
  1042)
• Verification and validation plan
• Plans can be included in this section or this
  may be reference to a separate document
• 5. Description of Work Packages
• 5.1 Work Breakdown Structure (WBS)
• Hierarchical decomposition of the project into
  activities and tasks
• 5.2 Dependencies between tasks
• An important temporal relation, i.e. defines
  what must be proceeded by what follows
• Dependency graphs indicate time-ordered
  dependencies of activities

12
Structured Project Management(12) Work
Breakdown Structures (WBS) and Work Package (WP)

• Simple Concept Divide and conquer
• Use Work Breakdown Structures (WBS) and Work
  Package (WP) definitions to identify and manage
  logical units of work.
• Mini-milestones
• When planning, identify binary milestones
  which are either complete/not complete.
• Communication
• Ensure all stakeholders are identified and
  understand their responsibilities.
• Ensure stakeholders attend necessary meetings,
  workshops, etc. and approve the appropriate
  project deliverables.
• Include stakeholders from the customer and all
  IT areas impacted by the project.

13
Structured Project Management(13) A Project
Management Method(ology) Prince21

• PRINCE (PRojects IN Controlled Environments) is a
  project management method covering the
  organisation, management and control of projects.
  
• Reference http//www.prince2.org.uk/web/site/home
  /Home.asp
• First developed by Central Computer and
  Telecommunications Agency (CCTA) now part of the
  Office of Government Commerce (OGC) in 1989 as a
  UK Government standard for IT project management.
• Has become widely used in both the public and
  private sectors and is now the UK's de facto
  standard for project management.
• Although originally developed for the needs of IT
  projects, the method has also been used on many
  non-IT projects.
• Latest version of the method, PRINCE2, is
  designed to incorporate the requirements of
  existing users and to enhance the method towards
  a generic, best practice approach for the
  management of all types of project.

1 Practical PRINCE 2 (ISBN 0117028533).
14
Structured Project Management(14) Work
Breakdown Structure

• As with any widely-used method(ology), Prince2
  has Work Breakdown Structure
• WBS is a divide and conquer" approach to
  breaking a large project into manageable units
  with respect to discipline, subsystem, etc.
• WBS has a Product-Based Planning Rationale
• - Identify products to determine activities
  needed to produce them.
• - Quality of product can be measured and thus
  planned, quality of an activity can only be
  measured by quality of its outcome, i.e. the
  product.
• Product-Based Planning Components
• - Product Breakdown Structure
• Hierarchy of required products including
  management and quality products.
• - Product Descriptions
• For each product, at all levels of PBS
  refinement
• a) Description of the product suitable for
  planning its production
• b) Quality criteria Degree and kind of quality
  checking
• - Product Flow Diagram Indicates how product is
  derived from another product (or group of
  products).

15
Structured Project Management(15) Work Package

• WP defines logical units of work.
• - Determine who is to undertake the work.
• - What is required.
• - What standards are to be used.
• - How it will be tested.
• Work Packages are mechanism for Project Manager
  to collate details of and pass responsibility for
  work or delivery to a Team Manager, team member,
  external supplier.
• WP may be informal or formal, e.g. verbal
  instruction, written instruction, formal
  specification, contractual agreement.
• WP contains
• Product Description(s)
• Techniques, processes, procedures to be used
• Interfaces to be satisfied by work
• Interfaces to be maintained during work
• Quality checking arrangements
• Reporting requirements

16
Structured Project Management(16) Measurement

• Measurement Rationale (why it is done).
• - Raises project visibility.
• - Supports corrective measures.
• Measurement What to measure.
• - Effort by activity.
• - Number of milestones achieved.
• - Number of requirements and features developed.
• Measurement What not to measure and Software
  Metrics.
• - Arguably a problematic discipline (but 30
  years old too!).
• - Involves defining the actual measures
  (numerical metrics some success here!) and
  also determining how to collect, manage and
  exploit measurements made (still a fundamental
  research topic)
• - Results of metrics research have been
  criticised as being unable to support
  decision-making for risk assessment and reduction
  (e.g. 1) due to emphasis on regression-based
  models for cost estimation and defects
  prediction.
• Reference 1 "The Future of Software
  Engineering" , Anthony Finkelstein (Ed.), ACM
  Press 2000, Order number is 592000-1, ISBN
  1-58113-253-0. ACM E-Store http//store.acm.org/a
  cmstore

17
Structured Project Management(17)

• Problems not addressed include causality,
  uncertainty and usefully combining different
  (often subjective) evidence.
• Some limited success with Bayesian Belief
  Networks (e.g. BBNs underpin help wizards in
  MSOffice) but
• BBNs limited Bayes rule assumes that all
  hypotheses are mutually exclusive
• Also assumes that findings are conditionally
  independent, and the occurrence of one finding
  does not influence the occurrence of another,
  hence other research on belief networks, etc

18
Structured Project Management(18) Risk

• Risk If outcomes will occur with known or
  estimable probability the decision maker faces a
  risk. Certainty is a special case of risk in
  which this probability is equal to zero or one.
• For a software development project Any threat
  to the delivery of a project.
• Risk is inherent in any activity you are
  unfamiliar with, makes that activity difficult to
  accurately estimate, effectively plan and
  systematically control.
• Must have definitive approach to risk, i.e. to
  risk assessment and risk control.
• Involves accepting initially that whole or part
  of project involves work of a kind unfamiliar to
  developers involved.

19
Structured Project Management(19) Risk
Assessment

• Must identify component(s) that are risk
  candidates.
• Assign a risk level to each risk candidate
  based on
• Estimate of work involved.
• Number of other components affected by design of
  each (dependency relationships)
• Risk Candidate component (e.g. due to changes
  to interface or expected behaviour).
• Number of other components that depend on each
  risk candidate (directly or indirectly, i.e.
  dependency relationships).
• Novelty of technology involved.
• Availability of existing knowledge, e.g.
• - Design patterns (more in later lecture)
• - Off-the-shelfcomponents
• - Knowledge Base articles, e.g. MSDN
• - Even books, research papers!
• Possibly using a logarithmic scale!

20
Structured Project Management(20) Risk Control

• Resolve and Monitor risk candidates
  recurrence of problems most likely due to risk
  candidates and ineffective resolution.
• Prototype risk candidates first (but assume
  prototypes will have limited potential for
  re-use).
• Dont amplify risk Use known technology to
  build risk candidate prototypes
• Feedback
• Feedback is critical to achieving control and
  improvement of a process.
• Enables a process to be refined as experience
  increases.
• Example NASA Software Engineering Laboratory

21
Structured Project Management(22) Feedback
and Experimentation

• NSL has conducted many hundreds of experiments
  on critical software products.
• Experiments have yielded extensive set of
  empirical studies.
• Studies have guided evolution of standards,
  policies, management practices, technologies and
  training.
• Between 1987 and 1993 raw error rates in
  completed software fell by 75, cost of software
  reduced by 50, cycle time to produce equivalent
  software products reduced by 40.
• Exploits a process improvement paradigm (three
  phase model) with three main steps
  Understanding, assessing, packaging.
• Software defect analysis tool(s) provide support
  for analysing data (that is continuous on
  attribute to be examined to find correlations)
• Error Resolution
• When problems arise
• 1. Stop development immediately.
• 2. Investigate cause of problem.
• 3. Re-plan and re-estimate.
• 4. Start development again.
• Sacrifice some aspects of the project to the
  benefit of others
• - Reduce the feature set, e.g. "de-scope.
• - Adjust the schedule.
• - Increase the cost.

22
Structured Project Management(23)

• Using Structured Project Management
• Benefits include
• Clear risk and issue identification, management
  and ownership.- Clear roles and
  responsibilities.- Clear definition of WBS's and
  WP's.- Effective measurement and control of time
  and cost.
• Repeatable levels of development performance
• Evolving maturity and recognition of intrinsic
  value of what is documented
• Not Using Structured Project Management
• - The reverse of the above!

23
Structured Project Management(24) PRINCE2
Critique

• Strengths
• Produces highly standardised projects which share
  a common approach, vocabulary and documents.
  Consequently it is a transferable skill and
  anyone familiar with a method can quickly be
  brought up to speed on a properly applied PRINCE2
  project.
• It is a method which embodies best (known)
  practise in project management.
• It enshrines management by exception as a guiding
  rule, which allows the Project Manager to do
  their job without undue interference, while at
  the same time involving higher level managers
  when things go badly off plan or in PRINCE terms
  out of tolerance.
• It provides a controlled start, middle and end of
  projects.
• Each type of document required by PRINCE2 is
  supplied as a template, which includes required
  sub-headings which produces easily
  comprehensible, standardised and complete
  documentation.
• Weaknesses
• A number of organisations suffer from PINO
  (Prince In Name Only), carelessly picking and
  choosing from the methodology, thereby failing to
  abide by its key principles.
• PRINCE2 is strongly document centric in order to
  provide good control. However, in some
  organisations the documents become ends in
  themselves, and the actual projects themselves
  falter.
• Similiarly PRINCE2 stresses the need for good
  organisation and regular meetings between
  stakeholders. In some organisations this has
  degenerated into too many meetings and too little
  work.
• PRINCE2 provides no explicit treatment of
  requirements analysis. It is an implementation
  methodology, which can lead to projects being
  adopted on false premises, and thereby inevitably
  failing.
• If too strictly applied PRINCE2 can be far too
  heavy duty an approach for small projects.

24
Structured Project Management(25)Managing
Requirements

• Primary measure of a software systems success is
  degree to which it meets the purpose for which it
  was intended.
• Developing descriptions of a systems
  requirements involves discovering the systems
  purpose by identifying stakeholders and their
  needs, and documenting these in a form which is
  suitable for analysis, communication and
  implementation.
• Requirements must be elicited, modelled and
  analysed, communicated, agreed and evolved.
• Problems are caused by stakeholders (paying
  customers, users and developers) who are numerous
  and distributed, whose goals vary and conflict
  depending on their perspectives of the
  environment in which they work and the tasks they
  wish to accomplish.
• - Stakeholders goals problematic as they may
  be implicit, difficult to articulate, difficult
  to accomplish due to constraints imposed by a
  variety of factors outside their control.

25
Structured Project Management(26)

• In the Real-World, goals (business, technical)
  motivate the development of software systems,
  i.e. few systems are developed simply as
  experiments
• Requirements link Real-World goals with
  software systems which enable those goals to be
  achieved.
• Descriptions of requirements provide basis for
  analysing requirements, validating that
  requirements are what stakeholders want, defining
  what designers and developers have to build and
  verifying that what is built has been built
  correctly when delivered.
• Developing such descriptions is a
  multi-disciplinary human-oriented process tools
  and techniques used come from computer science,
  cognitive psychology, anthropology, sociology,
  linguistics and (ultimately) philosophy.
• Requirements evolve and must be managed minimal
  solution involves techniques and tools for
  configuration management and version control that
  enable monitoring and control of the impact of
  changes to requirements documentation.

26
Structured Project Management(27)

• Some techniques for effectively managing
  requirements-
• Employ a (Lightweight) Requirements Management
  Tool
• Automate the management (i.e. at least the
  shared collective storage of) requirements
  (including their shared updating) and determine
  their impact on architecture, design, user
  interface, etc.
• Recognise different types of requirement
• Examples stakeholder requests, functional
  requirements (involve data modelling,
  behavioural modelling, domain modelling),
  non-functional (or q uality) requirements
  (safety, security, reliability, useability).
• Identify Your Stakeholders
• Ensure the key decision-makers are identified
  and kept in the loop.

27
Structured Project Management(28)

• Eliciting Requirements Use appropriate
  techniques
• Traditional/general purpose data gathering
  techniques
• e.g. questionnaires, interviews, surveys,
  analysis of existing documentation e.g.
  structure/organisation charts, process
  models/standards, existing systems
  documentation
• Group techniques e.g. brainstorming, focus
  groups, workshops
• Problem analysis1 e.g.
• Ishikawa diagrams Cause-and-effect diagram
  (or tree diagram, or fishbone diagram) that
  displays factors that affect a particular quality
  characteristic, outcome, or problem.
• Pareto Analysis Used to determine priorities
  for quality improvement activities via a bar
  chart (bars in decreasing order or relative
  frequency) that displays the relative frequency
  of problems in a process or operation. Pareto
  principle A small subset of problems affecting
  a common outcome tend to occur much more
  frequently than the remainder.
• Prototyping (i.e. executable modelling)
• Model-driven techniques e.g. goal based,
  scenario based
• Cognitive techniques e.g. protocol analysis
• Contextual techniques e.g. observation,
  conversation analysis
• 1 http//support.sas.com/rnd/app/qc/qcparish.htm
  l

28
Structured Project Management(29)

• Do Modelling
• - Where possible, use techniques for modelling
  the problem domain, e.g. prototypes, simulations,
  (executable) graphical models.
• Constrain Your Requirements
• Avoid "feature creep".
• Employ a (formal) change control process
• Determines the impact of change on the project
  (time / cost / quality / etc.), allowing a
  controlled decision to go / no go with the
  change.
• Measure Your Requirements (n.b. more advanced)
• Monitor the change in requirements over the
  duration of projects (n.b. plural) to determine
  how the initial requirements set correspond to
  the final requirements set.
• Adjust requirements process to minimise change.

29
Structured Project Management(30)

• State the Problem Define the "mission statement"
  or "vision" for the project and get it agreed.
• The problem of
• Affects
• The impact of which is
• A successful solution would
• Employ Specialist Roles Allocate a
  Requirements Manager to perform the process.
• Use Industry Standards - UML has become the
  de-facto standard for modelling, Use Cases are
  generally used for functional requirements.
• Ensure requirements are can be tested (develop
  test specification at same time as requirements
  specification).
• Ensure requirements are precise ("high-level" is
  not the same as "imprecise").
• Ensure requirements are bounded (particularly
  for non-functional requirements, ensure a
  definite start and end point is defined)

30
Structured Project Management(31)

• Modelling construction of (abstract)
  descriptions that are amenable to interpretation
  (n.b. also supports elicitation)
• Levels/kinds of modelling
• - Enterprise-level modelling
• - Behavioural modelling
• - Domain modelling
• - Quality (non-functional requirements)
  modelling
• Exploit automated support
• - Animators
• - Automated (analogical, case-based) reasoning
• - Consistency (model) checkers
• - Validation and verification checkers

31
Structured Project Management(32) Summary

• Early SE techniques not directly concerned with
  requirements emphasis was on formal
  specification of systems functionality
  independent of (many possible) implementations,
  e.g. using Formal Methods such as VDM, Z.
• Other techniques emphasised executional
  (formal) specifications, e.g. specifications of
  ADTs1.
• Modern process-oriented approaches emphasise need
  for communication (equally important as
  discovering and specifying).
• Managing requirements (descriptions) now seen as
  essential e.g. documentation standards/guideline
  s for structuring documents.
• Such techniques (and tools that support them e.g.
  for creating completing templates) enable
  traceability, integrity and completeness as
  requirements evolve.
• Resulting descriptions then suitable for
  validating evolving requirements establishing
  that requirements and their models provide
  accurate account of stakeholders needs/goals.
• 1 The Computer Journal, Volume 32, Issue 5, pp.
  413-421 UMIST OBJ a language for executable
  program specifications, R M Gallimore, D Coleman
  and V Stavridou.

32
Structured Project Management(33)

• Inspection/analysis of requirements for coherence
  (consistency and structural completeness) is
  still problematic.
• Validation is very problematic, ultimately it
  involves determining if something is true, i.e.
  it is true that software fullfils its purpose..
• (a) Philosophical considerations Question of
  truth and what is knowable, i.e. many
  philosophical meanings for truth as defined by
  e.g.
• 1Correspondence Theory
• It is true that P ("P" stands for a
  proposition) iff P corresponds with the facts
  (or more simply), It is true that P iff it is a
  fact that P, or even more simply (Redundancy
  Theory) It is true that P iff P.
• or
• 2 Coherence theory It is true that P iff P
  is part of a coherent system of propositions.
• or, arguably more pragmatically,
• 3 It is true that P iff P is agreed upon in
  the consensus achieved at the ideal limit of
  inquiry.
• (b) Social considerations problems agreeing
  (c.f. consensus) among different stakeholders,
  conflicting goals.
• Evolving requirements cause inherent problems and
  require systematic approach to their management.

33
Structured Project Management(34)

• More generally, it is now accepted that
  requirements
• Cannot be effectively modelled and analysed in
  isolation from organisational and social context
  in which any new system will have to operate.
• Requirements process should concentrate on
  modelling of indicative properties and users
  wishes for the environment that system will be
  used within to effectively model its purpose.
• Generating complete and consistent models of
  requirements is impossible, i.e. need techniques
  for-
• Analysing and resolving conflicting requirements
• Supporting stakeholder negotiation
• Reasoning (ultimately reasoning formally) about
  incomplete and inconsistent models of evolving
  requirements

34
Structured Project Management(35)Questions and
Exercises

• Explain, briefly, the eight processes in PRINCE2
  and how the various PRINCE2 management products
  might be reduced to those necessary for a
  small-scale project involving a small team of
  software developers.
• Explain the importance of the Business Case in
  PRINCE2 and identify the components of a minimum
  Business Case.
• Explain the importance of roles, responsibilities
  and line of authority in PRINCE2 and how the
  project organisation structure can be tailored to
  suit small and larger-scale projects.
• Explain how the three elements of PRINCE2s
  control enable both technical and managerial
  activities to be organised.
• Explain the purpose of the Project Plan in
  PRINCE2 how it is refined into stage plans, team
  plans and exception plans.

35
Structured Project Management(36)

• Explain, with the aid of simple examples, the
  headings under which a customers quality
  expectations might be considered in PRINCE2 and
  hence how the approach chosen for the provision
  of the end product influences the way in which a
  project can plan to meet a customers quality
  expectations.
• Explain PRINCE2s approach to risk management and
  hence the terms risk log, risk tolerance, risk
  responsibilities, risk ownership and risk
  analysis.
• Explain what is meant by the term configuration
  management in PRINCE2, the role of the
  Configuration Management Plan and the terms
  product identification, product attributes,
  product submission and issue procedures,
  baseline, release package, configuration status
  accounting and configuration auditing.
• Identify the causes of change in a project and
  explain the role of the issue log and the three
  types of project issues in PRINCE2.

36
Structured Project Management(37)

• Explain, briefly what is meant by the term
  product-based planning technique in PRINCE2 and
  hence, with the aid of examples, the terms
  product breakdown structure, product description
  and product flow diagram.
• What are the main aims of quality review in
  PRINCE2, who should be considered for attendance
  at quality reviews and what distinct phases are
  there in a PRINCE2 quality review procedure?
• What factors influence the choice of a formal or
  informal quality review and how would these
  factors themselves be influenced by the size of
  the project to be undertaken?

37
Structured Project Management(38)

• What data is there to justify the view that
  requirements errors are the most common kind of
  error and also the most expensive to fix during a
  typical software development project?
• What relationship exists between the relative
  costs of various kinds of error and the cost of
  fixing such errors at different stages in the
  software lifecycle?
• What is the justification for stating that a
  requirement is a capability that is imposed on
  the system?
• What is the significance of the statement that
  the requirements challenge is understanding a
  users problems in their culture and their
  language, and to build systems that meet their
  needs?
• Why does an iterative approach to software
  development reflect the view that requirements
  cannot be completely identified and fully
  documented in advance of actual software
  development?

38
Structured Project Management(39)

• Why does effective requirements management
  require an effective software team?
• Why and how do requirements have an affect on the
  work of all team members?
• What team skills must be acquired for effective
  requirements management?
• Why do users needs dominate all other
  considerations during problem analysis?
• How does identifying stakeholders and arriving at
  a collective agreed stakeholder judgement enable
  the boundaries of the solution to be identified
  and the constraints and degrees of freedom
  available when solving the problem to be
  determined?

39
Structured Project Management(40)

• What purpose does a business model fulfil and
  how can such a model be best represented?
• How do software-intensive systems differ
  fundamentally from IS/IT applications and how
  does systems engineering deal with such
  differences?
• What problems are encountered when eliciting
  requirements that enable user and stakeholder
  needs to be met?
• What technique enable problems encountered when
  eliciting requirements to be resolved?
• What is the role of use cases in defining a
  systems requirements?
• Who develops the use cases, what format do such
  use cases take and can test case development be
  driven by use cases?

40
Structured Project Management(41)

• How can requirements be effectively organised?
• What purpose does a vision document fulfil?
• Why role does a project champion or champion team
  play?
• How do product functionality, project resources
  and available time combine to define the scope of
  a project?
• How do a systems requirements enable effort to
  be reconciled with available resources and
  over-scoped projects to be reduced in scope?
• How can a customer be effectively engaged in the
  management of their requirements so that they
  own the results of such management and be
  provided with sufficient functionality at the
  correct time to meet their real needs?
• Explain how use cases can be systematically
  refined and supplementary specifications
  developed.
• What is the significance of ambiguity and
  specificity?
• What technical methods are available for
  specifying requirements?

41
Structured Project Management(42)References

• Practical PRINCE 2 (ISBN 0117028533).
• Managing Software Requirements A Use Case
  Approach (ISBN 032112247X).