.4 Strategy Analysis
Within an IT organization, strategy analysis focuses on the technologies and systems, business units, business processes, and business strategies impacted by a proposed change. It is possible that the impacts of a change cause a ripple effect through other systems in the organization. In order to analyze needs and proposed changes, business analysts seek to understand all the various aspects that may be impacted by the change.
Current state analysis within IT initiatives includes analysis of manual processes, understanding what the system or technology currently does, the data needed to complete tasks, and the other systems and processes that interact with the system. Business analysts plan for a thorough understanding of the current state and a large context of the enterprise at first, with the understanding that the scope will narrow as the future state is identified.
Once the current state is understood, the desired future state is described. This may be process or capability related and usually includes how current system functionality is required to change in order to support the future vision and meet the objectives of both individual stakeholders and the enterprise. In understanding both the current and future states, the gap between the two is identified, and that is where the direction of the change effort can be set. It is at this point of analysis that solution options are explored.
Once the aspects of the change scope and desired future state are understood, business analysts assess uncertainty and risk. Uncertainty is clarified by:
- identifying and defining risks,
- identifying and defining potential benefits,
- establishing parameters for variance in known processes and operations, and
- exploring the unknown.
Business analysts also explore other potential risks including:
- vendor risks, such as their business and product stability,
- impacts to the system’s technical environment,
- scalability of the solution should volumes of transactions or users increase over time, and
- additional process or system changes required based on the change initiated.
BABOK® Guide Techniques
- Business Capability Analysis (p. 230)
- Focus Groups (p. 279)
- Functional Decomposition (p. 283)
- Interviews (p. 290)
- Item Tracking (p. 294)
- Observation (p. 305)
- Process Analysis (p. 314)
- Process Modelling (p. 318)
- Scope Modelling (p. 338)
- Survey or Questionnaire (p. 350)
- SWOT Analysis (p. 353)
- Vendor Assessment (p. 361)
- Workshops (p. 363)
.5 Requirements Analysis and Design Definition
It is important for business analysts working in IT to understand and clarify the term “design”. Many IT organizations think of design only as it applies to the design or blueprint of a software or technical change. Within the Requirements Analysis and Design Definition knowledge area, the term design is viewed more broadly and from the business analyst’s point of view. Designs are usable representations that focus on the solution and understanding how value might be realized by a solution if it is built. For example, a model of a potential process improvement (whether it impacts or utilizes an IT system or not), as well as user interface layouts or report definitions, can all be considered designs.
Business analysts elaborate business and technical requirements, break down and define stakeholder needs, and identify the value to be realized by stakeholders once a technical solution or change is implemented. They elicit, define, and analyze business and stakeholder requirements, and also define, analyze, and model solution designs. They define requirements to a level of technical detail that will be used as part of solution design and input into technical designs. This elaboration will include both functional requirements and non-functional requirements. For some change initiatives, the definition of non-functional requirements could define all business goals for the change effort.
Business analysts often rely on other change agents to produce technical designs for software solutions. A systems architect, programmer, database manager, or other technical expert is often needed to determine how to use technology to satisfy a set of requirements. IT business analysts define process steps, business rules, screen flows, and report layouts. Defining requirements to include detailed functionality of a system, the business, and system processes is a crucial part of solution design and does not separate analysis and design.
As part of requirements analysis, an IT business analyst may partner with another business analyst with a different focus, such as an enterprise business analyst or business architect, to ensure that the IT requirements align to business or organizational strategy.
Requirements analysis and design definition frequently involves documenting requirements using words and pictures. In some cases, requirements may be represented in other ways such as a proof of concept, working software prototypes, or simulations. In all cases, the business analyst works to produce documentation with sufficient and appropriate details for:
- the business to verify and validate the requirements,
- the developers to design from, and
- the testers to measure the solution against before it is implemented into a production environment.
BABOK® Guide Techniques
- Business Rules Analysis (p. 240)
- Data Dictionary (p. 247)
- Data Flow Diagrams (p. 250)
- Data Modelling (p. 256)
- Decision Analysis (p. 261)
- Decision Modelling (p. 265)
- Document Analysis (p. 269)
- Estimation (p. 271)
- Functional Decomposition (p. 283)
- Glossary (p. 286)
- Interface Analysis (p. 287)
- Non-Functional Requirements Analysis (p. 302)
- Organizational Modelling (p. 308)
- Process Modelling (p. 318)
- Prototyping (p. 323)
- Reviews (p. 326)
- Roles and Permissions Matrix (p. 333)
- Scope Modelling (p. 338)
- Sequence Diagrams (p. 341)
- State Modelling (p. 348)
- Use Cases and Scenarios (p. 356)
- User Stories (p. 359)
.6 Solution Evaluation
Solution evaluation focuses on solution components and the value they provide. Within an IT context, this includes a focus on the interactions between multiple systems within the change and the surrounding environment. It is important for a business analyst working in the IT discipline to understand the context of the solution and how changes within one system or process can impact other systems within the environment. These impacts can add negative or positive value to the other systems, therefore impacting the overall realization of value for the change.
One aspect of solution evaluation within an IT context is software testing or solution testing. Testing or quality assurance ensures that the solution performs as anticipated or designed, and that it meets the needs of the business or stakeholders who requested the change effort. The business analyst works with quality assurance (testers) to ensure that technical solutions will meet the business needs as defined by the requirements and other business analysis deliverables. Testers utilize testing methodologies to plan, develop, and execute tests. This aspect of solution testing generally focuses on complete process testing, including across systems to ensure end-to-end solution quality and accuracy. Business analysts work with stakeholders to plan, develop, and execute user acceptance tests to ensure that the solution meets their needs.
Business analysts make themselves aware of the rationale for implementing an IT solution and how that rationale works to create solution value. This value realization is commonly associated with better support for business processes and procedures.
Business and technical objectives are associated with benefits and value realization which are measured against defined metrics used to evaluate success.
Requirements should trace back to the objectives, and this traceability provides a foundation for solution evaluation. The analysis of solution performance focuses on technical systems and how they provide potential and actual value to stakeholders.
Where a large organizational change contains an IT element, an IT solution evaluation can contribute to a broader benefits realization activity associated with the whole change program.
As part of solution evaluation activities, a business analyst may work with a team to complete tasks, such as assessing solution limitations and assessing the impacts of such limitations. The business analyst may support and assess technical testing efforts for all, or a portion of, the developed solution.
BABOK® Guide Techniques
- Acceptance and Evaluation Criteria (p. 217)
- Decision Analysis (p. 261)
- Estimation (p. 271)
- Item Tracking (p. 294)
- Metrics and Key Performance Indicators (KPIs) (p. 297)
- Organizational Modelling (p. 308)
