Requirements/Scope Management - Part 2. RUP Requirements Management

-

Definitions

Requirement is a condition or capability to which the system must conform.

Requirements Management is a systematic approach to eliciting, organizing, and documenting the requirements of the system, or

Requirements Management is a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

Why manage requirements

Project success is defined by meeting project requirements: conformance to some set of requirements defines the success or failure of projects.

Failing to manage requirements decreases the probability of meeting these objectives.

Requirements problems

  • Requirements are not always obvious and have many sources.
  • Requirements are not always easy to express clearly in words.
  • There are many different types of requirements at different levels of detail.
  • The number of requirements can become unmanageable if not controlled.
  • Requirements are related to one another and to other deliverables of the process in a variety of ways.
  • Requirements have unique properties or property values. For example, they are
    neither equally important nor equally easy to meet.
  • There are many interested and responsible parties, which means requirements need to be managed by cross-functional groups of people.
  • Requirements change.
  • Requirements can be time-sensitive.

Problem analysis

Analyze the Problem

  • Identify and understand business problems. Problem can be described by 4 statements:
    • The problem is …
    • Affects stakeholders: …
    • The impact of the problem is …
    • Solution would provide benefits: …
  • Identify stakeholders.
  • Propose high-level solution.
  • Develop the vision document.

Understand Stakeholder Needs

  • Stakeholders are primary sources of the information.
  • Review list of requests, determine key needs.
  • Produce a prioritized list of requirements.

Define the System

  • Translate stakeholder needs to description of system to build (documents, pictures, etc.).
  • Elicit use-cases (contract between customers, user and developers on how feature works).
  • Provide supplementary specification for requirements that do not fit use-cases (i.e. non-functional ones).
  • Provide a prototype if needed.

Hint: write the natural language description first. If opposed, natural language description will describe the model, not the solution.

Manage the Scope of the System

  • Scope is defined by requirements.
  • Manage scope to fit available resources.
  • Use attributes of requirement (effort, priority, risk) to manage scope.
  • Provide initial architecture document.

Refine the System Definition

  • Detail high-level solution.
  • If feature is complex to build, do not complicate its description. Provide different description for different audience.
  • Verify that solution behaves as described and fits stakeholder needs.

Manage Changing Requirements

Change is not an enemy. Unmanaged change is.

Changing requirements is attribute of flexible project and team.

  • Changes naturally affect analysis and design artifacts.
  • Define single change request management process for all change sources and types.
  • System analyst should review and classify change requests.
  • If change results to scope exceeding, changes to dates and budgets need to be approved by stakeholder.

Requirements concepts

Requirements types

Identifying types of requirements helps organize large number of requirements into manageable groups.

Cross-functional teams

Everyone should be involved: customers, managers, analysts, architects, programmers, designers, technical writers, testers.

Later requirements can be assigned to different roles by type.

Traceability

To determine impact of changes, manager must understand the following relations:

  • Stakeholder requests define product features, and each feature is related to some functional and non-functional requirements.
  • Test cases are related to the requirements they verify and validate.
  • Requirements may depend on each other or be mutually exclusive.

Multi-dimensional attributes

Define set of attributes for each requirement type to simplify management and defining the scope.

Change history

Keep history of requirement changes to capture change, reasons, time and initiator of change.

How to manage requirements

  1. Agree on a project’s vocabulary, suitable for both developers and stakeholders.
  2. Develop a vision of the system that describes the problem to be solved by the system, as well as its primary features.
  3. Elicit stakeholders’ needs in at least five important areas: functionality, usability, reliability, performance, and supportability.
  4. Determine requirement types to be used.
  5. Select attributes and values for each requirement type.
  6. Choose the formats in which requirements are described.
  7. Identify team members who will author, contribute to, or simply view one or more types of requirements.
  8. Determine traceability is needed.
  9. Establish a requirements change procedure to propose, review, and resolve changes to requirements.
  10. Develop a mechanism to track requirement history.
  11. Create progress and status reports for team members and management.

References

  1. Applying Requirements Management with Use Cases. http://61.153.44.88/development/rup/apprmuc.htm
  2. Scott W. Ambler. A manager’s introduction to The Rational Unified Process (RUP). http://www.ambysoft.com/downloads/managersIntroToRUP.pdf

Comments

Post a Comment