Latest Requirements Buzz
An Overview of Requirements ElicitationA 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 elici...
Brûlé’s Rules of Playing Telephone with RequirementsYou 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 analys...
An Overview of Organizing RequirementsThe 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 interdep...
An Overview of Requirements PrioritizationExcellent 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.
Business RequirementsThe 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.
Availability RequirementsThere 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.
Accuracy RequirementsThere 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.