This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: How do you define the term Requirement? While this may seem like a very simple question, few Business Analysts ever take the time to ask or to understand “what is a requirement”. Per the BABOK v2.0 “A requirement is: 1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. 3. A documented representation of a condition or capability as in (1) or (2).” Many business analysts may assume that requirements describe condition or capabilities of a system. Or perhaps they avoid this trap and expand a requirement to encompass a condition or capability of a business process. However, the BABOK definition has been carefully crafted to ensure that what is stated does not arbitrarily constrain the true definition of a requirement based on poor assumptions about the problem domain. A requirement, may relate to any number of problem domains that vary both by type and by scope, such as: • Organizational Structures • Business Processes • Business Policies • Business Rules • Roles/Stakeholders • Systems • Reports and Documents The possibilities are nearly endless. Additionally, a requirement can be defined at whatever level of detail or depth is necessary to accurately convey the condition or capability. It can be define at an enterprise level, a divisional level, a process level, and activity level, a task level, etc. In the real world requirements may be clearly understood or they may be implied or derived from other requirements. But, ultimately, when eliciting requirements for a project, a requirement is not truly a requirement until it is documented. A requirement may be documented as a requirement statement such as “The system shall…”, “The process shall…”, “The Financial Analyst shall…”, or it can be documented through any number of representative techniques including models and diagrams. Requirements are typically classified into a number of categories for easier organization and maintenance. The BABOK classifies requirements into the following categories. 1. Business Requirements 2. Stakeholder Requirements 1 3. Solution Requirements 1. Functional Requirements 2. Non-Functional Requirements 4. Transition Requirements What are the characteristics of a good requirement? While different organizations and authors may describe a slightly modified list, the following characteristics are generally accepted as those defining a good requirement. Cohesive: The requirement defines a single aspect of the desired business process or system....
View Full Document
This note was uploaded on 06/14/2011 for the course INF 100 taught by Professor Staff during the Spring '11 term at Ashford University.
- Spring '11