What does a Business Analyst need to know about Computer Science?

Seilevel 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 RedQuestionDicepeople 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?

 

6 Responses to What does a Business Analyst need to know about Computer Science?

  1. Jonathan Nituch March 12, 2013 at 11:21 am #

    I think this article hits the nail on the head. Especially for business analysts who come from a business background, some technology skills are necessary. The article picked the top three in my view.

  2. Stacey Bowling April 30, 2013 at 9:16 am #

    I would also add to this list a conceptual understanding of object oriented development. A BA should be aware of how the software models key business objects and their changing states.

  3. Keith German April 30, 2013 at 2:10 pm #

    The article does a nice job of balancing the reality that a balanced approach can be effective. If all BA’s were just IT strong, then the key attributes of business accumen, listening skills, and communication skills may be overlooked; and that would lead to failed projects. They key for me in any project is using a team approach to produce balance and objectivity. This assures any client that your listening without bias.

  4. Mark Lucas May 1, 2013 at 9:42 am #

    For most business system projects, the key skills I look for in BAs are:
    –Is the BA effective in talking to stakeholders and understanding their unstated and stated business objectives? Do stakeholders like them?
    –Is the Lead-BA an effective “product manager”, taking ownership and accountability for ensuring that stakeholder needs and expectations are met by the features delivered in a system?
    –Can the BA track down existing business policy and process documentation, so time is not wasted re-documenting existing knowledge?
    –Can the BA model current and future state processes and data?
    –Can the BA create use-cases or user-stories from the processes and data models? Can the BA transform use-cases/user-stories into test scripts?
    –Does the BA understand that user-specified models do not have to be perfect according to a particular methodology? …and likewise that user-specified models must be transformed (in a backroom process) to methodology correct models before using them for design artifacts?
    –Has the BA obtained all the business rules, and associated valid cases, and exception cases related to the rules?
    –Can the BA help stakeholders determine the *true* priority and rank of a requirement, relative to the overall program or project timeline?

  5. Mark Lucas May 1, 2013 at 9:44 am #

    IMHO, BAs do *not* need a CS background or degree, but ideally have some experience as a tester, help-desk analyst, or Business system developer (and/or have a MIS or CIS degree). Comp.Sci. people generally tend to be “too close to the

    machine”.
    I find that the most effective BA *teams* include a mix of (a) BAs with a broad exposure to multiple Business Processes and multiple Industries/domains (since they can see common patterns and are more likely to conceptualize business

    solutions “out of the box”), and (b) BAs with deep knowledge in a specific business process and/or industry, esp. if they used to be an actual “business person/stakeholder”.
    Key elicitation skills that I expect from BAs on my team include: –research of business documentation, –facilitation of requirements sessions (aka. JAD, JRA), –facilitation of prioritization and ranking sessions, –facilitation of

    focus-groups, –survey design and execution.
    BAs with *people-skills* are critical to the elicitation process. BAs who are friendly, upbeat, and can get along with multiple personalities (esp. challenging stakeholders threatened by change) and can manage stress are the ones you

    want scheduling and facilitating elicitation sessions.
    For post-elicitation analysis, I need BAs with experience in two or more of these ‘technical’ skills: –process modeling (swimlane, PERT, DFD, et al.), –navigation, user-interaction modeling, –conceptual data modeling, –wireframe UI

    design and Information Analysis, –metadata taxonomy, –cost-benefit analysis, –Use-case -or- User-story writing, –Test script and test case writing, –fishbone modeling, –cause-effect analysis.
    IMHO, with rare exceptions, (such as in highly mature organizations and those developing highly technical systems like command-and-control, investment management, gaming, infrastucture), “requirements engineering” and “semantic

    modeling/analysis” tends to be over-kill.

Leave a Reply

Your email address will not be published. Required fields are marked *