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.

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

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

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

• 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

Shows the artifacts required to complete the artifact under discussion.

Requirements are dependent on Business Needs. Business Needs are input to the Business Analysis Approach, the Stakeholder Engagement Approach, and the 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.)A functional requirement will include all observable inputs, all observable outputs, when they can occur, who (actor which) is allowed to initiate the requirement and the maximum time in which the requirement is allowed to complete.

• Consistent - Is the requirement in conflict with other project 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. For example, if one requirement states that all user inputs will be processed within 5 seconds of entry and another states that the system shall respond to a particular user input within 10 seconds, there is a conflict in the requirements.

• Correct – Are the requirements specifying a solution which the business wants implemented? For example, stating that a "data constant will be configurable" – does the business need this capability?

• 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. For example, stating that when the main window is closed that the system will logout the user, is too detailed, suppose we decide not to build a windowed application? A better way to abstract the requirement would be to say that when the user exits the application that they will be logged out.

• 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.

• Positive - Requirements state what the system will do. Anything else is considered out of scope. Stating the system ‘shall not’ do something is either untestable or irrelevant. For example, instead of stating that something shall not be ‘red’, state the colors that it may take. Another example; Stating that the system ‘shall not’ allow a user to view user information, is already covered by a requirement that an administrator shall be able to view user information. The fact that it has been stated that administrators may view this information, excludes all other actors, unless explicitly stated in a different requirement. (If you want to emphasize the point, write 'only' administrators'.)

• 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 in scope for the current project and 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. This is particularly true for non-functional requirements. If the non-functional requirement cannot be traced to 1 or more functional requirements, is it 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.

• Testable – Is it possible to define specific ranges of inputs and outputs for the requirement such that when the implementation of the requirement is executed all inputs cause the system to produce the specified outputs, otherwise the implementation of the requirement fails? For example, when declaring that a function will be available during ‘business working hours’, have those hours been defined?

• Time-Bound – If a 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).

• Unambiguous – The requirement should not contain any words that are open to interpretation (especially adjectives and adverbs), unless they are clearly defined in a project glossary. For example, the system shall allow ‘several’ users to change their profile. Unless the meaning of the word ‘several’ is explicitly defined this requirement has little meaning; and it can be satisfied by allowing exactly 2 users to change their profile and no more.