Software requirements analysis is a major SDLC approach and a leading step in the Software development Life cycle. In this tutorial, we’ll take a deep look at Software requirements analysis and various examples of it.
Software requirements are all the capabilities that the new system must meet. For instance, if you are going to create a website where you sold pet supplies, for example, your list of requirements would include things like: my website needs to accept credit cards, it needs to look like a friendly pet website as opposed to a business website or a lawyer’s website, it must be fast and so on. You could even describe how you want your information presented so that maybe a certain number of products are displayed on every page or maybe you just want text names of your products or maybe you just want giant pictures with small little taglines of what it is. So likewise you have to decide what it is that you want the new software to have and just make a list of all those things. Software requirements consist of functional and Non-functional requirements.
Functional requirements:
Functional requirements describe the functionality of a system or system services. It depends on the type of software we are using and expected users. It explains an activity or process that the system must perform. So you are looking at this from the business users’ standpoint. If you are creating something that helps them solve one of their problems relating to accounting for example, then all of the functional requirements are going to be about accounting.
Examples include:
- Maintain customer information
- Maintain product inventory
- Order processing
- Billing
- Management reports
- Shipping etc.
Non-functional requirements:
This defines the system properties and constraints. It describes the operational characteristics related to the system. These are techy nerdy things. These are general requirements that are not specific to the business alone. Now using the example stated earlier, we can say that they are requirements that are not specific to accounting alone.
Examples include:
- Technical requirements
- Performance requirements
- Usability requirements
- Reliability requirements
- Storage requirements
- Response time
- Security requirements etc.
Software requirement specification (SRS) document
A requirement specification for a software system is a complete description of the behavior of the system to be developed. It includes a set of use cases that describes all interactions the users will have with the software. So these requirements reflect the needs of the customers for a system that helps to solve some problems.
Documenting the software requirement specification (SRS)
The SRS document consists of the following:
- Introduction:
Here you state the purpose of your project. You define the scope, you state all the definitions, system overview as well as your references.
- Overall description:
In the overall description, you need to cover the product perspective, state the product functions, user characteristics, constraints, assumptions, and dependencies.
- Specific requirements:
In the specific requirements, you describe the external interfaces, functions, performance requirements, logical database requirements, design constraints, and key features.
- Validation checks:
After designing and developing the product, you need to specify some checks to be carried out such as validity check, consistency check, realism check, verifiability check, and completeness check.
- Validation techniques:
Here you state the validation techniques to be implemented in the product such as Requirement reviews to be taken, prototyping techniques to be followed, test case generations to be written.
Why should you document a software requirement?
In a project, you want to deliver the desired result on time, within the budget, and in the quality required by the customer. If you do not document your software project requirements, you may overlook the functionality or completely misinterpret your customer’s expectations. This causes additional efforts, costs, and delays. You can also fail to see the aspects of your project that are vital to the functional and non-functional requirements of your software. This can lead to false starts or even additional development circles. An important reason for documenting software requirements is that you need to consider more than your customer’s expectations.
Importance of analyzing software requirements
Analysis should be carried out on the requirements to check for its feasibility as well as possible associated risks. These two are closely related. If you are unsure about the feasibility of a requirement, there is a risk associated with that because finding a suitable solution might take the time or there might be no existing solution at all. Also, the testability of the requirements should be analyzed. The analysis should also cover the technical implications. This includes the assessment of dependencies between the various requirements. An example of this could be the close button of a typical window regulator engine control unit. When the close button is selected, the windowpane slides upwards until the window is completely closed but also, there’s a safety function that has a contrary effect on the closing action. This function is called the anti-pinch function. This anti-pinch function is designed to prevent fingers from getting caught when the window is closed. There are obvious dependence and mutual technical implications between these requirements. This should be taken into consideration during the requirement analysis. The business aspects of the requirements should also be incorporated in the analysis. There’s a need to determine how the implementation of the various requirements affects costs and timeline.
How to analyze requirements using various quality parameters.
The quality of software requirements can be determined using various parameters.
- Atomic:
This implies that the requirement should be well spelled out, and not mixed up with other information. It is preferable to itemize key points separately rather than to mix up two pieces of information with the use of “and”. This is shown in the example below. Assuming we are building a software system for online coding courses.
Example of proper and improper requirement:
| Improper requirement | Proper requirement |
| The applicant will be able to apply for Python programming and Java programming classes | Applicants will be able to apply for a Python programming class applicants will be able to apply for a Java programming class |
- Uniquely identified:
When several requirements are listed with id numbers, the id numbers for each requirement must be different and specific to each requirement. This is illustrated in the example below.
Example of proper and improper requirement:
| Improper requirement | Proper requirement |
| 1. Applicant will be able to apply for Python programming class 1. Applicant will be able to apply for Java programming class | 1.1 Applicant will be able to apply for Python programming class 1.2 Applicant will be able to apply for Java programming class |
- Completeness:
This implies that the details of a requirement must be completely started with exact information and not generalized information. This is shown in the next example below.
Example of proper and improper requirement:
| Improper requirement | Proper requirement |
| A registered user will log into the system by providing his email address password and other important information. | A registered user will log into the system by providing his email address, password, and phone number. |
- Consistent and unambiguous:
This implies that the requirements must not be contradictory to each other. The requirement must be easily understood. An example is shown below.
Example of proper and improper requirement:
| Improper requirement | Proper requirement |
| Applicants will have either beginner’s class or master’s class but not both. Some classes will be open to both masters and beginners. | An applicant will have either beginner’s class or master’s class but not both. |
- Traceability:
The given requirement must have a unique value number that is easily traceable.
Example of proper and improper requirement:
| Improper requirement | Proper requirement |
| Maintain applicant data mapped to BRD req. ID | Maintain applicant data mapped to BRD req. ID 2.3 |
- Prioritized:
When requirements are listed, they should be listed in order of priority by assigning a unique priority level to each requirement. This enables proper implementation and enhances traceability. This is shown in the example below.
Example of proper and improper requirement:
| Improper requirement | Proper requirement |
| Register applicants Maintain user data Billing View result | Register applicants priority 1 Maintain user data priority 2 Billing priority 1 View result priority 3 |
- Testability:
The requirements should be stated in such a way that they are easily testable after implementation. This is achieved by assigning specific values to specific requirements. See the example below.
Example of proper and improper requirement:
| Improper requirement | Proper requirement |
| Every page of the system will load in a reasonable time-frame. | The home page, as well as the billing pages of the system, will load within 6 seconds. |
Conclusion
Software requirement analysis is a key aspect of the software development life cycle and there is a need to fully understand the concept to ensure a smooth journey in the software development process. If you write your software documentation before you start your product, you will get a complete idea about the product, what you have to do and what the user requirements are. Based on the requirements, you will have an idea of what you need to develop and in which stages, also how the product is divided into modules (smaller units), which module will be given to which team, and how you are going to integrate it finally so that everything will be covered in the SRS document.
One Response