August 12, 2020
Hot Topics:

Anatomy of a Software Development Role: Functional Analyst

  • By Robert Bogue
  • Send Email »
  • More Articles »

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.


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.

About the Author

Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server - Networking . You can reach Robert at Robert.Bogue@CroweChizek.com

Page 2 of 2

This article was originally published on April 26, 2005

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date