Requirements Management & Engineering
It is widely agreed in the software industry that one of the keys to delivering
high quality products is to get the requirements "right". However there is far
less consensus on what "right" actually means, and even less consensus on what
is the best way to get there. This section outlines some of the key concepts
surrounding requirements and introduces some main activities that should take
place on a project to ensure that a robust requirements definition underpin the system.
What is a "Requirement"?
A requirement is a very simply a stated desire or need: For example in a ficticious
library system, a requirement could be that "the library system allows people to check-in
and check-out books".
The "Granularity" of the Requirement
Not all requirements are equal. When going through the process of gathering requirements
you will come across a variety of different types of requirement and it is important to clearly
categorize them so that you understand what they represent and how they should be considered
when designing or building a system:
-
Functional Requirement - Also known as a "Business Requirement", these requirements are high-level statements
of what the customer expects the product to do - independent of any system or technology. In our example library system, a functional requirement
might be "The library needs to allow a borrower to check-out a book". These requirements typically don't mandate
any particular technology solution.
-
System Requirement - Also known as a "Product Feature", these requirements are at a lower level of granularity
than the Functional/Business Requirements and are usually derived from a higher-level Functional Requirement. In our example
library system, a system requirement might be "The library system needs to be able to scan the barcode of the book during
check-out". The main difference is that the level of detail in a System Requirement is sufficient for an engineer
to begin designing a system specification to meet that requirement.
-
Technical Requirement - Not to be confused with a System Requirement, these requirements essentially embody the
technical environment that the product needs to operate in, and include the technical constraints that it needs to
operate under. They are not directly related to the Functional Requirements, but they are vital in decomposing the
Functional Requirement into System Requirements. For example in our library system, a technical requirement might
be that "The system needs to run on the Windows operating system, be web-based and use the existing bar-code
scanner technology".
-
System Quality - Also known as the '-ilities', these requirements usually end in the word 'ility' and include
such matters as: scalability, reliability, usability, maintainability, supportability, configurability, etc. Similar
to the Technical Requirements, these items will not directly affect the Functional Requirements (after all the borrower
of a book has to check-out somehow), but will have a large impact on the System Requirements and the design of the system.
For example in our library system, it might be required that the system be able to handle 1000 concurrent users
and be maintainable by the existing IT staff, who have certain defined skill-sets.
-
Use Cases and Scenarios - Although not always considered strictly "requirements", use cases and scenarios
are a critical part of defining what a system needs to do and how it will operate. A use case is an example of how
a particular set of Features will be used to fulfill a specific objective. The power of a use case is that it will
often highlight missing Features that were assumed but not documented. In our example library system,
a use case might be "Borrower checks-out book but has overdue items".
-
Assumptions - In some ways, these are the most dangerous of requirements because they are usually
not explictly stated and if not discovered during requirements gathering or business analysis
can lead to the project not being successful. In our library catalog example, a key assumption might be that
the users will be accessing the website through a high-bandwidth connection, whereas the libraries only
have a dial-up connection.
What About an Agile/Scrum Project?
One of the myths surrounding Agile methodologies such as Scrum
is that you don't need to perform a detailed requirements definition since customer
input will provided continuously, and the scope and plan for the project is adjusted at the end of each iteration/sprint.
However contrary to that perception, in such methodologies, the same activities will need to happen, and the same types of requirement
will need to be gathered, analyzed and documented, just the level of documentation formality and timing may be different.
The main difference is that the upfront activities will focus primarily on gathering high-level functional requirements and
prioritizing the items with the customer. Then only the highest priority functional requirements will get analyzed and decomposed
into the System Requirements (usually called User Stories) with the lower-priority items
only getting addressed when they're needed to be included in the requirement backlog for that specific release.