Understanding Functional Requirements

In this tutorial, we would be taking a deeper look into functional software requirements.

But before we dive in, let’s quickly define these key terms.

Function: 

Merriam Webster dictionary describes “function” as the special purpose for which a thing exists or is used.

Requirement:

Requirement implies something that must be done 

Functional requirements, therefore, are requirements provided by the customer to the software company which specifies how the software is going to perform. It tells us how the system should react to some given inputs and how the system should behave in particular situations. It describes what the system should do as well as, what the system should not do. For instance, if we take banking software, for example, a banking software can have a deposit feature, another functional requirement can be, a user should be able to open a new bank account by filling an online form. We can also have another functional requirement like; users should be able to log in by providing their account number, account name, and pin. We can also have something like: the system should not fail when there’s a power failure, the system should not log in when an invalid pin is provided.

In simple words, functional requirements tell us how the system is going to function.

A functional requirement is dependent on the type of software being developed, the targeted users of the software as well as the method of approach applied by the organization in writing the requirements. For instance, if you are developing a health care software, the requirements are different also, the users are different, and examples of users can be doctors, nurses, pregnant women, and so on. If you are developing college software, the requirements are different and likewise users are different, users can be students, teachers, and so on.

Functional software requirements explain the system functions in detail, its inputs and outputs, exceptions, and so on.

Characteristics of a good requirement

Unambiguous: A good requirement is clearly expressed and understood. It is not written in such a way that is confusing to the reader.

Testable: a good requirement can be easily tested after implementation is done to ascertain the level of progress.

Feasible:  It doesn’t appear complex but is rather measurable and achievable.

Atomic: a good functional requirement is well written out unit by unit. No two requirements are mixed up together. This allows for easy tracing.

Valuable: The requirement must be of value to the intended final user of the software.

Estimable: The requirement must be estimable. We should be able to measure and estimate how long it will take to turn that requirement into a working software solution.

Small: for large requirements, we want to be able to split them into smaller concise requirements that are very easy for the developer to understand and implement.

Complete: All services required by the user should be fully stated and well defined to ensure that no part of the requirement is missing.

Consistency: The overall definitions of each requirement should be consistent at every point in time throughout the SDLC process. No requirement should have contradictory definitions.

Examples of functional requirements

Functional requirement for obstetrics healthcare patient management (OHPM) system of a hospital, used to provide health care to pregnant women until after delivery.

1. A user shall be able to register for antenatal by entering her name, address, password, and period of pregnancy in months.
2. A user shall be able to view a list of available doctors by clicking on the “book consultation” icon.
3. A user shall be able to have a live chat with a doctor by clicking on the “chat now” icon.
4. A user can only log in with a valid username and password.
5. Only registered employees (doctors) have the right to view patient’s data.
6. The software should automatically save all patients’ data in the system’s database after a successful registration.
7. The software should not allow unregistered and unproved doctors to attend to patients.

Functional requirement for a university software used to handle administrative and academic activities.

1. There should be a payroll option for school fees and other payments.
2. There should be an icon for the master’s academic calendar.
3. Users should be able to check all school events for the session by clicking on the events options.
4. The user (students) should be able to chat with other students by clicking on the “chat room” option
5. The student user should be able to chat with a lecturer by clicking on the “consult” icon
6. The student should be able to access all registered courses for the semester by clicking on the “my courses” option.
7. The users (both students and lecturers) should be able to view all locations of the university campus by clicking on the “campus map” option.
8. There should be a pop-up notification for important information

Types of functional requirements

1. Business rules:

The business rule is a term used to describe the aspects of your software requirements that deal with the basic activities of your business and how things work. 

Example of business rule requirement for a university software:

 Students should be able to register new courses for the semester by clicking on the “register courses” option.

2. Administrative functions:

These are requirements that deal with the management of the business or organization.

Example administrative requirement:

Registered admin staff can have access to student details by login in with admin ID.

3. Authentication: 

These are functional requirements that deal with verifying the identity of the user. Example of Authentication requirement:

 Users can log in by entering their matric number and password.

4. Certification requirements:

These requirements deal with the process of certifying users of the software. 

Example of certification requirement:

Only graduated students with a minimum of pass grade can print certificates.

5. Audit tracking: 

This requirement deals with the process of tracking registered user data. It is mostly accessible to the admin staff of the organization. 

Example of audit tracking requirement:

Admin staff can remove unwanted student details from the record by clicking on the remove button.

6. Historical data requirements:

All recorded data in the organization’s database can be managed on the software system. These requirements ensure effective data management.

Example of historical data requirements:

Users can view old student results up till the year the school was established by clicking on the “check student results” option and selecting the corresponding year.

7. Reporting requirements:

 These deal with creating and sharing the business reports of the company or organization.  

Example of reporting requirements:

The user should get notifications of school events every week.

8. Legal or Regulatory requirements:

These requirements deal with all the rules and regulations of the organization and the compliance with these rules. 

Example of Regulatory requirements:

The user (students) can only view the school’s academic calendar after logging into the software. 

Dissimilarities between functional and Nonfunctional requirements

In conclusion

A software can only be understood and utilized only when certain commands and instructions are assigned to it. Functional requirements are a way of assigning all the necessary instructions and commands that establish the software for use.