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.

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 Design and Coding Conventions level could be items such as

• Coding Naming Conventions * => All name of objects in source code are applied following the "Naming Conventions and Guidelines".
• Coding Standards and Conventions*
  • SQL-based Coding Conventions => All commands in SQL-based source code are applied following the "SQL-based Coding Standards and Guidelines".
  • Front-end Coding Conventions => All commands in Front-end source code are applied following the "Front-end Coding Standards and Guidelines".
  • Back-end Coding Conventions => All commands in Back-end source code are applied following the "Back-end Coding Standards and Guidelines".
• Database Naming Conventions* => All name of database objects and child components are applied following the "Naming Conventions and Principles".
• Database Design Policies* => All name of database objects and child components are applied following the "Design Principles and Policies".

At the QA/QC level could be items such as

• Test cases* => All test cases completed on committed environments:
  • DEV: Development environment (Required environment for Bootcamp project)
  • SIT: System Integration Test environment
  • UAT: User Acceptance Testing environment
  • PROD: Production or Staging environment
• 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.

Mentor(s) / Coach level (for training mode only) could be items such as

• Mentor(s) reviewed and accepted.
• Leader(s) / Manager(s) agreed and accepted.

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 »