Getting started the with

Acceptance CRITERIA

Production-like Project with ALM Model

Acceptance CRITERIA of a Production-like Project

Acceptance criteria are conditions that are used to determine if the product has been implemented to requirements. They are defined by stakeholders such as product owners, mentors, leaders, solution architects, and quality assurance officers, and subject matter experts.

At edXOps Bootcamp, the acceptance criteria of a Production-like project are designed by various criteria and they would be used to evaluate the completion of a Production-like project. edXOps mentor needs to provide the criteria-acceptance before qualification of the product requirements and software architecture design and make sure these criteria are properly communicated to the project team.

Production-like Project


The acceptance criteria for a Production-like project are critical terms and conditions of any verification process and should be appropriate to the requirements of the software project. They are designed to be unambiguous such that stakeholders (including customer or product owner) can not reject product on an arbitrary basis.

At the QA/QC level could be items such as

  • Test cases* => All test cases completed.
  • Percentage of minor defects* => A specified percentage of cases completed with an allowed percentage of containing some number of minor defects.
  • Unit test => Unit test cases passed.
  • Non-Functional test => Non-Functional testcases passed.
  • Functional test => Functional test cases passed.
  • Acceptance test => Acceptance test cases completed.

System requirement level could be items such as

  • Website layout must be designed in a responsive mode (support cross-browser).
  • A user cannot submit a form without completing all the mandatory fields (with *).
  • Submitted information from the form is stored in the database.
  • An acknowledgment email is sent to the user after submitting the registration.

Product Owner level could be items such as

  • Product Owner reviewed and accepted.
  • Client / Customer reviewed and accepted.

The Functional level could be following items

  • Look and Feel (for example: the background color is compliant with the design style guide.)
  • Business Rules (for example: if the user gets their email wrong three times then they are locked out of the system for 10 minutes or require the user to key in captcha string.)
  • Process Flow (for example: when the user submits leave application an approval holiday is created in the HR system.)
  • Calculations (for example: if the user account does not sign in more than two years, the system will freeze this account.)
  • Events (for example: if a user does not purchase a product within 20 minutes of adding it to their shopping cart, the cart system is notified.)
  • Validation (for example: if the user adds invalid email address and press login button the system sends a warning message.)
  • Usability (for example: by default of button on the sign-in form, OK button is disabled until a valid email entered.)
  • Implementation (for example: Easy to implement or configure the system by developers, testers, and even end-users.)
  • Controls (for example: the system will automatic log all activities with a signed user.)
  • Operations (for example: the core of the website will integrate with the Web API and automatically request resources from another database system.)
  • Performance (for example: the system will have a load time of a page with 100K records less than 5 seconds with 100 concurrent users.)


Explore Complete FACTORS »

edXOps   © Copyright
edXOps Foundation.
All Rights Reserved.