Before you start building an ideal product which would bring the use to the target audience and bring profit to the creators, it is necessary to conduct a long preparatory work. Some say that this stage can be skipped, and everything can be solved on the go. Of course, such an option also has a right to exist, but in this case your project risks becoming an addition to the collection of “expectation vs reality” memes. To prevent this from happening, your idea must have specific forms, clear goals and, obviously, precise requirements that would be a certain basis of your project. Before the development process begins, a business analyst works closely with a client and gathers the requirements of two types: functional and non-functional. But how do they differ? Why are both types important in software development? In this article we will discuss the problem of requirements gathering and explain why a clear formulation of both functional and non-functional requirements is one of the key factors for your project success.
Functional Requirements (FR)
Each system possesses a set of features subsequently used by the audience. For instance, let’s consider an example of an online store. It is obvious that its core features should include the possibility for a user to log in, add products to the chart, and proceed with online payment. This is all about the system behavior and the way it interacts with a user. Such requirements that define how a product responds to the user’s requests are called functional. To elicit them in the most efficient way, the following points should be considered:
- Business Requirements
Basically, these requirements contain the final goal of the project, which benefits it may yield to the stakeholders and which limitations it will possess. - User Requirements
This is about which actions users will be able to take when interacting with the system. - System Requirements
This point includes the system actions along with software and hardware specifications.
Non-Functional Requirements (NFR)
Undoubtedly, it is not only important what the system can do, but also in what manner. In other words, how the system carries out its functions. The requirements not related to the functional aspect of the software are called non-functional and determine the attributes expected from the system. Let’s get back to the example of an online store described in the paragraph with functional requirements. Say, it is expected that the store will be used by millions of users simultaneously, which should not have a negative impact on the app performance. Or, for instance, the web page downloading time should not exceed three seconds. Both these examples reflect the non-functional requirements, and are no less vital than functional, because good user experience depends exactly on them. To formulate the list of non-functional requirements, it is necessary to pay attention to a variety of aspects, and below is the list of points NFR may be related to (may vary depending on the product type):
- Usability
Defines how user-friendly your system is. For instance, this parameter may include the buttons size and color, or the amount of the written content. - Security
If you operate in the industry which handles sensitive information, financial for instance, your system must possess the highest level of security. - Scalability
If you have an online store and plan to have sales, keep in mind that your application should pass the “Black Friday test”. - Reliability
This parameter determines the environment or a particular period of time the system must operate flawlessly, without any minimal failures. - Maintainability
This point determines how the system will be maintained and updated after launch, and if it will be the burden of the in-house team or your software development partner. - Performance
Estimates how quickly the system responds to the users’ requests.
Read Also What is the Role of a Business Analyst in a Startup
Documenting the Requirements. Why and How?
Well, the work with requirements does not stop after they are elicited by a business analyst. When all the needs and wants are clear for the team involved in the further development process, there comes another stage of documenting both types of the requirements. But is it really that necessary? In theory, it could be possible to develop the product right away, without any document. But the reality shows that this option is fraught with further miscommunications and misunderstandings between the team providing custom software development services and the client. Also, we are all humans, and we are no strangers to some negative human traits, such as forgetfulness. To provide both parties with the certainty that all the aspects of the project are clear and everything will be fulfilled accordingly, a business analyst creates the special document where all the requirements are prescribed. It may exist in different forms, such as specification documents, user stories or use cases. Let’s consider them one by one in detail.
Read Also In-house Vs. Outsourcing Software Development. Benefits and Pitfalls of Each Option
Software Requirements Specification (SRS)
The main pillar of the team involved in the development of the future application is software requirements specification (SRS). It contains the comprehensive description of all needs and wants formulated by a customer and translated by a business analyst into a language understandable for the team of developers. Therefore, all the requirements, both functional and non-functional are recorded in the specification, and technical specialists use it as a project guideline. As a rule, software requirements specification has a typical structure with the paragraphs outlined below:
- Introduction
The initial point of software requirements specification, which outlines the main goals of the project, the glossary of terms and also references. - Description
This chapter is dedicated to the detailed specification of the product features, coding standards and project limitations. - System Features
After project description there follows the specification of how this or that feature should work. - External Interface Requirements
This point includes the description of how your application is expected to interact with the environment, such be it a database or a hardware. - Non-functional Requirements
The final paragraph contains the application quality parameters, along with the performance standards and security regulations.
User Stories (US)
User requirements can also be recorded in the form of user stories. This documentation method is focused more on conversation than on writing, which makes it highly collaborative. Basically, it describes the product functionality from the end-user’s perspective and has a common template: as (a user) I want to (purpose) so that (reason). Let’s consider some simple examples of an Uber-like app user: “as a passenger I want my location to be determined automatically so that I would not need to spend extra time entering the address”. Another example can be considered from the app driver’s perspective: “as a driver I want to have a possibility to assess the passengers so that I could block the ones who misbehaved”. This form of requirements documentation is pretty easy and much shorter than any software requirements specification.
Use Cases (UC)
Agile development routine also includes such a thing as use cases, which at first glance is very similar to the user stories approach, but in fact is quite different. When the US describes the purpose of this or that feature, the UC in its turn is about the steps that need to be taken on the way to accomplish the purpose. For instance, if you intend to build a supply chain software, you need to take into account that its functioning will involve a big number of parties including buyers, suppliers, warehouse managers etc. And their roles may include a wide range of actions, such as: “both sellers and buyers can track the current location of the product” or “all company managers can see the ordered product’s payment status”.
Conclusions
Well, the proper work with the requirements means much in software development. Of course it is possible to develop a product without time-consuming and labor-intensive preparatory work. It is totally up to you to decide, but it is highly recommended not to skip this step due to possible misunderstandings that may arise during the development process, which, in their turn, will take much more time and nerves than gathering and documenting the requirements beforehand. If you currently have a project idea but do not know where to start, please contact us, our team will help you to develop the product in compliance with all your requirements.