The following represents one possible example of each type of requirement as they would be applied to a bank’s external ATM.

• ATM functional requirement: The system will enable the user to select whether or not to produce a hard-copy transaction receipt before completing a transaction.
• ATM non-functional requirement: All displays will be in white, 14-point Arial text on black back­ground.
• ATM technical requirement: The ATM system will connect seamlessly to the existing customer’s database.
• ATM user requirement: The system will complete a standard withdrawal from a personal account, from login to cash, in less than two minutes.
• ATM business requirement: By providing superior service to our retail customers, Monumental Bank’s ATM network will allow us to increase associated service fee revenue by 10% annually on an ongoing basis.
• ATM regulatory requirement: All ATMs will connect to standard utility power sources within their civic jurisdiction, and be supplied with an uninterrupted power source approved by the company.

The effective specification of requirements is one of the most challenging undertakings project managers face. Inadequately specified requirements will guarantee poor project results.

Documenting requirements is much more than just the process of writing down the requirements as the user sees them; it should cover not only what decisions have been made, but why they have been made, as well. Understanding the reasoning that was used to arrive at a decision is critical in avoiding repetition. For example, the fact that a particular feature has been excluded, because it is simply not feasible, needs to be recorded. If it is not, then the project risks wasted work and repetition, when a stakeholder requests the feature be reinstated during development or testing.

Once the requirements are documented, have the stakeholders sign off on their requirements as a confirmation of what they desire.

While the project manager is responsible for making certain the requirements are documented, it does not mean that the project manager performs this task. The project manager enlists the help of all the stakehold­ers (business analysts, requirement analysts, business process owners, customers and other team members) to conduct the discussions, brain-storming, and interviews, and to document and sign off the requirements. The project manager is responsible only for enabling the process and facilitating it. If the project manager feels that the quality of the document is questionable, his or her duty is to stop the development process.

The project manager reviews the requirements, incorporates them into the project documentation library, and uses them as an input for the project plan.

Software Requirements Fundamentals

This section refers to requirements of “software” because it is concerned with problems to be addressed by software. A software requirement is a property that must be exhibited by software developed or adapted to solve a particular problem. The problem may be to automate part of a task of someone who will use the software, to support the business processes of the organization that has commissioned the software, to correct shortcomings of existing software, to control a device, etc. The functioning of users, business processes, and devices is typically complex. Therefore, the requirements on particular software are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.

An essential property of all software requirements is that they be verifiable. It may be difficult or costly to verify certain software requirements. For example, verification of the throughput requirement on a call centre may necessitate the development of simulation software. Both the software requirements and software quality personnel must ensure that the requirements can be verified within the available resource constraints.

Requirements have other attributes in addition to the behavioural properties that they express. Common examples include a priority rating to enable trade-offs in the face of finite resources and a status value to enable project progress to be monitored. Typically, software requirements are uniquely identified so that they can be monitored over the entire software life cycle.

Measuring Requirements

As a practical matter, it is typically useful to have some concept of the volume of the requirements for a particular software product. This number is useful in evaluating the size of a change in requirements, in estimating the cost of a development or maintenance task, or simply in using it as the denominator in other measurements (see Table 9.1).

Table 9.1: Measuring Requirements

Property	Measure
Speed	Processed transactions/second User/Event response time Screen refresh time
Size	K Bytes Number of RAM chips
Ease of use	Training time Number of help frames
Reliability	Mean time to failure Probability of unavailability Rate of failure occurence Availability
Robustness	Time to restart after failure Percentage of events causing failure Probability of data corruption on failure
Portability	Percentage of target dependent statements Number of target systems

Scope Inputs

The project manager gathers initial project facts from the project charter. In addition, background information on the stakeholder’s workplace, existing business model and rules, etc. assist in creating the vision of the final product/service, and consequently, the project scope (see Figure 9.2).

Techniques

Certainly being a seasoned project manager broadens the repertoire of one’s scope planning techniques. An experienced project manager can draw on past experiences with like projects to determine the work that is realistically doable, given time and cost constraints, for a current project. Communication and negotiation skills are a “must-have” as well. Project managers need to educate stakeholders about the project impacts of some requirements. Adding complexity to a project may require more staff, time, and/or money. It may also have an impact on project quality. Some aspects of the project may be unfeasible – stakeholders need to know this so they can adjust their vision or prepare for future challenges.

Gathering requirements is part of scope definition, and it can be done using one or more of following techniques:

• Interviews
• Focus groups
• Facilitated groups such as JAD (joint application development)
• Group creativity techniques: brainstorming, nominal groups, delphi, mind map, affinity diagnostics
• Prototyping
• Observation
• Questions and surveys
• Group decision-making techniques: unanimity, majority, plurality, dictatorship

Requirements Traceability Matrix

The requirements traceability matrix is a table that links requirements to their origin and traces them throughout the project life cycle. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope. This process includes, but is not limited to, tracking:

• Requirements to business needs, opportunities, goals, and objectives
• Requirements to project objectives
• Requirements to project scope/work breakdown structure deliverables
• Requirements to product design
• Requirements to product development
• Requirements to test strategy and test scenarios
• High-level requirements to more detailed requirements

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved), and date completed. Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria.

Matrix Fields

These are suggestions only and will vary based on organizational and project requirements.

• A unique identification number containing the general category of the requirement (e.g., SYSADM) and a number assigned in ascending order (e.g., 1.0, 1.1, 1.2)
• Requirement statement
• Requirement source (conference, configuration control board, task assignment, etc.)
• Software requirements specification/functional requirements document paragraph number containing the requirement
• Design specification paragraph number containing the requirement
• Program module containing the requirement
• Test specification containing the requirement test
• Test case number(s) where requirement is to be tested (optional)
• Verification of successful testing of requirements
• Modification field (If a requirement was changed, eliminated, or replaced, indicate disposition and authority for modification.)
• Remarks

 

Scope Statement

Scope statements may take many forms depending on the type of project being implemented and the nature of the organization. The scope statement details the project deliverables and describes the major objectives. The objectives should include measurable success criteria for the project.

A scope statement  captures, in very broad terms, the product of the project: for example, “development of a software-based system to capture and track orders for software.” A scope statement should also include the list of users using the product, as well as the features in the resulting product.

As a baseline scope statements should contain:

• The project name
• The project charter
• The project owner, sponsors, and stakeholders
• The problem statement
• The project goals and objectives
• The project requirements
• The project deliverables
• The project non-goals (what is out of scope)
• Milestones
• Cost estimates

In more project-oriented organizations, the scope statement may also contain these and other sections:

• Project scope management plan
• Approved change requests
• Project assumptions and risks
• Project acceptance criteria

Image Descriptions

Figure 9.2 image description: A project manager develops a Scope Management Plan by taking the project charter, organizational memory, and the project plan and applying the following techniques and tools:

• Calls on past project experience
• Uses scope management templates (SOS, WBS, Scope Management Plan)
• Uses Communication skills (for negotiating with and educating clients)

[Return to Figure 9.2]

Figure 9.3 image description:

0.0 Clean Room

• 1.0 Mop floor.
  • 1.1 Get mop and bucket out.
  • 1.2 Mix cleaner with water in bucket.
  • 1.3 Rinse out bucket and mop.
• 2.0 Dust
  • 2.1 Coffee table
  • 2.2 Blinds
• 3.0 Vacuum
  • 3.1 Get vacuum out of closet
  • 3.2 Vacuum carpet
  • 3.3 Empty bag
  • 3.4 Connect hose and plug
• 4.0 Pick up floor
  • 4.1 Toys
    • 4.1.1 Put toys in box
  • 4.2 Clothes
    • 4.2.1 Hang up in closet
• 5.0 Clean curtains
  • 5.1 Remove curtains
  • 5.2 Take to cleaners
  • 5.3 Hang curtains

[Return to Figure 9.3]

 Text Attributions

This chapter of Project Management is a derivative of the following texts:

• Project Management by Merrie Barron and Andrew Barron. © CC BY (Attribution).
• Project Management/PMBOK/Scope Management and Development Cooperation Handbook/Designing and Executing Projects/Detailed Planning or design stage by Wikibooks. © CC BY-SA (Attribution-ShareAlike).
• Requirements Traceability Matrix by DHWiki. © CC BY-NC-ND (Attribution-NonCommercial-NoDerivatives)