Architecture: Functional Requirements

What are Functional Requirements?

Functional requirements detail the behavior of the intended system. This is from the workflow to the end-user interface. You want to ensure that each functional requirement that you capture is just that. One. You don’t want to have more than one functionality written in a requirement for various reasons:

1. You’ll lose money. When you go to design the system, then you might realize that the bunched-up requirements are really unrelated, and you will have to come out of your pocket to still give your client what they paid for.
2. You will screw up your design. As I said in the first reason, you might realize that the design functions are different. When you try to cut corners, then you will end up with a design that is more flawed than it should be.
3. You will end up losing tons of resources and time to fixing the system. It is like a domino effect. If you don’t have solid requirements, then your system design will fail. If your system design is flawed, then the building of the system will be.

Yes, you should group your requirements, so that you have them organized in a way that it’s easy for everyone involved to follow.

How to Group Requirements?

There are several ways to group requirements, but you want to do it in a way that doesn’t confuse anyone.  Remember that requirements are something that are usually viewed by multiple group of people with varying levels of knowledge. Therefore, you want to ensure that you don’t alienate any of them. Here are two ways to group requirements:

• By Functionality – This is probably the best way to group your requirements.  You want to group similar requirements that are part of the same functional area.
• By Process – This is similar to functionality, except you can have different functions in one process.  If this is the route you want to take, ensure that the process is a small one.

There are other ways, like input and output, so it’s up to you.  Just remember: Think about all the user groups involved.

What Functional Requirements Should I Capture?

Here are the basic functional requirements that you should capture.  You have to remember that not all systems are the same, so you might have additional ones you have to capture for your system.

Business Rules

Every company works differently, so you want to capture all of their business rules. Business rules will influence how the system works, its security, and data management.

Interface Functional Requirements

Maybe once upon a time, you could have a system that was standalone, and everyone was happy.  In reality, times have changed.  Systems talk to one another, processes overlap, and workflows as well. Therefore, you have to capture the all the different kinds of interfaces because each of them will affect your system. These are usually hardware, software, and user. You want to ensure that you capture the following information for each interface requirement group:

• Description of the interface
• Each data element, and how it transfers to and from the system
• Interface workflow

Remember that pictures are always a great thing to have, so try to have pictorial views of the information you are trying to explain.

Data Functional Requirements

If you don’t understand the data, then how will you understand what the system needs to do? You have to detail each data element, its format, any dependencies to other data elements, groupings (if any), and how it is used in the system. Also, you want to describe how it is captured. There are times that you will be doing some changes to the data flow.  You should capture the “as is” and how it will be transformed to the “to be.”

A good resource to create a data dictionary that can capture all this information.  If you ever need to see the detail of a data element, you have it right there.  It makes it easier than having to sift through a long, detailed document.

Operational Requirements

This is the bulk of your functional requirements.  These requirements detail how the system will run and communicate.

Security

Security requirements are the different levels of security that the system will have.  This is from user security to administrative security, all the way to data security.  You want to capture if user groups will have different levels of access.  This means if one user group will be able to view sensitive information while another won’t. You also want to discuss the security of the location(s) that the system will be held in.

Audit Trail

Audit trails are important.  For instance, if you have a security breach or a failure, you can always go back to the audit trails to find out what happened.  There are different kind of audit trails.  There are some for data and interfaces.  This kind of audit trail will capture if the interface ran, what kind of data was captured, was it successful or not, and time.

The other kind of audit trail is user information.  Things like what user accessed the system, when, what kind of and what kind of information was accessed.

There are other kinds of audit trails. Remember, audit trails are your friends, so don’t skip this step.

Data Currency

Data Currency is self-explanatory.  It keeps track of how recent the data is. You also want to have the most recent data in your system.  If you don’t, then this can cause problems for users trying to access this data for their job.

Reporting Requirements

Systems usually output reports of all kinds.  Therefore, you really want to think and analyze all the reports that the client is going to need in the system.

Data Retention

You want to think about the different data that is collected, and the length that it has to be retained in the system.  Data retention also is where you want to discuss archiving.  You can archive data for longer periods of time, but how much data has to be right in users’ grasp.