Written by Matt Stehling
Requirements Overview
Requirements, which are interchangeably referred to as “expectations,” encapsulate capabilities and behaviors that a product, system or process must have in order to fulfill a business need or solve a business problem. A requirement is typically classified first into either a functional or non-functional requirement, and from there into whether it is a reporting requirement, security requirement, technical requirement, and so on…
From “my 14 yrs of project mgmt experience: a Top 10 list of why projects fail.”
For this article, we explore “Requirements Management” from a system perspective. Functional requirements describe what a system must do. For example, a functional requirement would be that a web site must send an order confirmation email following a successful e-commerce transaction.
A non-functional requirement places a constraint on how the system will execute it. For example, an order confirmation email must be sent within five minutes of receipt of a credit card authorization code from the merchant credit card processor.
Other non-functional requirements may include system performance (or uptime), usability (or user-friendliness), and validity (or data accuracy). Fulfilling all functional and non-functional requirements should be the goal of project managers and team members alike. Therefore, great care and due diligence should be exercised when managing all types of requirements.
Significance of Managing Requirements
Effective Requirements Management virtually eliminates one of the leading causes of project failure. To be more specific, the probability of scope creep and poor requirements quality is vastly reduced when project managers utilize well-defined Requirements Management processes.
The Future of Big Data
With some guidance, you can craft a data platform that is right for your organization’s needs and gets the most return from your data capital.
Reasons Projects Fail
In my fourteen years of project management experience I’ve witnessed dozens of reasons why projects fail. Here’s a top ten list of reasons which is not in any specific order:
- Incomplete/incorrect business requirements
- Lack of end-user involvement
- Insufficient resources
- Unrealistic business requirements/expectations
- Inadequate managerial support
- Change requests (involving business requirements)
- Poor project planning
- Poor communication
- Project team turnover
- Insufficient user acceptance testing
The above-mentioned reasons include, but are not all related to business requirements. The key takeaway is that it is imperative to resolve requirement related issues/problems as early as possible. Failure to address them early on may result in wasted development effort, and the time spent up until the resolution is complete – may not be able to be recovered. For example, in terms of a web site project, poor requirements can lead to design issues, as well as development issues. In order to recover from flawed requirements, project managers may be facing a situation where they have to essentially start over from the very beginning.
Requirements Management Processes & Deliverables
Requirements management consists of the following four processes and their respective deliverables:
- Requirements Planning – produces a Requirements Management Plan which is approved by the project sponsor and key stakeholders.
- Requirements Development – produces a Requirements Definition Document which is a common understanding of the project requirements among the project sponsor and development team).
- Requirements Verification – produces a formal acceptance by the sponsor that the project requirements have been delivered.
- Requirements Change Management – produces proper handling of all change requests and the development of all approved changes.
Project managers should adhere to all four of these processes in order to ensure that all project requirements are well-understood. Therefore, it is crucial that project managers have an in-depth, as well as practical understanding of these processes.
Requirements planning: is the process that involves the development, review, and approval of a Requirements Management Plan (RMP). The RMP should be reviewed by key stakeholders and approved by the project sponsor. Requirements Development includes requirements gathering and elicitation, requirements analysis, and requirements definition.
Gathering & Elicitation: Requirements are either known or unknown. The objective of Requirements Gathering is to collect all known requirements. This process is very involved and important. Information gathered may stem from a variety of forms, such as email, interviews, surveys, meetings, etc. The information may also come in a variety of formats, such as .xls, .doc, .csv, etc.
The objective of Elicitation is to identify the needs and constraints of various stakeholders. The results of this process are a common understanding among the stakeholders of the user’s communicated needs.
Requirements Definition: is the process of organizing, documenting, defining and refining requirements. The Requirements Definition Documentation (RDD), sometimes referred to as Requirements Specifications (or Site Requirements Specifications (SRS) for a web site project). The approved SRS is a documentation of the agreed upon project scope. It is considered a contract of the system to be delivered between the business and the developers.
In situations where the development of the system is outsourced to an external entity, and SRS is typically part of, or referenced within, the Statement of Work (SOW). The SRS is expected to be very detailed and clearly define the users’ needs.
Requirements Analysis: The objective of Requirements Analysis is to discover unknown requirements, and essentially convert unknown into known requirements. Users’ needs that were not communicated during requirements gathering and elicitation can be uncovered through Requirements Analysis. It is a value-added activity to the project if unknown or overlooked requirements are discovered as early as possible in the project lifecycle.
Requirements Verification: The objective of Requirements Verification is to ensure that all documented requirements are being delivered. This is a recurring process throughout the lifecycle of a project starting at the onset of development and continuing until the completion of the user acceptable testing.
Requirement Change Management: The objective of Requirements Change Management is essential to Requirements Management in which it is the usage of a project change control system that manages the actual implementation of approved changes. This chosen system along with a governing Change Control Board is responsible for handling change requests, any limitations/exceptions of the defined process, and any tolerable irregularities.
In summary, requirements describe the characteristics of the project’s end product (or system). It is crucial to ensure that their descriptions are specific, measurable, and written in a clear and concise fashion. Since requirements describe the project’s end result, they can also be considered the very foundation of a project. Investing the time to accurately and thoroughly explore and record the requirements will pave the road to project success.
