The notion that BAs are supposed to wear multiple hats (especially on Agile teams) can seem quite daunting, but it doesn’t have to be. This post is a follow-up to How Technical Should Business Analysts Be? If you agree like I do, that BAs would benefit from a fundamental understanding of technology, the next question would then be, “What exactly do BAs need to know?”. Here are my top answers:
There’s a general understanding that business analysts are not required to be programmers. Neither are they meant to be concerned about how requirements will eventually be translated to the desired system functionalities. These tasks are for system architects and developers. What BAs would benefit from, however, is an understanding of the complexities of software development.
An understanding of the complexities of programming (even if it’s at a high level) would guide the recommendations made to the business. Let's take a look at this example:
Company X has identified numerous problems centered on collecting and reporting on customer data. A BA was brought in to identify the business need and present recommendations after evaluating all the possible alternatives (via a business case). Here are the alternatives: 1) Building the software in-house 2) Outsourcing the development to an external firm 3) Buying the software off-the shelf.
In assessing option 1, the analyst would at the minimum, need to understand the development platform, the skill sets of the available developers, the effort (development and testing) that would go into delivering the application within the available time, and whether the unique requirements of the project can be met using the development platform or not.
The BA’s understanding of the complexities of software development is a prerequisite for producing feasible and correct requirements for developers. This understanding would reduce the chances of rework and drastic change requests as the project progresses.
BAs should also at the very minimum, be familiar with programming standards in the organization, screen design standards and basic technological terms that would facilitate discussions with the technical team.
Business Analysts would also benefit from an understanding of the different software development methodologies, which represent a body of practices on how software should be developed. Some popular methodologies include Waterfall, Agile, Incremental Development and so on. Different levels of analysis effort are required with different methodologies. The role of the BA would be different or evolve, depending on the methodology that is employed on the project. It is, however, important to understand that methodologies were not designed to be followed without question. They should instead, be adapted to suit the requirements of the organization or peculiarities of the project.
Some people believe that testing should be strictly restricted to testers. Ann Smith argues that it is all too easy for software specifications to be insufficiently detailed, and for assumptions to be undocumented - issues only an independent or unbiased tester can flush out. While I agree that there might be some conflict of interest, the main focus of the BA, when involved in the testing process, should never be to prove that the specifications are right, but to validate the solution by proving it meets the business needs.
On Agile team settings or in small companies, Business Analysts are often involved in the testing effort.
Testing expert, Dorothy Graham emphasizes that “we can save a great deal of time and money if testers are involved in testing requirements. If the requirements have some consistent quality criteria, testers can raise questions and find problems before we turn them into code.” I believe there are some benefits to be had when business analysts are involved in the testing process. The bigger question then becomes: to what extent should they be involved?
The role of a BA in testing may range from helping to develop test cases to reporting defects in the solution and ensuring that such defects are corrected. Whether there’s a dedicated quality assurance team or not, BAs are often invited to test the final solution, which could be a combination of software and procedures.
The BA’s understanding of what testing entails will ensure that requirements are designed to be “testable” from the onset, and that he/she participates actively in test sessions. Adopting a “testing approach” to the development of requirements right from the beginning will ensure that BAs produce better requirements.
BAs should understand how data is stored or accessed and should know what databases look like. An understanding of logical/physical data modelling, data security issues, as well as access methods can help to increase their value on software projects.
At the very least, BAs should know the distinction between tables, rows and columns and be able to hold discussions with programmers on database access methods.
Business Analysts should show an interest in not just the areas discussed above but also the technical architecture (interfaces and protocols), software usability, operating systems and general technological advancements. This will ensure that they are in a position to add value to business teams and software development projects, regardless of the domain.