Clear requirements can be compared with the guiding star which helps clients and software developers to achieve goals: release a quality product, avoid financial risks, and meet deadlines.
The process of drawing up requirements consists of several stages, such as information gathering, analysis, concretization, validation, and management. In this post, we’ll review functional and nonfunctional requirements in detail.
There are several kinds of requirements:
Let’s focus on the last two types of requirements
As we said above, functional requirements are product features that should be implemented by developers.
They should be clear and understandable for both developers and stakeholders. Functional requirements can be presented as a text, a diagram, or in any of the following convenient forms:
Let’s further consider these 5 forms.
This document includes a full description of the features which a product should have as well as its possible limitations. SRS can be presented in the form of a separate document or a series of use cases or user stories.
A person who works with requirements should register the requirement for every function before writing it. After the first customer feedback, SRS can be updated. SRS consists of goal definition, general description with a mockup or prototype of the product, and specific system or functional requirements.
Software requirements specification document should be readable for developers and stakeholders. Usually, software development companies create them on the basis of a template with visual highlighting and a clear structure, as this ensures an accurate and consistent treatment of every project.
Use cases describe the ways of interaction between a system and users. Simply put, they show how users can achieve certain goals. Every use case consists of three elements: actors, the system itself, and goals.
Use cases can be presented as a text or diagram that outlines a sequence of actions.
As a rule, a template specification includes:
The use case diagram gives a review of connections between actors and the system in different cases.
The following symbols are used in the diagram:
A user story is a documented description of software functions in terms of interaction with the end-user. A user story shows what the user expects from the system. User stories look like to-do lists consisting of product features. Normally, a user story can be presented as the following formula:
How <type of user>, I want <goal>, so that <reason>:
For example: As a content manager, I want to add 5 images to every product page so that customers can consider the looks of the product.
A user story goes hand in hand with acceptance criteria, basic features required by stakeholders to accept a product. Acceptance criteria should be clear and testable, in the form of a list, text, or the Given-When-Then description.
Good user stories should match the INVEST quality model:
Functional decomposition, also known as Work Breakdown Structure, helps to present the project as a clear scheme of understandable components.
There are two methods of construction of this structure:
Option A: The most general function,
a more concrete function,
the most concrete function,
Option B: High-level function,
If the latest functions can’t be concretized, it means the WBS was drawn up correctly.
Software prototypes contribute to illustrating how requirements should be implemented and how clients will work with the product. Also, prototypes can make weaknesses of the product more evident and this way they help developers prevent possible issues.
The two most popular ways of prototyping are throwaway or evolutionary. The one-time prototype is a rapidly prepared budget version of the requirements visualization. On the contrary, an evolutionary prototype can be an early version of the product or become a minimum viable product, aka MVP.
There are three most popular ways of prototype creating which can move on to each other:
Nonfunctional requirements, also known as quality attributes, describe the characteristics that a system should have.
The most known nonfunctional requirements are:
This attribute shows the level of convenience of using the product by the target market. Usability can be assessed with the help of such criteria:
Security requirements defend the software from unauthorized access to sensitive data. Security also implies the protection from viruses and cyber-attacks and determines different access levels for users. For example, only an admin can change certain information.
This characteristic is about how reliable the software is, how much time the system can work without mistakes and how easy it can be fixed. It depends on the quality of code, problems with other components or hardware.
Performance describes the quality of interactions between a user and a system. Unsatisfactory or slow performance leads to negative user experience and threats to system security. For example, performance requirements can include website page loading time or a number of users on the server at a time.
It is about the availability of the web application of the website during system updating. The customer needs to highlight the most important system components, which should be available at any time. Also, developers should prepare notifications for users when some parts of the product are not working.
It means that system growth and an increasing number of users and information shouldn’t affect its performance. Developers can use optimization algorithms or additional memory or servers. Yet, scalability depends a lot on a proper choice of the technology stack and software architecture.
Functional requirements are needed to ensure that software developers and customers are on the same page; everyone knows what to expect from the software and how to test and accept it. Requirements can be presented in different ways, from lists to software prototypes, but they should always be clear and unambiguous. Nonfunctional requirements are qualities that a product should have to meet customers’ expectations. The accuracy of functional and nonfunctional requirements leads to the qualitative product as a result.