The success of process improvement projects is greatly influenced by good planning for gathering requirements or user stories. Part of the planning is identifying which of the analysis techniques will be effective for the elicitation of business needs with stakeholders. One objective for these techniques is to enhance project team collaboration by establishing a common understanding of the business process, thus providing a knowledge basis for developing changes. This article explores using job task instructions as an analysis technique for supporting project team collaboration by providing a platform to keep team members informed with the decisions on workplace changes.
So how do we incorporate design thinking in Business Analysis in a value-add way? Take the following thoughts into consideration when working on your next project that involves building or significantly updating a customer-centric application.
Author: Michael Roy, Business Analysis Professional / Requirements Leader
Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.
The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.
Gathering and documenting requirements to develop software is often seen by business analysts as their core task. Actually, they are there to deliver value to the business—everything else is secondary.
I never really understood the hubbub associated with system design. People tend to look upon it as a complicated process. Actually it's not, yet the corporate landscape is littered with disastrous system projects costing millions of dollars, all because developers overlooked some rather simple principles for design and focused on technology instead.
This article reviews the complexity of the role of the business analyst (BA) facilitator in obtaining a stakeholder agreement (i.e., a consensus or a compromise) on solution features and/or user requirements. The BA facilitator achieves this agreement by maintaining a neutral posture in guiding the stakeholders though a dialogue in a series of meetings.
Most of the projects inevitably struggle at some point or the other if the scope is not defined properly. The right note to start a project is to have a clear Project and Solution/Product scope at hand. It is very critical for a Business Analyst to clearly understand and define the Solution Scope in black and white before even going into the Requirement Elicitation phase. This article focuses primarily on key aspects of understanding and defining Solution Scope in traditional methodologies.
Checkpoint Beta is not mandatory. It is, however, extremely helpful for the business analyst. Checkpoint Beta is also an informal meeting, this time with the solution team. It is held prior to committing the solution to the final, formal solution document andobtaining final confirmation from the business community.
Business requirements are usually captured in narratives and graphics that, regardless of how detailed, structured, cross-referenced and validated, are fundamentally imprecise. A data-driven approach to specifications has the potential to help avoid these problems and subsequently decrease the risk and increase the return on companies' IT investments.
We present a requirements framework and methodology that may be different from what you are doing. Its three prominent characteristics are a framework, a new model, and visualization. The framework ensures completeness of all requirements. The new model is the Decision Model, transforming important business thinking into a tangible and manageable business requirement. The visualization simulates user scenarios, alleviating the need for abstract specifications or models.
Until business analysts really begin to understand the difference between rules of the business (business rules), and choices about system design, we’ll keep falling to the same requirements and legacy traps as always. In my previous column I looked closely at the meaning of business rule. Now let’s probe the two fundamental categories of business rules: behavioral and definitional.
brought to you by enabling practitioners & organizations to achieve their goals using: