Lean Project Management

Managing Requirements

What is a requirement, how do we classify them, and how do we manage them?  The book, Managing Software Requirements by Dean Leffingwell and Don Widrig, defines Requirements Management as follows:

  • A systematic approach to eliciting, organizing, and documenting requirements
  • A process that establishes and maintains agreement between the customer and the project team

 A “Systematic approach” should be based on a life-cycle.  When does a request or an idea become a requirement?  This is like asking … “when does life begin?”  Does it begin at conception or birth?  Should we manage requirements when they are an idea or after they have been reviewed, formalized, and approved by authorized stakeholders?

While I am asking questions, here are a few more to ponder.  Who is responsible for managing requirements?  When do we stop managing requirements … at the conclusion of a project or after we have verified that outcomes have been realized?   If the requirement replaces an existing capability … who is responsible for decommissioning the existing capability?  What is the difference between a requirement and a specification?  What is the difference between a requirement and scope?

If your organization is typical, many of these questions are not answered by your requirements management process and responsibilities are probably ambiguous.  The following list of topics will provide guidance for improving requirements management.

Requirements Management Considerations

Potential requirements begin as ideas, needs, or requests that should include expected benefits or outcomes and a relative priority.  At some point in time, they must be received, logged, and documented in order to ensure proper consideration.  The earlier an idea or need is logged, the greater the chance it will be properly evaluated and possibly approved as a requirement.  The greatest risk is posed by requirements that are informally accepted and never logged or formalized.

Requirements originate from many possible sources.  Some of these sources may mandate approval or limit options.  Examples include:

  • Strategic Plans and Objectives
  • Regulations or Industry Standards
  • Internal Standards or Architecture
  • Continuous Improvement Suggestions

Business requirements are typically high level and expressed as an outcome because the business doesn’t have the understanding of technology to define functional requirements.  Upon receiving a business requirement, IT should conduct an impact analysis to identify impacts to existing business processes and processing capabilities.  Based on the impact analysis, functional requirements should be defined along with a recommended solution strategy.  Note: Functional requirements should support the business requirement or outcome.

The failure to consider differences between business and functional requirements is the source of many requirements disagreements.  The initial functional requirement describes “what” but doesn’t necessarily describe “how”.  Additional analysis and design is required to determine how the functional requirements will be delivered.  This is a normal progression.  The business may provide specifics on how the want the solution to operate or they may simply describe the outcome.  IT must be able to define their own functional recommendations if they are not provided by the business.

Project scope consists of the subset of approved requirements.  Depending on the available resources, time and budget, it may not be possible to include all of the requirements in the scope.  Scope changes involve the addition, enhancement or removal of approved requirements.

During the construction phase, specifications are defined for implementing each functional requirement in compliance with the established technical requirements.  Requirements details evolve over time and should not be considered a change.  Changes to requirements can result in significant re-work and added cost and must be analyzed and managed.  Finally, the construction phase of requirements management should also validate the in-scope requirements have been included and are operating properly and that unauthorized functions have not been added.   The final step (which is often skipped) is benefits realization.  Did the implemented solution realize the desired outcome?  If not, why not?

The following Requirements Management Principles will help you maintain perspective:

  1. The devil is in the details
  2. The difference between a vision and a hallucination are the details and the due date
  3. Sponsorship: “I am behind you all the way.  It is simply a matter of distance.”  Support can disappear when problems occur.
  4. Changes in nature are classified as evolution or mutation based on whether they are beneficial or detrimental.  Make sure that requirements and scope changes provide benefits that exceed the disruption and added cost.
  5. If you can’t measure it, you can’t manage it. How will you define success?
  6. Everything is “relative”
  7. The only “constant” is change

Related Articles

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.