2. Scope & Requirements Management

Scope and requirements Management is about defining what the project is supposed to/expected to deliver.

The project scope defines the range or extend of matter being dealt within a project.

A requirement is a statement about a condition or capability.

Collect Requirements —> define scope —> create workpackages —> validate scope —>controle scope

A stakeholder has goals and therefore requirements to achieve them.

*To capture requirements completely a good understanding of the stakeholders and their goals is needed

• Product Requirements: refer to the functionality and quality of the product

  • Functional requirements: Describe the future functionality of the output

    • Actions that can be operated independently by a system

    • Human-system-interaction

  • Non-functional requirements:

    • Technical requirements

    • Security requirements

    • Performance requirements

• Project requirements: refer to the way the project is managed and on the way certain other project activities are executed (e.g. legal and contractual requirements)

Choosing the right techniques is important because capturing requirements does not creating value at.

• Factors to consider when deciding for a tool or method

  • Opportunities and risks in a project

  • Skills and experience of the stakeholders

  • Known explicit or unconscious/subconscious existing information (see also Kano-Model)

• Survey Techniques: Useful for performance factors (Kano-Model) and explicit knowledge

• Observation Techniques: Useful for implicit knowledge and excitement factors

• Creativity Techniques: Useful for identification of new functionalities and solution finding

• Backward-Looking Techniques: Useful for gathering basic factors 

• Supporting Techniques: Supporting techniques increase the effectiveness of other requirement capturing techniques

• Questionnaire —> —> large numbers of stakeholder with small effort—> direct queries are not possible

• Interview—> —>Individual adaption and modification —>Time consuming

• Self-recording—>capturing of existing process (e.g. video)—> low expenditure of time for the analyst—->Often only aware requirements documented

• On-Site Customer—>customer permanently on site with the developers—>Quick transmission of requirements—>Very high effort for the customer

Field observation—>Analyst records activities of the stakeholders—>Enable the detection of unconscious work—>Not useful for hardly observable processes and exception

• Brainstorming —> Effective in a good atmosphere—>Risk of poor results if there are complicated group dynamics

• Method 6-3-5 —>Brainwriting 6 people 3 ideas in 5 min 6 times —> Even feasible with critical group dynamics —> less effective with people diffcult to express themselves in writing.

  
  

  
  

• Systems Archaeology—>Analysing an existing system—>consistent functionality —>complex and time consuming

• Reuse—>Analyse a similar system—>High cost saving—>Risk to find not the right requirements

• Workshops—>—>Direct communication promotes a mutual understanding—>Risk: negative group dynamics

• Mindmaps—>—>Good suitability for a visualisation—>Mind Map mostly only interpreted in the right way by the author

  
  

A glossary helps to avoid misunderstandings due to different interpretation of terms

• creation at the project start

• centrally administered by one person

• Everyone able to access

• consistent structure

• mandatory and binding

• Five Steps:

  1. Determination of the legal liabilities

  2. Formulation of the core of the requirement

  3. Characterisation of the activities of the system

  4. Inser Objects

  5. Formulation of logical and temporal conditions

• Quick embedding and determination of the contents

• Enables a selective reading and review

• Simple reuse of contents

The minimum scope of the project that is accepted by the stakeholders

often based on user stories

requirements are kept individually, if necessary relations to other requirements are documented

• Quality criteria for requirements: INVEST

  • Independent

  • Negotiable

  • Valuable

  • Estimatable

  • Small

  • Testable

• The complete project scope is represented and managed as a backlog (which contains all user stories) → contains all PBI’s (Product Backlog Items)

• The quality of the backlog is evaluated by the DEEP criteria

  • Detailed appropriately: The top PBI is most detailed → detailing just-in-time

  • Emergent: Continuous rebalancing, reprioritizing and adding of PBIs

  • Estimated: Each PBI has a size estimate

  • Prioritized: Near-term items are prioritized (not the entire backlog)

Validate scope is the process of formalizing acceptance of the completed project deliverables

• Outputs of the scope validation

  • Accepted deliverables

  • Work performance information

  • Change Requests

Integrated change control is the process of reviewing all change requests, approving changes and managing changes

• The classical and agile approach differ in these regards because agile project management is built around changes

A “Change” is every change that has an effect either on the project output or on its approach and can be documented in a Change Request

Change Request Management is the process of ensuring that all Change Requests are documented and managed during the entire project duration