Requirements Management

Requirements Management

by Inflectra on

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.

Try our products free for 30 days, no credit cards, no contracts

Free Trial Please!

And if you have any questions, please email or call us at +1 (202) 558-6885