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.
What do requirements mean in terms of software development?
There are several kinds of requirements:
- Business requirements are high-level goals. They answer the question of what the company and its employees need.
- Stakeholders’ requirements describe what business owners expect to receive in a particular situation.
- Solution requirements are the product characteristics that can satisfy both business and stakeholders’ expectations.
- Transition requirements formulate what functionality the company needs to achieve desirable efficiency or other business goals.
- Nonfunctional requirements are known as quality attributes; they describe common system characteristics, such as security or availability.
- Functional requirements describe the behavior of the software product in certain situations.
Let’s focus on the last two types of requirements
What are functional 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:
- Software requirements specification document (SRS)
- Use cases
- User stories
- Functional decomposition
- Software prototypes
Let’s further consider these 5 forms.
Software requirements specification document
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 case
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.
- Actors are the users who stand outside the system and communicate with it.
- The system is described with functional requirements that characterize the behavior of the product.
- Goals are the reasons why the interaction between actors and the system happens.
Use cases can be presented as a text or diagram that outlines a sequence of actions.
As a rule, a template specification includes:
- description
- pre- and post-interaction condition
- basic interaction path
- alternative path
- exception path
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:
- Use cases are presented in the form of an oval. They include different scenarios that can happen to actors, for example, searching or purchasing items in a web store.
- System boundaries are marked as a field that gathers different use cases in the system.
- Actors are portrayed as figures which interact with the system.
- Associations look like lines, which illustrate different types of relations between actors and use cases.
User story
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:
- Independent: every user story can be implemented separately, which helps roll out projects faster and deliver constantly deliver improvements.
- Negotiable: it is about the importance of discussion and detalization during development.
- Valuable: user stories should be useful, relevant, and important for the client.
- Estimable: clear assessment helps developers to prioritize their tasks and balance the time.
- Small: it is easy to estimate and work with a short and precise user story.
- Testable: testing user stories help QA engineers define whether the requirements were satisfied.
Functional decomposition
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,
verification.
Option B: High-level function,
sub-function,
process,
activity.
If the latest functions can’t be concretized, it means the WBS was drawn up correctly.
Software prototype
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:
- A wireframe is a graphical structure of a website or a web application that shows pages with interactive elements and sections.
- A mockup is a wireframe with visual elements of the product, say, logos and branded colors.
- A design prototype includes visual elements and details of interaction with the user interface. Design prototypes can be created with special services such as InVision or written in HTML or CSS.
What are nonfunctional requirements?
Nonfunctional requirements, also known as quality attributes, describe the characteristics that a system should have.
The most known nonfunctional requirements are:
Usability
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:
- Efficient usage: it is about the time necessary for the achievement of users’ goals and the number of activities that users can do themselves.
- Intuitive understanding: it means how easy it is to comprehend the interface and its elements.
- Low perceived workload: it depends on how much effort it takes the user to achieve the goal.
Security
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.
Reliability
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
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.
Availability
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.
Scalability
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.