This session is a deep dive into requirements documentation issues showing examples of good documentation practices and samples of materials that only look good on the surface, but have significant buried problems. Find out the 3 most common documentation mistakes, and learn about 5 critical success factors for effective requirements documentation.

In this Webcast, Amit Parikh, manager of systems consulting for Quest Software will show you some best practices to simplify the process of defining reporting requirements, finding the data you need, and designing and distributing reports. Featuring examples from organizations who have implemented Toad for Data Analysts’ technology, Parikh will demonstrate how to utilize a simple workflow to perform the following tasks...

Why should it take months to determine project scope and gather requirements? Register now to look at the underlying problems that impede the collection of business requirements and make projects less successful.

Managing Requirements Operational Excellence is about making significant change in requirements discovery and management performance.
This session is for the business analyst leadership and development executive looking to make long term, systematic improvement to their business analyst organization.

A thorough discovery of business requirements is almost never readily available at an analyst’s fingertips—rarely can requirements be quickly looked up as one would gather information for a term paper or study for a test. Much of business or technical requirements is not documented anywhere—it resides in the minds of stakeholders, in feedback that has yet to be obtained from end users, and from a study of flowcharts and surveys that have yet to be created. And so requirements must be elicited, or drawn out, and the methodology in doing so must be logical and meticulous. The importance of elicitation cannot be overstated, for it is the linchpin to any requirements project.

You remember the game of telephone, right? The test of communication skills where one person whispers a message to his neighbor, and that message is translated multiple times from person to person until eventually, the last contestant repeats her interpreted message aloud. The goal is for the final person in the chain to correctly hear the original message, but invariably, there is laughter all around as the message is misconstrued.

When this happens in business however, it’s no laughing matter... There is a tendency to interpret information in very individualized ways, but as business analysts (BAs), we don’t want to allow for that. Rather, BAs strive for clear, concise and coherent articulation of requirements because it influences the outcome of solutions.

The voluminous amounts of information that an analyst collects during the discovery and elicitation phases warrant a good deal of planning and organization in order to make business or user requirements into a usable, cohesive whole. As with any other organization process, the key element to requirements’ organization success is thorough preparation and planning.

According to BABOK 2.0, an analyst has two main objectives when organizing requirements: (1) to understand which models are appropriate to include based on the business need, and (2) to understand and clearly communicate the interdependencies and relationships between the various requirements.

Excellent requirements prioritization is essential to any well-run project. It ensures that the project focuses on the most important elements first, and that everyone understands and agrees regarding what the project’s most important elements are. Good prioritization of requirements will also ensure that engineers, programmers and database analysts develop a project’s most critical elements in sync with the business needs.

The purpose of business requirements is to define a project’s business need, as well as the criteria of its success. Business requirements describe why a project is needed, whom it will benefit, when and where it will take place, and what standards will be used to evaluate it. Business requirement generally do not define how a project is to be implemented; the requirements of the business need do not encompass a project’s implementation details.

There is no one standard definition of an Availability Non-Functional Requirement. It will be defined for each project where it needs to be specified. This principle is true of all non-functional requirements.

For the purposes of this article an Availability Requirement is any requirement that is not a functional, data or process requirement concerned with defining the periods when the solution can be used.