ArgonDigital is an interesting place to work. One of the things I love about it is that our service delivery department has people who come from a huge range of backgrounds. Without thinking too hard, I can rattle off that we have 
people with backgrounds in finance, law, counter terrorism, German, physics, mechanical engineering, information science, and philosophy. The diversity of our backgrounds has not hindered us from performing well in a wide range of projects.
However, if we look at our most senior consultants, many of them have a background in the computer industry if not in computer science directly. This observation led us to wonder – what level of computer science does one need to understand in order to write software requirements? Some might answer “none” – write your business requirements and let IT figure it out. Others argue that business analysts should almost always come from an IT background, since they know the systems best and can help interpret business needs in the context of the systems in which those needs are implemented.
I definitely don’t think everyone needs to have a software, or even an IT background in order to be a good business analyst. However, I think there are some key concepts from computer science that most business analysts should be aware of, and I list a few of those here.
Databases
A large majority of the projects that we work on operate on data contained in relational databases. So what would I expect a consultant to know about databases? Let’s take a look:
- They should understand the idea of a flat file, and how a flat file stores data.
- They should understand the limitations of storing things in flat files.
- They should understand the concept of data living in tables and data being related to other tables through keys.
- They should understand that there are standardized ways to query data from the database.
I certainly don’t think a BA needs to be an expert on SQL, but I think it’s conceptually useful to basically understand how a query is structured.
Software Interfaces
Many of the systems that we work on interact with other systems within the enterprise environment. One of the reasons that we build Ecosystem Maps early on in projects is to identify the interfaces that may be affected by changes to various systems. I don’t think our BAs need to be experts in interface design, but they probably do need to understand some of the mechanisms by which systems communicate, whether that’s through flat file exchange or a RESTful web service.
Scaling
Many of the non-functional requirements that we write relate to usability and system performance issues. These issues, in turn, are tied quite closely to how performance of a system scales with a greater amount of data in it. I don’t expect BAs to be algorithm experts (because IT should be designing the algorithms necessary to meet the business requirements), but I think it’s certainly useful in discussions with IT to be able to understand how a system scales. If we double the number of users, what does that mean? Does that mean doubling the number of servers? Could it mean quadrupling the number of servers that we need? BAs do need to have a basic understanding of the different types of growth that systems might see.
What do you consider to be the core computer science skills for your BAs?
