DEV Community

Cover image for Requirements
Jeferson 'Shin' Leite Borges
Jeferson 'Shin' Leite Borges

Posted on

Requirements

What are these texts?
I was studing and for me to have some real study done I need to write it down, this is a small collection of topics that I studied in the last few weeks.
Other links from the same study-pool:

What are requirements?

What you are going to accomplish is defined by the requirements. What will be included, what won't be included, how it will be done, and who will do it. Possible risks to the project, as well as criteria to measure the project's success, are often included in requirements. This information for the reader may include charts, graphs, diagrams, use cases, and mock-ups. It is necessary to define a project's need as well as the solution in order to write effective requirements. To write effective requirements, it must define a project's need as well as the solution.

What are functional requirements?

In software development, functional requirements determine the functions an entire application or just one of its components should perform. A function consists of three steps: data input – system behavior – data output. It can calculate, manipulate data, carry out business processes, establish user interaction, or do any other tasks. In other words, a functional requirement is WHAT an application must or must not do after some data input. Functional requirements are important as they show software developers how the system is intended to behave. If the system doesn’t meet functional requirements it means that it doesn’t work properly.

Function requirements determine the functions of an entire application or some (or even one) component. The three steps of a function are: data input, system behavior and data output. It can do a lot of things, such as calculating, manipulating data, carrying out business processes, and establishing user interaction. A functional requirement is what an application must or cannot do after some data input. Functional requirements show how the system is intended to work. The system doesn't work properly if it doesn't meet functional requirements. In other words, a functional requirement is WHAT the software should do.

What are non-functional requirements?

The performance and quality characteristics of software, such as system usability, effectiveness, security, and scalability, are considered non-functional requirements. For instance, a website must load in no more than 3 seconds and be able to serve more than 15 million people without seeing any performance issues. An app will still be able to carry out its essential tasks if non-functional requirements aren't met, but it won't be able to offer a satisfying user experience. Non-functional requirements are crucial because they aid in defining the system capabilities and restrictions necessary for producing high-quality software. Therefore, for effective product adoption, non-functional criteria are just as crucial as functional needs. In other words, a functional requirement is HOW the software should do.

How they differ?

The benefit of understanding the distinction between functional and non-functional requirements is that they specify the project's overall scope of work and budge. To create an application within the specified time and financial constraints, software engineers must stay current with this scope. The development team must prolong deadlines when the scope of the task is continually changing, which raises development expenses. This could have negative effects on a project.

When developing an MVP, it's critical to distinguish between the two categories of criteria. The features and functionality that should be included to the app first should be discussed by the development team and the client. A client could have his or her own ideas on the project's specifications. It's crucial to understand what kind of demand it is if a customer decides they want to remove or modify a feature. Software engineers can typically adjust non-functional needs with little effort, but functional requirements usually take more effort and significant modifications.

Where requirements comes from?

Customers should ideally have all the functional and non-functional requirements ready before contacting starting the development. Therefore, they must either seek a third party source or prepare them in advance on their own. These are some groups examples of functional requirements:

  • Business requirements: outline the project's objectives and expectations, potential advantages, potential restrictions, and scope.
  • User requirements – include the user's requirements and the system's capabilities for the user's activities.
  • System requirements – include system activities, hardware and software requirements, and other information

There is also some groups for non-functional requirements:

  • Availability – ensures that the software will operate reliably for a specific amount of time, such as with minimal downtime throughout the year.
  • Capacity – determines how much data or services the application can handle.
  • Performance – determines the app's speed.
  • Recoverability – assures that the app can restore the system to a specific set of parameters or recover all the data following a system failure.
  • Reliability – specifies that the application will operate without interruption in a specified environment or for a set amount of time.
  • Scalability – decides whether the app's functionality will remain unaffected by changes to its size or volume.
  • Security – establishes the level of security that the app should have, for instance, banking and fintech apps must adhere to national and international security standards.
  • Supportability – indicates whether the app is simple to support and maintain throughout its life cycle and what type of help is needed, such as an internal team or remote support.
  • Usability – determines how easily a user may interact with the app's interface, such as the color of the screen and the size of the buttons.

How can I express some requirements?

User Stories

It is standard procedure to write the requirements as user stories. User stories are the requirements that a user communicates. They typically take the shape of multiple short, repetitive sentences:

  • As a (user), I want to (goal) so that (reason).

When needed to explain or show to non-technical members, user stories are helpful and can explain easily most of the features and functionalities needed on the project.

Software Requirements Specification Document

A software development team can use the Software Requirements Specification (SRS) document to guide their work when developing an app. It contains a thorough explanation of all the features and functions of the product, as well as a compilation of all the customers' needs and wishes in a language that is understandable to the development team.

An SRS document typically has the following major sections:

  • Intro: a brief introduction that includes the goal of the product, a glossary of words, and references to relevant literature and resources for the development of the app
  • Description: description includes a thorough explanation of the characteristics of the product, coding guidelines, data interchange rules, and more.
  • Features: the section on system features, which describes how the features of the app should work.
  • Non-functional: Non-functional criteria include all performance benchmarks, the qualities of an app, and security specifications.

For efficient application development, user cases, user stories, and SRS generation are crucial. However, there are other documents that are just as crucial for the beginning and growth of a project.

Other tools

There are huge variety of tools and methodologies that could be applied for development. These are some that can be used, modified or even based on to create new ones.

Top comments (0)