|
 |
Home > Topics > Test & Evaluation > Detail: The Right Business Analysis Tool
| |  |
The Right Business Analysis Tool
By Matthew Leach
  
Summary: The continued rise of the business analysis profession has led to a surge in software tools specifically designed for the business analyst. Find out what types of tools are in the marketplace today and how to select the right business analysis software tool for your organization. | | |
|
 |
Experts have stated that of the projects that fail, 71 percent can be traced back to requirements issues. It is clear that we need to identify means to improve the efficiency and effectiveness of our requirements solutions and thus improve this deplorable percentage. To reach a higher state of requirements excellence, business analysts must focus on three improvement areas: communication and collaboration; structure, rigor, and completeness; and traceability and relationships.
Communication and collaboration: An effective business analysis approach requires clear and consistent communication among business analysts, users, and stakeholders. This sharing of information enables meaningful collaboration and improves the quality and accuracy of requirements.
Structure, rigor, and completeness: Requirements definition is not as simple as pulling statements out of thin air or blindly repeating the wishes of users. Developing meaningful requirements necessitates a sophisticated level of analysis, which requires the use of models, diagrams, and other business analysis products to gain an in-depth understanding of the users' and stakeholders’ needs.
Traceability and relationships: Few requirements or business analysis artifacts offer sufficient detail alone. It is the combination of these artifacts and their relationships to one another that provide the complete view of a system that is required for the latter stages of the software development lifecycle (SDLC).
To support these three improvement areas, organizations should introduce software tools that support the requirements lifecycle and cater to the specialized needs of the business analyst. The implementation of a specialized business analysis tool can greatly benefit each of these core areas and, in turn, decrease the overall time needed for requirements development, increase requirements quality, and minimize rework.
The most popular requirements definition tool today, Microsoft Word, was never intended to be one. For years, business analysts have depended on standard office productivity software--Microsoft Word, Excel, and PowerPoint--as tools of their trade. Overextending and forcing these tools to perform tasks for which they were never designed limit our productivity, increase costs and schedule, and do more harm than good.
There is a better way, but navigating the myriad business analysis tools to find the right solution can be difficult. Only by understanding the types of tools that exist, identifying your organization's constraints and needs, and knowing what traits to look for can you make an informed choice for your organization and its software development projects.
Business Analysis Tools 101
The majority of software products for the business analyst can be broken down into two distinct categories based on functionality and the products' places within the requirements lifecycle.
Requirements definition tools: Software products designed to aid the business analyst in the elicitation and documentation of requirements are considered requirements definition tools. This category includes computer-aided software engineering tools, visualization products, and business process modeling software. These tools are deployed during the planning and requirements phase of a project. Requirements definition tools improve the quality of the requirements and are designed to aid business analysts in communicating with stakeholders. They provide a means to link IT and the business through standard languages, such as UML, or through the development of visualizations. These tools are adept at documenting several views of the candidate system, and some support the standard architecture frameworks, such as Zackman, DODAF, and
TOGAF.
Requirements management tools: Once requirements have been defined, requirements management tools pick up where definition tools left off. They store requirements in a single location, allow you to view relationships between requirements, and track changes. Requirements management tools are effective when used within organizations with a mature requirements process and skilled business analysts. Unlike requirements definition tools, requirements management tools do not improve the quality of the requirements during elicitation but maintain the requirements during subsequent phases of the SDLC, resulting in fewer overlooked requirements and a tighter integration with other project artifacts.
There are tools that do not fall into either the requirements definition or requirements management categories. Hybrid tools represent business analysis tools that contain functionality that supports both practices. Functionality may not be as mature in hybrid tools, but they provide cost savings and allow users to perform their work in a single tool.
Each type of tool has a different purpose and features suited to it. When selecting a tool, decide where your organization needs to improve and select the tool suited to that area of improvement.
Selecting Your Business Analysis Tool
A robust, repository-based tool solution that supports modeling, collaboration among stakeholders, requirements traceability, and integration with testing and application development is ideal, particularly with respect to moderate- to high-risk projects. However, organizations and projects vary in maturity and complexity. The selection of a tool solution must reflect these variations. To evaluate a tool, consider the traits of both the tool and your organization:
Organizational maturity: Be honest and evaluate the maturity of the business analysis practice within your organization. Conduct an assessment of your organization utilizing a business analysis maturity model, which will offer insight into the level of complexity that your organization can support. Implementing an overly complex solution will slow tool adoption. Instead, select a tool that not only provides the functionality that your organization needs but one that also will grow with you over time as business analysis maturity increases. For organizations at a starting maturity level, selecting a requirements definition tool will be far more effective than a requirements management tool.
Scalability: Your organization will take on projects of different sizes, and not every project needs a full business analysis tool solution. Tools range in complexity from solutions for large advanced projects to back-of-the-napkin documentation tools. An ideal solution should scale to meet your project's needs.
Lifecycle integration: The majority of the work performed by the business analyst is undertaken during the early phases of a project, but that work influences all other phases of the SDLC. A business analysis tool--particularly requirements management tools—must be capable of supporting activities within the entire SDLC by providing the ability to trace work done during development, testing, and implementation back to requirements. If a tool cannot provide support across the SDLC, its usefulness is diminished.
Simplicity and the user experience: Business analysts use Word, Excel, and PowerPoint for one reason: They offer a positive user experience. Any new business analysis tool should provide the same. The user interface must be easy to navigate and relatively intuitive. Commonly used functionality should be easily accessible. Look to minimize the number of mouse clicks that a user will need when performing common tasks.
Information accessibility and reporting: Ease of compatibility and widespread use is a reason the Microsoft Office suite has continued to be used for business analysis work. Consider tools that allow users to access and share information easily either through a shared repository or through reporting capabilities that generate documents in commonly accessible formats such as RTF or HTML.
Cost: The cost of tools varies greatly. Some are available as free downloads; others can cost up to $10,000 a license. Evaluate the cost and benefit of each tool, focusing on the features your organization needs and the relative cost of each feature. Beware of hidden costs of tool implementations. Additional features, software add-ons, hardware upgrades, and training and support can add to the upfront cost of purchasing software.
Selecting a business analysis tool is no easy undertaking. The successful implementation of a business analysis tool necessitates an in-depth understanding of the people, processes, and technology involved. However, by understanding the type of tool you require, your organization, and what to look for, it is possible to make an informed decision that will benefit your organization by improving your business analysis capability. {end}
The evaluation criteria for business analysis tools should change based on the needs of an organization. What criteria are you using for your organization? What steps are you taking in your organization to implement business analysis software tools?
Join the conversation below or start a new one in the Member Comments section.
About the Author
Matthew Leach is a consultant with Doreen Evans Associates, Inc., a professional services firm that has pioneered the use of software tools for business analysis and helps organizations improve their business analysis practices.
He can be reached at mleach@doreenevans.com and www.doreenevans.com.
Back to Top
 |
|
|
|
|
|
|
|
|
Testing Training Courses
Software Testing Certification, Systematic Software Testing, Test Management, Mastering Test Design, Just-in-time Testing
Software Engineering Training
Mastering the Requirements Process, Requirements Modeling, Introduction to the Capability Maturity Model Integration, Business-Driven Software Measurement
Agile Software Development Training
Scrum Master Implementation Workshop, User Stories and Estimation in Agile Development, Design Patterns Explained, Practical Test-Driven Development
|
|
|
|
|
|
|
|
