Originally published on Developer.com, April 26, 2005.
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 Experts (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.
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. Click here to view the entire organizational chart.
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.
One of the most important tool to know how to use is a word processing program. An FA may need to know how to use a word processing program at a more advanced level that others on the development team. The FA might need to create templates, develop large documents, and clearly convey requirements in a written format. The FA will need to understand the use of styles in the word processing program to support consistent formatting throughout the document. The role also needs to know how to create indexes and tables of contents so that the documents they produce can be useful reference documents as well as a readable introduction to the problem.
Another tool that the FA might need to understand and use is a spreadsheet tool. They must be comfortable collecting, organizing, and combining a variety of lists including mapping requirements to the design feature points created by the architect and the development leads. They must further then help to map requirements to the testing scripts created by the quality assurance role. An understanding of how to manipulate data in a spreadsheet facilitates all of these mappings.
The last tool I’ll mention that is in the toolbox is a drawing program, such as Microsoft Visio, which allows for the definition of use cases, process flows, and other diagrams that would be nearly impossible to express in words alone. The ability to use the program to accurately depict a wide variety of complex ideas is essential to crossing the chasm between the SME’s knowledge of the problem and the ability for the software development team to solve the problem. The generally accepted practice for diagramming is becoming UML (Unified Markup Language). UML allows you to describe relationships, states, and other common requirements that are best expressed in a graphical way in a standardized way.
Where’s the role heading anyway?
There was once a time when people predicted that everyone would be able to write their own software. They would sit down at a computer and just tell it what they wanted. The computer would write the program from this dialog and thus developers in their current incarnation would no longer be a necessity. This vision is all but gone from the heads of most practitioners. As more became known about what people wanted to do with computer and the rate of growth of their demand it became clear that there would always be increasingly more complex problems to solve.
A part of that realization is the realization that our ability to accurately describe the problem determines the ability for the problem to be solved. Most people are incapable of clearly and precisely articulating – to the level necessary — the problems that they’re trying to solve. This is a problem that is getting larger and not smaller.
This is the very problem that the functional analyst role has been created to solve. The functional analyst’s goal is to refine the understanding and communication from the subject matter experts and convert that into the clear, precise vision necessary to create a solution. Because of the growing need to automate in order to be competitive and because of the increasing difficulty for clearly articulating true business needs, the functional analyst’s role is more important now than it ever has been.
Standing Out in the Crowd
One way to stand out from the crowd as a FA is to become adept at dealing with differing opinions and conflict. The ability to gather a room full of disagreeable people and getting them to agree is a skill that is difficult to master but one which will show its value relatively clearly. Disagreements about what the problem really is – is common between SMEs. Sometimes SMEs are able to work the problems out amongst themselves. When they can’t, it is a powerful FA who can jump in and work through the problem.
Another way to stand out from the crowd is to develop requirements documents that are clear, precise, concise, and meaningful. The ability to develop requirements documents that are clearly understood by the entire software development team is rare even in a role where the primary purpose is to develop requirements documents.
A FA will also stand out when they show that they are keen to listening rather than more focused on presenting solutions. It is not the job of the FA to provide the solution, but rather to document and connect the requirements. SME will recognize a functional analyst that is more interested in hearing from them on what the requirements are, rather than one that presumes to know the answers already. By listening to the SMEs and by taking note of what is being said, an FA can build relationships that can help them in the future.
The Good, the Bad, and the Ugly
As with any role there will be good with the bad and then there will be the really ugly. The functional analyst has the opportunity to set the software development process on the right path by carefully controlling how the process gets off the ground. There are the key points for the role:
- Good: Key role in the definition of the solution. Being at the start of the process the FA has the greatest opportunity of any member of the software development team, to get the project started in a way that will create the best solution.
- Good: Interaction with everyone An FA has the greatest opportunity to interact with everyone on a project. This includes people on the development team as well as people outside the development team. Often this can include higher-level people within an organization. Such exposure to can be great for building a positive reputation and a strong career.
- Bad: Not all SMEs are created equal The quality of SMEs that a FA must work with will vary greatly. Some SMEs will make the FA role easy and others will make the FA want to commit acts of violence.
- Ugly: Conflict For most FAs conflict will be a normal consequence of daily work. This can get downright ugly at times – resembling a session of the Taiwanese congress.
- Ugly: All fingers often point to the FA. If the FA does their job, then everything should work out. If something is found to be missing from the solution, then the FA is often the role that is blamed first.
Conclusion
The Functional Analyst can be described as the “bridge across troubled waters.” Their role is to bring together two very different perspectives. This process is done through conflict management, listening, and clearly communicating. The true armor that the FA has against the slings and arrows that will likely be thrown at them is the armor that they build in the development of a rock solid requirements document that accurately captures and communicates the vision of the SMEs and removes areas of potential misunderstanding by illuminating the dark crevices of detail that hide in everyone’s vision of a solution.