To understand the relationship between a Business Analyst, the business, and the Software Development Life Cycle, just picture this. You enter a nice restaurant, excited to try the latest items on the menu. A well-dressed waiter approaches you and invites you to your seat. He is friendly and you partake in some witty chat as he serves you drinks and appetizers. He knows what he is doing and knows his way around the menu. A few minutes later he comes back to take your order, but it turns out you have questions. It is then that you discover that the waiter knows absolutely nothing about what happens next the minute after he takes your order:
How long is the wait for dinner tonight? No idea.
Does he know whether the shrimp is hot or cold? Nope!
Does the chef make the the steak medium or rare? Who knows.
Does the dessert have alcohol in it? Your guess is as good as his.
It’s just his job to take your order and bring you food, right? Wrong.
Even though OF COURSE the waiter does not work in the kitchen, and doesn’t need to know anything about cooking, his failure to know basic facts about what happens in the kitchen, behind the scenes, makes him an ineffective waiter. You probably leave him a lousy tip and never come back.
I think you see where I’m going with this analogy: in the world of IT, the restaurant customer is the business and the cook and kitchen staff are the software development team. You, the Business Analyst, are the waiter and serve as the connection between the “kitchen” and the customer. You don’t have to know how to “cook up” the code, but you better know a lot about how the development shop creates code so that you can help your customer arrive at the best business solution.
The Software Development Life Cycle (SDLC) is a great place to start. While Business Analysis may be technology neutral by focusing on business needs, the results of Business Analysis will almost inevitably end up with the implementation of software, so BA’s have to know something about how software gets built.
So here is your beginner’s guide to the SDLC. Let’s start with a graphic that shows the cycle:
PRE-SDLC: PLANNING THE PROJECT
Before you even start the process of developing a software solution to meet a business need, there’s a whole lot of work that goes into planning for the entire software development project. The following questions need answers, among others:
- What is the business case for spending the money to implement the software solution?
- What is the Enterprise Architecture approach for implementing the software solution? (That is, what is the overall organizational guidance for implementation.)
- What priority does this project have in comparison with competing ones?
- Who will pay for the project?
- What teams will execute he project?
Once answers to these questions exist, the project is ready to begin implementing the software solution.
How Business Analysts add value: BA’s may write business cases. They may also work with business stakeholders to help prioritize a project. Depending on their background, BA’s may also help with providing high level estimates of project cost.
SDLC PHASE 1: REQUIREMENTS ANALYSIS
The requirements analysis process kicks off the SDLC. BA’s must work with business owners and users to determine the requirements that the solution must address. Business Analysts will elicit, manage, prioritize, and update requirements using a variety of techniques. They may also create use cases or user stories that describe specific scenarios that the software solution must address.
This phase is (or should be) technology agnostic. It should be about the business stating what they need without concerning itself with the specific tools and technologies to use in deploying the solution.
Output: a set of requirements in some form (spreadsheet, Requirements Specification Document, or some other artifact).
How Business Analysts add value: BA’s own this phase of the SDLC, which is why it becomes easy to see why Business Analysts are so indispensable to software engineering!
SDLC PHASE 2: SOFTWARE DESIGN
Once the requirements are complete, there needs to be a design in order to properly code the software. Systems analysts or solution architects are the people who primarily own this phase, although experienced Business Analysts with technical knowledge can work in this space too.
A systems analyst will meet with the Business Analyst and other stakeholders to make the technical decisions necessary to implement the software, documenting those decisions as a set of technical requirements. This is the time when software tools, coding languages, data sources, and other technical details get ironed out. A solution architect will describe the internal technical details of how the solution will operate within itself and in relation to interfacing systems (which is known as software architecture).
Output: a software high level design and architecture to guide the development process.
How Business Analysts add value: BA’s may need to facilitate design sessions that bring together business experts and technical staff to iron out details. The BA may also capture overlooked business requirements that become apparent during the design process.
SDLC PHASE 3: SOFTWARE DEVELOPMENT
This is the point in which developers get to work. They may create more technical specification documents to address the finer points of how they will be implementing their code, but the majority of the work consists of actual code development to build the solution.
Output: a set of untested software code.
How Business Analysts add value: software developers will often work with BA’s to ensure they fully understand the business requirements they are coding. Software developers do not have the big picture view that BA’s have, so they rely on BA’s to provide context for what they are building.
SDLC PHASE 4: TESTING
Once the code is complete, it must go through several levels of testing. There is internal testing to ensure that code works as desired. There is also system testing to see how the code works in the greater context of interfacing systems. Additionally, there is also regression testing to ensure that existing code doesn’t get broken by the new code. If testing fails, developers will code fixes and testing begins again.
At the end of this process is User Acceptance testing, where the business provides final criteria for measuring whether the solution succeeded in fully meeting the business need. If it does not, then development and testing continues until the criteria are met.
Output: tested software that is ready for final implementation.
How Business Analysts add value: BA’s will provide the User Acceptance criteria and work with developers and testers to ensure that all of the criteria are met. The criteria help to ensure that the coded solution traces back successfully to all of the original requirements.
SDLC PHASE 5: IMPLEMENTATION (AND ITERATION)
Once the code is ready it must be deployed to whatever hardware and network platforms are going to hold it and make it available. That could be data center machines, individual PC’s, an app store, or the cloud.
The code is unlikely to be perfect, but it works as intended (if tested properly). The business may want to create additional enhancements to address unintended flaws identified during the process. Software development is therefore iterative, and the process begins anew with a new set of requirements.
Output: working software that meets the business need, but that may need additional enhancements or improvements in the future.
How Business Analysts add value: BA’s play a key role in capturing the enhancements and fixes necessary for future versions of the software solution, and begin iteration of the SDLC again.
Whew, that’s a lot to know! As you can see, BA’s add value at every step of the way so you should be prepared to address the basics of the SDLC at your next Business Analyst interview.
So again, what do the restaurant waiter and the Business Analyst have in common? You both represent the “business” to the software development “kitchen.” While you don’t work in the “kitchen” you should know how it works so you can help the customer make the best choices off the “menu” of business options!