Requirements Verification & Validation

Requirements Verification

The requirements verification activity makes sure that the models and specifications adhere to the essential quality standards so that they can be utilized to effectively direct future work.

Requirements verification constitutes a final check by the business analyst and the client to determine that:

Requirements verification is the business analyst and client's last check to ensure that:

1. The customer and users can conduct a formal review of User Stories.
2. Items supply all the information needed to do the task.

Definition of Done

It's critical that the Product Owner and the team come to an understanding of what constitutes Done.

During the project chartering, "Done" typically means the following:

·????????Requirement coded/implemented

·????????Code is checked against the most recent source-control version (dev) Source control code has been validated and annotated.

·????????Code examined (Best practices that leads to refactoring and High-Quality Code) (Code refactored after being reviewed)

·????????Jenkins will collect automated metrics to monitor code coverage and prevent it from declining (all unit tests works fine and build compiles successfully) Needed Written and passing unit tests

·????????The planning and management tool updates the hours on the task list and completes the work (Jira and TFS), updated task tracking system

·????????Product Owners sign off functional working, based on the Story Acceptance Criteria.

·????????Functional working is approved by the product owners and business analysts based on the story acceptance criteria (devs will perform a walkthrough). Passing the functional walkthrough and being registered

·????????Generated and/or updated pertinent documentation, diagrams, and designs

·????????QC Signoff

·????????If the User Story has “User Interface,” it must work in the following browser: IE 9

User Story Quality

Main quality attributes of GOOD user stories:

• ?I (Independent) - The story does not depend on any other user story.
• N (Negotiable) - The story serves as a basis for discussion and can be developed further together.
• V (Valuable) - The story always elaborates on the user, customer, or client advantages.
• E (Estimable) - The story is quantifiable: it has enough concrete detail to enable an experienced team to appreciate its scope.
• S (Small) - The story is the right size.
• T (Testable) - The story contains enough information to allow it to be tested.

Verification Activities

The following are some of the verification activities that are routinely carried out throughout the sprints:

·????????Within each requirements model, make sure everything is complete.

·????????Examine the INVEST components for each Product Backlog Item in the sprint backlog.

·????????Ensure that all causes and effects have been discovered and recorded.

·????????Ensure that the team and users can grasp the terminology used in the story description and acceptance criteria.

·????????For explanation, include wireframes and samples.

·????????Before obtaining business approval, meet with the client team to discuss each Product Backlog Item.

Requirements Validation

All specifications must support the delivery of value to the business and satisfy customer needs, according to the requirements validation activity.

Verifying that the stakeholders, solution, and specifications adhere to the business requirements is a continuous process known as requirements validation.

Validation Activities

The validation tasks are usually completed throughout the sprints, and they cover:

·????????Wireframes: Schematics or diagrams of a page that include a preliminary version of the screen

·????????Prototyping: A minimally-efforted-for product with limited functionality (Proof Of Cconcept)

·????????Functional Walkthroughs: Functional validation of each developed and tested Product Backlog Item. Before doing QA tasks, the BA must ensure that the requirements outlined in the user story are satisfied and implemented as planned.

·????????Showcase: Formal presentation from the team to the business to go through every story that was implemented during the current sprint. The primary objective is to explain and demonstrate all features that were provided, known issues that should be resolved in the upcoming sprint, and the upcoming core features in order to convey how the current sprint came to a finish.

·????????UAT: To ensure that the business value offered is in line with the customer expectations, formal sessions with the end users are held.

Validation Activities – Functional Walkthrough

Validation Activities – Showcase

Recommended Steps

·????????Schedule the Showcase meeting at least one week in advance

·????????Audience: Client & Team

·????????Create a presentation that lists the key sprint-delivered features and known issues.

·????????Create test scenarios in a secure setting.

Expected Output

·????????Issues

·????????Changes

·????????New Requirements to be included in the following Sprints

·????????Client’s comments about the current progress

?

Validation Activities – Showcase

Recommended Steps

·????????Set aside one week in advance for the UAT Kickoff & touchpoint meetings.

·????????Audience: Product Owner, End Users, and Engagement Manager

·????????Create a presentation that lists the primary features that were delivered during the sprint, known problems, and scenarios that must be tested by the end users. It's critical to specify the testing procedures and outcomes that must be achieved for the requirements.

Expected Output

·????????Issues

·????????Changes

·????????New Requirements to be included in the following Sprints

·????????Client’s comments about the current progress