In order to succeed in a project, it is essential for both the customer and the project delivery teams to clearly define and agree on a project’s scope and requirements. In this blog post, we elaborate on the various types of requirements and provide examples highlighting the fundamental differences. Basically, there are three types of requirements conscious, unconscious and undreamt requirements. Although the difference between them appears straightforward, it can be challenging for the business analysts/delivery teams to understand/capture such types of requirements and deliver results.
Conscious Requirement
A conscious requirement is something that the stakeholder is consciously aware of. It is generally easy to gather this type of requirements from the stakeholder.
Unconscious Requirement
An unconscious requirement represents a requirement that the stakeholder desires, but for some reason they did not express or forgot to elicit, assuming that it will be taken care of as a matter of course. This can lead to some challenges during the software development process, as this type of requirement often comes to the fore after the application has been developed. Quite often stakeholders have a great knowledge about their domains and they assume that everyone working on the project have similar domain knowledge, leading to last-minute confusions and additional development effort.
Undreamt Requirement
An undreamt requirement is a requirement that stakeholders generally do not mention since they assume that such requirements are impossible to achieve. Undreamt requirements are even more difficult to capture, as the stakeholder might not share these requirements unless some ideas or facts relating to these requirements are shared with them. Generally, these requirements surface after the software application has been in use for a while. As a matter of fact, business analysts are the ones who elicit many of these undreamt requirements.
Functional and Non-Functional Requirements
In addition to the above, requirements are further classified into functional and non-functional. The below table illustrates the difference between functional and non-functional requirements.
| Functional Requirement | Non-Functional Requirement |
|---|---|
Defines the external behavior of the system.
In other words, it illustrates what the system does and what the system must not do. |
Defines the quality attributes or the constraints of the system. Some examples of quality attributes include security, performance, and availability. Technology Constraint – For example, the system must be implemented using core Java technology. Process Constraint – A process constraint could be that the new system must be developed with the Rational Unified Process (RUP) methodology due to its architectural complexity. |
Let us consider an example of an airline reservation system, where users can search and book flight tickets. We have defined the Function and Non-functional requirements for this use case.
| Functional Requirement | Non-Functional Requirement |
|---|---|
| ‘A user can search for a flight. If a flight is selected, the user has 2 minutes to confirm the booking or the flight will be released’. This requirement defines how the system will interact with the user and responds under certain conditions. |
‘The response time for a search transaction under a peak load of 10,000 users must not exceed 2 seconds’. ‘The throughput of the system is 100 search transactions per second’. These requirements define the quality attributes of a software in terms of response time and throughput. |
Fact Check
In reality, stakeholders never provide quantitative non-functional requirements. Instead, they give certain generic statements, which are at times difficult to decipher. Some examples are mentioned below:
Example 1
Instead of mentioning, “The response time for a search transaction under peak load of 10,000 users must not exceed 2 seconds” they would state “The system should be fast when the number of users is high”.
Example 2
Similarly, instead of stating “the throughput of the system should be 100 search transactions per second”, they would say “the system must accept a high number of search commands”.
Example 3
They would state “I want a secure system”, or “I want a system that is easy to use”.
It can be a challenge to transform these qualitative requirements into quantitative ones with specific numbers, such as:
- 10,000 users peak load
- 2-second response time
- 100 transactions per second throughput
- “Users must learn how to perform the search transaction after 3 attempts”
This should be ideally taken care in requirements engineering process, where vague, non-functional requirements can be transformed into quantitative ones. Without being quantitative, requirements cannot be properly designed and later measured.
Collaboration Between Analysts and Designers
When attempting to quantify non-functional requirements, the collaboration between analysts and designers become necessary. The primary reason is that designers are the ones who understand the architecture of the system i.e. if non-functional requirements are feasible or not. For example, a business analyst without a deep understanding of system architecture might happily add in the final SRS document a quantifiable non-functional requirement specifying the response time as 2 seconds.
From a business analyst’s perspective, this is a well-stated requirement. However, it is the designer who understands based on the system’s architecture if such a number is feasible or not. Without the designer’s involvement, the analyst might approve the requirement leading it to become part of the contract with the customer. Quite often, there are situations where a designer informs the analyst that such a requirement is not feasible. Such situations can create all sorts of bottlenecks and lead to a negative impression of the organization in front of the customer.
Analysis and Design
Non-functional requirements are highly related in an iterative phase.
This continues until the non-functional requirements are deemed feasible and non-conflicting. Of course, this does not eliminate the risk of a designer finding out non-feasible requirements at the later stages of design when the solution becomes more understood, but this process reduces this risk to a minimum.
Many times a non-functional requirement can lead to other functional requirements. Here is a classic example, although security is a non-functional requirement, a statement such as systems must be secured against unauthorized access will typically require use cases of a user-login and user-registration, both of which are functional requirements.
Summing-up
Defining and capturing requirements is a prerequisite for any software development company before taking up projects. Generally speaking, most of the processes and requirements are clearly defined, and employees engaged in projects are aware of these requirements. It is largely the non-functional requirements that are quite often overlooked. When the functional and non-functional requirements are precisely captured keeping into perspective users interaction with the application, you can be assured about the success of your project.
Author
 |
Venkatesh Ganji is a Senior Business Analyst at Evoke Technologies. With his extensive knowledge and experience as a Business Analyst, Venkat is instrumental in identifying and translating stakeholder requirements into tangible deliverables. In his spare time, Venkat enjoys reading and spending time with family and friends. |
