Understanding these requirement concepts is important to effective requirements management.

  1. A requirement is something wanted or needed. If it is no longer wanted or needed, it ceases to be a requirement. For example, 19 inch monitors were specified. After some experience, it was realized the monitors should be 21 inches. The 19 inch monitors are no longer a requirement.
  2. Requirement timeframe. Whether or not something is a requirement is independent of a project and its timeframe. A requirement may not be implemented during a project. In the example above, the users can get by with their old monitors, even though they can't work very quickly. Because it must prioritize its spending, the company will not purchase the new monitors during the project, even though the users still want - and need - them. Consequently, it is not a requirement that must be implemented by the developer the company hired, but is a requirement for the company and may be implemented sometime after the project.
  3. Why are these concepts important? For one thing, if you tell a user that something is not a requirement when it actually is, you will generate arguments and complicate your analytical work. Your project probably has a client project manager or similar authority (not users/subject matter experts) who is responsible for funding, contractual, and scope decisions. This is the person who ultimately decides what requirements will be implemented--and the one with whom your project management should be having these discussions!

    Also, if the client is enlightened and will use the requirements for maintaining and enhancing the system, the client will want the requirement retained for future implementation, and this will affect how you set up and maintain the requirements repository, which is now a deliverable.

  4. Requirement point of view. User requirements are stated from the user's point of view and describe what is needed for the user to do his job. A system requirement is stated from the system's perspective and describes what the system must provide to satisfy or help satisfy the user requirement. (User requirements are sometimes called business requirements.)
  5. Requirements have an object. The object could be a product (such as an automated system), manual processes, project activities, or contract. The nature of the object determines the category of the requirement. For example, the object of the requirement to calculate XYZ is the system, making this a "system functional" requirement. The object of a requirement to report monthly progress is project management. It is a non-technical requirement that is usually found in contracts.
  6. The scope of a requirement determines its level. For example:
    • requirements that affect all systems are industry standards
    • requirements that affect all systems within an organization are at the enterprise level
    • requirements that affect an entire system or major portions of it are system-level requirements (for example, user interface requirements)
    • requirements that affect only a subsystem are at the subsystem level

    It is not the breadth of the wording, but the extent of the impact that determines the scope of a requirement. Requirements at the highest levels can be very detailed. The scope of a requirement should not be confused with project scope.

Why are these concepts important? They facilitate requirements analysis, organization, and management. Next page

Page updated 9/26/2009
Ludwig Consulting Services, LLC