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 fictitious 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 Requirements
- System Requirements
- Technical Requirements
- System Quality
- Use Case and Scenarios
- Assumptions
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. A sample functional requirement is illustrated below:
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.
Some sample system qualities are illustrated below:
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 explicitly 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 (often called Epics). 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.
What is the Process for Managing Requirements?
A lot will depend on the methodology being used on the project (waterfall, agile, hybrid, etc.) and the level of specificity and auditability needed by the customer or organization. Managing requirements for a safety critical system (such as a flight control system) is very different from managing requirements for a startup business with a new social media product, for example.
The general process looks like this:
We describe each of these below:
- Needs Assessment – This is the process of identifying the needs and understanding the underlying business drivers, scope, constraints and context.
- Requirements Management – The process of putting in place a process to manage the requirements before they are gathered
- Requirements Elicitation – Also called requirements gathering, the process of identifying and researching all of the requirements and needs.
- Requirements Analysis – Sometimes called functional analysis, the process of analyzing the requirements so far, identifying gaps, duplications, contradictions and areas of further investigation.
- Requirements Monitoring – The process of monitoring the requirements as the project is underway to see if they need to explicitly change or whether there were simplifications or misunderstandings that result in clarifications and changes.
- Solution Evaluation – Benchmarking the final solution against the requirements to see if there are gaps (for future development), or whether there are missing features or test cases.
Now that we have discussed the types of requirement, and the main activities, the question you may be asking, is what tools should I be considering to manage this information?
Why Should I Use SpiraTeam for Requirements Management?
SpiraTeam manages your project's requirements, use cases, tests, tasks, source code, and issues in one integrated environment, with full traceability throughout the product development lifecycle.
- It is a complete requirements management solution that provides multiple views of requirements, including a document, hierarchical, grid, mind map and agile Kanban board view.
- Writing requirements is only the start, with SpiraPlan you can plan your products work with its integrated project, product and quality management system.
- SpiraTeam lets you connect your requirements to your other product artifacts for end to end traceability, you can link requirements to your test cases, issues, tasks, defects and builds, and source code.
How do I Get Started?
To learn more about SpiraTeam and how can be used to improve your management of requirements: