Software development is a complicated process that requires detailed preparation before starting the coding phase. In this topic, you will learn about an important stage of the application development lifecycle, in which you form Software requirements for the application. You'll explore two software requirement types, learn what their purpose is, and how to document them.
What are the requirements?
A software requirement is a feature or property of the software you have to implement for the customer. When you want to build software, you must first define what you are going to build as a set of requirements during the Requirements engineering phase. This is a very important skill that each software engineer should have. Unlike a programmer who just gets a task and implements the required functionality, an engineer knows how to design requirements for an application and knows how to implement them.
Requirements are important since they show the project goals and objectives, what a final product should do and how it should operate. Clearly defined requirements can help identify potential risks that may arise during development and prepare for them. The development team can use it to ensure they are moving in the right direction to satisfy customers' needs. Further in this topic, you'll explore two types of software requirements: functional and non-functional based on the FURPS+ model. Note, that except for software requirements, there are also others, such as Business and User requirements.
Functional requirements
In the FURPS+ model, the "F" stands for functionality. Functional requirements are features of the software and what the system is expected to do. In practice, they typically can be expressed in terms of inputs, processes, and outputs. Here the input is an action performed by the user to interact with the system, the process is the response of the system to the input that transforms into the output as a result. For instance, when users input their credentials and log in to the system it is an input. Then the system starts the authentication and authorization processes and grants or denies access to the system as an output.
If we want to describe the login functionality as a functional requirement, we can define it the following way:
The user must be able to log in to the system using an email and a password.
The user must be able to log in to the system using a phone number and a password.
The user must be able to log in to the system via a Google/Apple/Microsoft account.
The user must be able to set a two-factor authentication.
In an agile environment functional requirements can be defined in the scope of user stories.
Functional requirements can vary depending on project needs and domain. However, they have one common purpose to define the functionality of the software, and what it should do.
Non-functional requirements
Non-functional requirements describe the system's behavior and how it should operate in different cases when end-users or any other system interact with it. They let you set user expectations for the system operation and ensure that your software satisfies them. According to the FURPS+ model, non-functional requirements are:
Usability: defines the ease of use for users. How they can learn to interact with the system.
Reliability: this requirement defines the ability of the system to perform as expected without issues under certain conditions.
Performance: defines the performance of the system in various metrics and how it can handle a large number of requests. It includes the response time, throughput, availability, and accuracy.
Supportability: describes how easily the system can be modified. It covers the adaptability, maintainability, and portability properties of the system.
These are the so-called quality requirements of the system. In this approach, there are also additional pseudo requirements or constraints that the "+" stands for. They are:
Implementation requirements: they define how the system should be implemented. What frameworks, libraries, or programming languages will be used, and so on.
Interface requirements: such constraints are set by external systems.
Operations requirements: these are constraints on the administration and management of the system during its operation.
Packaging requirements: constraints on the delivery of the system.
Legal requirements: this includes licensing, regulation, and certification constraints.
Requirements are an important part of the software design process that is desired to be and should be documented. Let's move to the next section to explore some tools for this purpose.
Documenting requirements
Requirement documentation is an important communication channel between a customer and a team working on the project, including product owners, business and system analysts, product and project managers, and the development team. This helps to plan project details and avoid many issues, saving time and financial resources. Fortunately, the market provides many solutions we can use to document requirements in a clear and in detailed manner. In this section, you will explore several diagram types and enterprise software that you can use to document your project requirements.
Here are some examples of diagrams:
Functional decomposition: With this technique, you can break down your system into parts and show how they interact with each other.
Use Case Diagram: This is a diagram that represents scenarios of how users can interact with the system.
Context Diagram: Such a diagram describes how the system interacts with the surrounding environment entities.
Above mentioned diagrams can be complex and carry a large amount of data but you don't need advanced tools to create them. Simple visual design tools can be enough, but you can also use complex tools. They are shipped with many useful features to manage this process, including UML modeling. Among them are:
StarUML
Jama Software
IBM Engineering Requirements Management DOORS Next
Besides these enterprise solutions task management systems like Atlassian Jira or Azure DevOps also include features you can use for requirements management.
Conclusion
In this topic, we discussed the idea of software requirements. You learned about functional and non-functional requirements, how the FURPS+ model defines these types, and what kind of information each requirement type provides about the software system. Another important benefit of the topic is the different approaches and software solutions you can use during this process. If you have pet projects, we recommend that you try to describe them in the form of functional and non-functional requirements using these tools. This will be a good practice that will be useful to have.