Is there business analysis without software development?
This is more of an inquiry, and I don't fully know the answer. But I wonder what business analysis is without software development. This post looks at the elements of business analysis and provides and evaluation of whether this applies strictly, or primarily, to software development.
Business analysis is all about requirements in some way. And those requirements need to apply to something. Is it just software? Or is there something more, something else?
Here are the basics of what business analysis, as a discipline, covers:
- BA Essential Competencies - Competencies involve such things as gathering requirements, using special techniques to analyze problems and identify potential solutions, demonstrate a significant level of business-related competency, and understand software.
- BA Planning - This type of planning involves the ability to see the big picture and choose the tools and techniques that might match the task. This includes techniques for decision analysis, process modeling, and technique such as RACI analysis and stakeholder maps.
- Planning BA Communication and Monitoring - This is not so much about doing the BA work, but more about the process of executing BA tasks, and how to perform them optimally. This includes managing the requirements gathering process, doing structured walkthroughs, utilizing metrics and key performance indicators, and other strategies for managing the BA process. The core focus here is on communication around the BA tasks.
- Requirements Elicitation - This is the core function of business analysis. It is the key product at the center of the BA process. It involves gaining an understanding of stakeholder needs, but also balancing that with what is possible. Understanding the whole process, from start to finish, is really necessary to being able to properly plan and execute the requirements elicitation function. Techniques can include brainstorming, conducting stakeholder working sessions, analyzing documents, analyzing interfacing within potential systems, prototyping, and developing and sharing of scenarios.
- Requirements Management and Communication - It's one things to gather the requirements. It's another to manage them throughout a project, where change is likely to occur for a number of reasons. Key techniques include scoping the solution domain and baselining the actual solution. This includes building trace-ability into the requirements at the appropriate level of detail, building test scenarios, and communicating at the various levels of detail required by different stakeholders.
- Enterprise Analysis - This is all about keeping the big picture context in mind. Somewhere at the enterprise level, thge business need must be identified, and a plausible solution identified and defined, and the investment in the solution justified. So it's all about defining the business case for the project by attaching it to analysis of the business and the particular opportunity. Techniques include root cause analysis, assessing capability gaps, SWOT analysis, determining potential solutions, conducting feasibility analyses,
- Requirements Analysis - There is a bit of project management here; requirements analysis involves identifying dependencies among tasks, and properly ordering them in a way that makes sense and gets the end results. Techniques include MoSCoW analysis, data flow diagrams, non-functional requirement analysis, modeling requirements, and state diagrams.
- Requirements Verification and Validation - This involves making certain that you and the stakeholders understand just what needs to be done, and that you have the resources in place to execute and deliver the solution. Techniques include defining assumptions and constraints, techniques for verifying and validating requirements, development of checklists and prototypes, and walking in detail through scenarios.
- Solution Assessment and Validation - This includes studying the viability of the solution within the organization, identifying what will be required in order to make the solution work, and validating and evaluating solution performance. Techniques include the defining of transition requirements, assessing organizational readiness, and planning for stages to get from the current situation to the desired end state.
The above areas largely cover the realm of business analysis, albeit at a high level. It seems to me that these things are all about the development of systems - new systems involving software. any hardware aspect is simply infrastructure and supportive of the software solution. Hence, I conclude that business analysis is primarily a discipline that almost exclusively supports the development of solutions within an enterprise to produce system solutions involving software.
Related training - Business analysis training for certification and PDUs