Anatomy of a Software Development Role: Functional Analyst
The role of Functional Analyst is one of the keys for successful software development. In Cracking the Code: Breaking Down the Software Development Roles you get a high level view of the software development industry and the various roles involved including that of the Functional Analyst.
The role of the functional analyst (FA) is to capture, consolidate, and communicate the information from the Subject Matter Expertss (SMEs) to the rest of the team. This may seem odd if there's only one Subject Matter Expert; however, the typical case for a sizeable software development project is that it takes several SMEs in order to provide the necessary information to create a solution. Because of this the Functional Analyst is a critical link between the Subject Matter Experts providing the business requirements and the rest of the team trying to construct the solution.
Depending upon the organization that the software development is being performed in the functional analyst title may be called by other names as well. Another very common label for the FA is Business Analyst, or sometimes simply analyst. No matter what the name, the need to help capture, consolidate, and communicate the information from the SMEs to the rest of the team is the critical, bridge-the-gap, role that this person plays. An organizational chart gives you an idea of how each position fits together within an organization.
Click here to view the entire organizational chart.
What's a Functional Analyst?
The Functional Analyst is the facilitator for the Subject Matter Experts. The FA takes their input and transforms it into something that the development team can understand. One of the key components of this is clarifying the intent of the SME. The FA will spend a great deal of time asking questions like "What do you mean by that?" or "How does this fit in with what we were talking about earlier?" Questions like these expose potential, often subtle, differences in meaning between the SME and the rest of the development team. More importantly, these questions expose assumptions regarding business logic and processes that may not be clearly stated - or even stated at all by the SMEs.
FAs are also responsible for identifying and resolving conflicting requirements. If SME number 1 says the sky is blue and SME number 2 says the sky is red, it will be the FA's responsibility to resolve that discontinuity. This may be done by getting the SMEs together to agree or merely in understanding the different perspectives. For instance, perhaps SME number 2 was referring to the sky on Mars. A less abstract example would be if SME 1 considered the way to uniquely identify a customer to be using a person's social security number, where as SME 2 considers a customer to also include people from outside of the United States who don't necessarily have a social security number. If uniquely identifying a client is important, then it is the FA's responsibility to identify this and document the requirements.
Through the software development process a document or set of documents are being developed. These documents, the requirements documents, will represent the contract between the business that wants a solution and the software development team that wants to create the solution. A requirements document is, at the basest levels, a listing of all of the features or aspects that the final solution should have to fully solve the problem that the SME is describing.
The documents need to be understandable both by the SME and the development team. The SMEs will need the document to validate that the requirements for the project are correct in every detail. The development team needs the document so they know what is to be built. To accomplish both objectives the documents must be brief but thorough. They must also be expressed in both business and technical language. Done correctly they are the perfect balance between competing forces.
Getting Started as a Functional Analyst
In Real Estate it is said that there are only three things that matter: "Location, Location, Location." In that is a simple truth that sometimes there is one key attribute that drives all the rest. In the case of the FA that one attribute, or skill, is clear communications. So the starting point for a functional analyst is becoming a great communicator. Unlike Ronald Regan the objective in becoming a great communicator is not inspiring people with a vision. It is, instead, developing precise communication that will allow discovery of inner meaning and inconsistency that is essential.
Learning these skills is best done by working in positions requiring either leadership or detailed documentation. Leadership positions in professional or community organizations is an obvious target for training for the FA role, however, those roles require so many more things that they can often be distracting from the core skill that the FA needs to develop. A better role is the often-neglected role of secretary. While the obvious thought here is that the secretary is simply someone who is taking notes, the role can actually be an opportunity to safely develop the core skills for the FA role. Another benefit is that this role is rarely as contested as the role of leader of an organization.
Precision communication in most professional or community organizations isn't a overt requirement. It is often lacking because of the volunteer nature of the organization; however, most organizations appreciate the addition of the skill. The ability to clearly articulate the situations faced by the organization through precision communication is an immensely powerful tool for helping the mission of the organization. This being said, community organizations are often a safe place for the FA to learn this skill. The secretary role puts the potential FA into the position of being enabled to ask the detailed questions. As the note taker it's generally acceptable to others to ask the questions like "Can someone summarize what we decided?" or other questions that drive towards validating a common understanding. In addition questions such as "Can we clearly define what we mean here so that there are detailed notes of our commitment?" can be asked to drive into more precision communications. This is the exact kind of behavior that the FA will need to use to elicit clear communications from SMEs.
Building a requirements document is usually a key responsibility of the FA. Creating a good requirements document requires an insight into knowing when detail is necessary and when additional detail would only serve to clutter up the understanding. Just as there is no one recipe for creating cookies, there is no one formula for creating an awe-inspiring requirements document. In many ways creating a good requirements document is as much of an art form as it is about the science of capturing specific, numbered requirements.
What's in their Toolbox?
The functional analyst's toolbox is, first and foremost, a toolbox filled with communication and relationship skills. Although the FA has a set of technical skills, their greatest asset is their ability to communicate with others and to work relationships with others in the organization who can help to weave the SME feedback into context.
The FA's technical tool box is not extremely specialized, they largely have to use the same tools as other members of the software development team, however, in their case they sometimes have to be more skilled at the basic word processing, spreadsheet, and general office tools' use in order to support their deliverables.