Functional requirements

Previous: https://medium.com/@svosh2/who-is-the-architect-c3aeb8daf427

We already defined who the stakeholders are and now we will explain what they need.

All the customers involved in the process have their own pains and goals. These goals can be transformed into some requirements that the system should be able to cover. These goals define, what the system will do.

IMPORTANT:
Functional requirements — what the system should do according to a stakeholder’s needs.

Thus our stakeholders are members of very different groups they may produce very different requirements.

Here are some functional requirements categories divided by their focus areas(examples are included):

Functional category:

• User Authentication: The system shall allow users to register, log in, and manage their user accounts with appropriate security measures.
• Data Input: The system shall allow users to input various types of data, such as text, numbers, dates, and files, through user-friendly forms or interfaces.

Information category:

• Data Storage: The system shall store user data, such as profiles, preferences, and transaction history, in a secure and scalable database for future retrieval and analysis.
• Reporting and Analytics: The system shall generate reports and provide analytics capabilities to analyze and present data in a meaningful way, enabling users to make informed decisions based on the available information.

Concurrency category:

• Concurrent User Support: The system shall be capable of handling a specified number of concurrent users, ensuring that multiple users can access and use the system simultaneously without experiencing significant performance degradation.
• Data Concurrency Control: The system shall implement appropriate mechanisms, such as locks or timestamps, to manage concurrent access and modifications to shared data, ensuring data consistency and preventing conflicts.

Development category:

• Modularity and Extensibility: The system shall be designed and implemented in a modular manner, allowing for easy integration of new features, enhancements, or third-party components in the future without significant impact on the existing system.
• Code Documentation: The system’s source code shall be adequately documented to facilitate understanding, maintenance, and future development by other developers or teams.

Operational category:

• System Backup and Recovery: The system shall provide automated backup mechanisms to regularly create and store system backups, allowing for data recovery in the event of hardware failure, data corruption, or other unforeseen incidents.
• System Monitoring and Logging: The system shall have built-in monitoring and logging capabilities to track system performance, identify errors or exceptions, and facilitate troubleshooting and performance optimization.

NOTE: It’s important to note that these examples are just a few possibilities, and the specific functional requirements for a given system will vary depending on the nature of the project, stakeholders’ needs, and the intended functionality of the system. It’s absolutely not mandatory that you will face all of the categories together in one project.

To declare more clear relationships between stakeholders and functional requirements, let’s take a look at a few examples:

EXAMPLE: As we can remember from the previous article — we have the next stakeholders of a bicycle:
The father — wants to buy a durable bicycle made by a well-known brand so his Son will retrieve the best from what he can give him.
His functional requirements can be defined as:
1) The bicycle should be durable (should have certificates etc.)
2) The bicycle should be made by a well-known brand (and has a warranty
from it)

The mother — wants her Son to be in safety first of all.
Her functional requirements:
3) The bicycle should have a maximum level of safety (all the protections should be included, all the lights should work, breaks should be in
the best shape)

Son — well… He just wants a black bicycle with a Spiderman image on its frame. And it should be ultimately fast.
His functional requirements:
4) bicycle should be able to move at 30km/h speed (and this requirement contradicts a Mother’s requirements)

Pains and needs of a Bicycle Seller we will move out of scope.

EXAMPLE 2: The pet clinic web app has next stakeholders:
Individual patients — want to be able to schedule encounters with their pets and
take online consultations about their questions.
Functional requirements:
1) The system should provide the ability to schedule an encounter using a web interface
2) The system should support an online tool with answers to popular questions

Pet doctors — they want to be able to check and manage their schedules.
Functional requirements:
3) System should give the ability for doctors to manage their schedule using the web interface

Developers (SRE, testers, designers) — want the system to be able to test, extend, and support in a straightforward way.
Functional requirements:
4) The system should support tools simplification support (logs, traces, metrics, and dashboards)
5) The system should be well documented and this documentation should be supported (prepare documentation templates)
6) The system should be easy to extend (consider modular architecture)

Pet shops — want to be able to place their advertising so the petitions will see it Functional requirements:
7) System should have the ability to add advertising to specific places in the web app (this specific requirement should be covered considering 6) )

As we can see — sometimes requirements from different stakeholders may cooperate with each other and add additional context, and sometimes these requirements may contradict each other.

But it’s not enough for us to know “what the system should do?”. We also would be glad to know “how the system will do it?”. Let’s discover this question deeply in the next article.

Next: https://medium.com/@svosh2/non-functional-requirements-ce6e55305900