Functional vs Technical Requirements Document : Business Analysts and System Analysts FAQ

Any system that has to be built by an organization/company starts just as documents. This requirements documents are the ones that speak out the customer minds. What is expected of the system? How is it going to be used? Who is going use it? What are the things that the system should support? What new “Out-of-the-box” features are expected now/in future? Well, you have all such questions answered by the customer in these documents.

Not all requirements are going to be handled by the programmers and System Analysts alike. Not all requirements makes sense in the same way! Some requirements can just give you idea what is to be built as system- this is helpful for the programmers- Whilst, some others can give you the requirements as facts that have to be true- these may be just the ones that can alter the entire requirement and technology usages. Formally taken these are the ones that are respectively called as the Functional and Technical requirements.

Functional requirements and uses:
These are the ones that say what is expected from a system. They are the ones that get transformed into the UMLs and the UseCases. What exactly is the system going to achieve. It can be stated in informal terms like “the system should get input A and give output Ax”. This is just a plain practical usage description from the customer. We can make out easily that there is no specification from customer as to how this should be done. All we are worried about in case of the functional requirements are the higher level system interaction and behaviour. They describe the system!

Technical requirements and implications:

The technical requirements are giving the information to the developers as to what the system must adhere to. They are more often just facts that have to be true about the final system. Let us say for example “the system should handle 300 calls per second for over 8 hours”. Here we just are able to see what is expectation from customer. These are just guidelines that can have implications over on the developer’s way of developing a code. These are refinements that have to be considered when designing a system technically. Some software systems can come in with technical requirement as “program should run on the Java platform”. In such a case the system to be built is meant for java, so has to be built compatibly.

Ideally, the technical requirements should give an insight as to what is being required basically from the client. More of the technical stuff just makes the requirement a constraint over the system. Most of the technical requirements can be converted to functional requirements by very good questioning. There are also some technical requirements that are put in to have a standard or to maintain a generality of operation. In such a case, the development should take in the requirement as one on which the other functional requirements are based. For a really successful development process identification of the correlation between the functional requirements and corresponding technical requirements/constraints is really important and that can happen when they are both stated and represented well to the team.