Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work.
Verifying requirements ensures that the requirements have been defined correctly; that is, that they are of acceptable quality. Requirements that do not meet quality standards are defective and must be revised. Requirements verification constitutes a final check by the business analyst and key stakeholders to determine that the requirements are:
Requirements [Any Except Stated]: Any requirement may be verified (including business, stakeholder, solution, and transition requirements).Verification is a quality check performed following analysis of a requirement.
1. Characterstics of Requirements Quality
Correct: Defects in requirements will lead to defects in the resulting solution.
Feasible: Each requirement must be implementable within the existing infrastructure, with the existing budget, timeline and resources available to the team (or the project must develop the capability to implement the requirement). The business analyst needs to work with the project team to make these determinations.
Modifiable: Related requirements must be grouped together in order for requirements to be modifiable. This characteristic is exhibited by a logical structuring of the requirements.
Unambiguous: Individual requirements must never be unclear. A requirement must not allow for multiple divergent valid interpretations of the requirement.
Testable: There must be a way to prove that a requirement has been fulfilled. Each requirement should be testable—that is, it must be possible to design a test that can be used to determine if a solution has met the requirement or some other means of determining whether to accept a solution that meets the requirement.
2. Verification Activities
Verification activities are typically performed iteratively throughout the requirements analysis process. Verification activities include:
Check for completeness within each requirements model. For example, data flow diagrams will have all components and data flows labeled, and all data flows will have arrows indicating direction.
Compare each prepared requirements model (textual or graphical) against all other prepared requirements models. Check for elements that are mentioned in one model that are missing in the other models. Also check that the same component is referenced the same way in all models – for example, use of consistent language, e.g., ‘customer’ and ‘client’. Resolve all discrepancies, correcting terminology, or adding/deleting components as needed.
Make sure all variations to the documented processes have been identified and documented. Pay particular attention to common branching logic – e.g. “none found”, “one and only one found” or “more than one found”.
Make sure all triggers and outcomes have been accounted for in all variations.
Make sure the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms within the organization.Add examples where appropriate for clarification and to strengthen the business case.
1. General Techniques
Acceptance and Evaluation Criteria Definition: Ensure that requirements are stated clearly enough to devise a set of tests that can prove that the requirement has been met.
Problem Tracking: May be used to ensure that any problems identified during verification are resolved.
Structured Walkthrough: Used to inspect requirements documentation to identify ambiguous or unclear requirements.
Checklists are useful as a quality control technique for requirements documentation. They may include a standard set of quality elements that the business analyst or other reviewers use to validate the requirements or be specifically developed to capture issues of concern to the project. The purpose of a checklist is to ensure that items that the organization or project team has determined are important are included in the final requirements deliverable(s), or that process steps that the organization or project team has determined must be followed are addressed. Checklists may also be developed on a project basis to help ensure consistency of approach and outcomes, particularly on large projects where multiple sub-project teams are working.
All Stakeholders: The business analyst, in conjunction with the domain and technical subject matter experts, has the primary responsibility for determining that this task has been completed. Other stakeholders may discover problematic requirements during requirements communication. Therefore, virtually all project stakeholders are involved in this task.
Requirements [Verified]: Verified requirements are of sufficient quality to allow further work based on those requirements to be performed.
Business Analyst Related Interview Questions
|Business Analyst Interview Questions||Business Letter Format Interview Questions|
|Business Communications Interview Questions||Business Environment Interview Questions|
|Business Management for Financial Advisers Interview Questions||Business Development Interview Questions|
|Business Management Interview Questions||Executive Business Analyst Interview Questions|
|Business Objectives Interview Questions||Business Development Manager Interview Questions|
Business Analyst Tutorial
Business Analysis Planning & Monitoring
Requirements Management & Communication
Solution Assessment & Validation
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.