Requirement

Details

A Requirement receives input from Change Assessment and Elicitation Results. Requirements provide input to Change Assessments Design Options, Risk analysis Results, Traceability and the Requirement Architecture. They are used by any and all stakeholders. A Requirement includes Design, and contains 20 attributes and 6 operations.

Operations

There are 6 tasks that are specific to requirements. The following is a logical sequence for performing these tasks, but once the requirement is specified these tasks may occur in any sequence.

• Specify and Model Requirements - Analyze, synthesize, and refine elicitation results into requirements and designs.

• Prioritize Requirements - Rank requirements in the order of relative importance.

• Approve Requirements - Obtain agreement and approval of requirements and designs.

• Verify Requirements - Confirm that requirements and designs specifications and models meet quality standards.

• Validate Requirements - Test requirements and designs to ensure they align with business needs.

• Maintain Requirements - Keep requirements and designs accurate to support reuse in future solutions.

Attributes

• Basis for Prioritization – A statement agreed upon by relevant stakeholders as defined in the Business Analysis Planning and Monitoring knowledge area.

• Challenges of Prioritization – An assessment of relative prioritization values.

• Continual Prioritization – A list of priorities that may be assigned to a requirement.

• Maintain Requirements – A list of maintenance changes.

• Maintain Attributes – A list of changes to requirement attributes.

• Reusing Requirements – A statement containing the source of the requirement.

• Understand Stakeholder Roles – A RACI showing the stakeholder roles.

• Conflict and Issue Management – A requirements issues list.

• Gain Consensus – A record of requirement approval.

• Track and Communicate Approval – A record changes to requirement Approval.

• Model Requirements – The parts of a requirements model that relate to the requirement.

• Analyze Requirements –The results of a requirements analysis that relate to the requirement.

• Represent Requirements and Attributes – A representation of the requirement attributes (such as a document, spreadsheet or class diagram).

• Implement the Appropriate Levels of Abstraction – A descriptive overview of the requirement.

• Characteristics of Requirements and Designs Quality – A description of the quality attributes.

• Verification Activities –A record of requirement verification.

• Checklist – A list of requirement verification attributes.

• Identify Assumptions – A statement of any assumptions made about the requirement.

• Define Measurable Evaluation Criteria – A list of Acceptance Criteria.

• Evaluate Alignment with Solution Scope – A statement describing the benefit of the requirement to the organization.

Life-Cycle

A Requirement is created, modeled, validated, verified, approved, prioritized, maintained and eventually archived (it is no longer maintained). Anytime a requirement is changed it the requirements model is updated and the lifecycle starts again.

States

A state name describes the primary action that is occurring to the requirement. In reality, these actions occur in parallel. The state diagram shows something that must be done before moving to the next state, and does not indicate that the action taken in that state is complete.

• Specify and Model – The requirement is being developed and modeled.

• Prioritize – The requirement is being ordered and priorities added..

• Validate – The requirement is being analyzed for consistency, accuracy, ambiguity and completeness.

• Verify – The requirement is being reviewed with the stakeholders.

• Approve – The requirement has been agreed to by the stakeholders.

• Maintain – The requirement has been implemented and retained for future reference.

• Archived – The requirement is no longer relevant to the organization.

Dependency Diagram

Requirements are dependent on Business Needs. Business Needs are input to the Business Analysis Approach, the Stakeholder Engagement Approach, and Elicitation Activity Plan, which is the input for Elicitation Results. All of these artifacts plus Change Assessments and the requirements themselves, contribute to Requirements.

Example

These are quality characteristics of a requirement:

• · Atomic - Does the requirement statement define exactly one requirement? Is the requirement statement free of conjunctions (and, or, but) that could indicate multiple requirements? Do not tie requirements together when it is unnecessary. All attributes of a single requirement, such as owner, schedule, risk, effort, etc. should take a single value that is applicable to that and only that requirement.

• · Complete - Is the requirement stated as a complete sentence? Is the requirement stated entirely in one place and in a manner that does not force the reader to look at additional information to understand the requirement? (References to external files such as a glossary are ok, if it avoids duplication). See functional requirement description for an example of completeness.

• · Consistent - Is the requirement in conflict with other requirements? Is the terminology used consistent with other requirement and glossary terms? Inconsistent requirements that implemented within the same system will allow development to choose one or the other. Resulting in potentially confusing results for the end users, and testers.

• · Design Independent - Is the requirement stated in such a way that all design options are permitted? If the requirement imposes any constraints on the design, thereby limiting options for development, are those limitations justified? A typical example is stating that a particular technology will be used, because that is the current technology. This restricts developers from replacing an out of date system with something that may prove cheaper and more efficient in the long run. Let the developers choose the best technology that fits within the project plan.

• · Feasible – Can the requirement be implemented within the known capabilities and limitations of the system and its environment? Architects and infrastructure analysts provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost or with other tradeoffs. Ask the project manager if the requirement can be satisfied within budget and on schedule? Ask developers if the requirement is feasible with current technology.

• · Measurable and Verifiable - Can you determine whether the system satisfies the requirement? Is it possible to define a clear, unambiguous pass or fail criterion? See whether you can devise tests or use other verification approaches, such as inspection or demonstration, to determine whether each requirement is properly implemented in the product. If a requirement is not verifiable, determining whether it was correctly implemented is a matter of opinion. Requirements that are not consistent, feasible, or unambiguous also are not verifiable.

• · Necessary – Is the requirement stated in such a way that it specifies the true need of the stakeholder? Did you specify something that was actually needed, or was there a misinterpretation? If possible, create a mockup of what you think might be delivered and ask the stakeholder to prioritize the delivery of this feature. You may find that the stakeholder doesn’t actually need the requirement, or that they had something else in mind.

• · Prioritized - Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to include it in a particular product release. Product owners and producers have overall responsibility for establishing priorities. If all the requirements are regarded as equally important, the project manager is less able to react to new requirements added during development, budget cuts, schedule overruns, or the departure of a team member. Priority is a function of the value provided to the customer, the relative cost of implementation, and the relative technical risk associated with implementation.

• · Relevant and Traceable - Is the requirement uniquely identified so that it can be referenced unambiguously? Can the requirement be traced from a source you recognize as having the authority to specify requirements. Trace each requirement back to its origin, such as a use case, system requirement, regulation, or some other voice-of-the-customer input. If you cannot identify the origin, perhaps the requirement is not really relevant.

• · Specific and Unambiguous - The reader of a requirement statement should be able to draw only one interpretation. Multiple readers of a requirement should arrive at the same interpretation. Natural language is highly prone to ambiguity. Avoid subjective words like user-friendly, easy, simple, rapid, efficient, several, state-of-the-art, improved, maximize, and minimize. Words that appear to be clear to the author may not have the same meaning to different readers. If using an adjective such as close, fast, etc., make sure that the word is well-defined in a project Glossary. Write each requirement in succinct, simple, straightforward language of the user domain. Effective ways to reveal ambiguity include formal inspections of the requirements specifications, writing test cases from requirements, and modeling the requirement using a formal (unambiguous) language.

• · Time-Bound – If the (functional) requirement describes an action or activity performed over a period of time, does it include; a pre-condition, one or more triggers, externally observable data, an expected post-condition, maybe one or more exceptional post-conditions and time to complete (time may be derived from non-functional requirements).