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.

[Read the rest of this article...]

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.

[Read the rest of this article...]

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.
 

[Read the rest of this article...]

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.

[Read the rest of this article...]

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.

[Read the rest of this article...]

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.
 

[Read the rest of this article...]

There is no one standard definition of an accuracy 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 accuracy non-functional requirement is any requirement that is not a functional, data or process requirement concerned with defining the precision which the solution will record or produce data.

[Read the rest of this article...]

Before you can chart how you are going to implement a solution, everyone involved in the development effort must agree on why you need it to start with and that it is the very best solution available. Business requirements are fundamental to any development effort because they define where you are going by articulating the business problem and its solution—why it is needed and how to measure its success.

[Read the rest of this article...]

For almost every analyst, the day comes when you write a set of requirements that causes engineers to bemoan a recent development project that they just coded. "If only we'd known that you wanted to build this, we would have made the last project more flexible. Now we've hardcoded in changes that will take days to rebuild."

[Read the rest of this article...]

From a developer's standpoint, few things are more frustrating than having to make lots of calls and research to learn what to create because the requirements are ambiguous. From an analyst's view, few things are more frustrating than having your requirements misunderstood. Yet so often, requirements are ambiguous to their readers, despite the writer's best efforts.

[Read the rest of this article...]