In Part four of this six-part series of articles, we will continue to explore the basic skills and concepts of business analysis (BA). In this section, we will review and analyze the business analysis process. As we stated in Part one, there are a variety of techniques and tools suggested by PMI that should be in your business analysis toolkit.
According to the Business Dictionary, a needs analysis is defined as a formal process that is designed to look at how a product addresses the needs of its intended market. “A needs analysis is a valuable analytical technique that is designed to gauge the marketability of a product or service for human consumption,” however, it is worth noting that it is not considered an official business development tool. Although this tool was initially intended for use in the software development industry in combination with requirements analyses, it can be used across many other consumer-based industries. In short, if these two systems were applied to Apple Inc.:
- Requirements analysis
- All the internal guts of the computers would be covered in a requirements analysis. This would include areas that are traditionally hidden from the end-user. They include complicated bits of hardware and firmware
- Needs analysis
- Software operating system interfaces would fall under the needs requirement blanket. The end-user perception of the product/service would be shaped by the interfaces that are created with the end-user satisfaction paramount. They include the keyboard and mouse.
Requirements management activities are the cornerstone of the analysis domain. Tasks that make up the analysis domain are:
- Elicitation – In order to capture requirements with supporting details, individual and group techniques should be employed.
- Analysis – In order to collaboratively clarify and uncover product options and capabilities techniques such as dependency analysis, interface analysis, and data processing modeling should be used to analyze requirements.
- Decomposition – In order to determine which requirements are accepted, deferred, or rejected, product options and capabilities should be examined with decision-making and valuation techniques.
- Acceptance – The business analyst will balance scope schedule, budget, and resource constraints by implementing prioritization, dependency analysis, and decision-making tools and techniques so that a proper baseline can be created.
- Approval – To facilitate stakeholder consensus and to achieve stakeholder approval, the requirements baseline must be signed-off.
- Specification – Requirement specifications should be written to process data to communicate, so they are viewed as measurable and actionable.
- Validation – Specific detailed metrics and acceptance criteria should be used in evaluating whether the solution meets requirements.
6 Principles of analysis
- When in doubt, the end-user opinion will prevail. The process is written and executed with the goal of customer satisfaction, not the self-satisfaction of the design team.
- The best direction for product or service designs can be further defined by market research. Properly executed qualitative and quantitative research will unify end-user opinions.
- Apply the KISS principle – “keep it simple, stupid.” The largest potential market is addressed by appealing to the lowest common denominator.
- Beta testing should not be rushed and should be very comprehensive. This will allow you to do proper fault finding and readjustment.
- After product launch, defects should be addressed as quickly as possible. It is also important to keep an accurate record to apply to future releases.
- Successful needs analysis can be accomplished with an elegant design. It will also distinguish your product from others in the larger market.
Similar Content:
-
Part 3 – Basic business analysts skills and concepts: Planning
-
How to conduct a gap analysis for business process improvement
-
Utilizing Plan, Do, Check, Act (PDCA) for business process improvement
