Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @

EGI Core activities:2013-bidding Acceptance criteria

From EGIWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Main operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security

EGI Core services menu: Services PHASE I Services PHASE II Services PHASE III Bids Payments Travel procedure Performance

Go back to the EGI Core Activities Bidding page.

Go back to the Core EGI activity list.

  • Service name: Acceptance criteria
  • Service category: Software
  • Service type: Coordination, operation and maintenance


The quality criteria are the functional and non functional requirements that a product must fulfill to be released in UMD, these include generic requirement applicable to every product, and specific requirements applicable to the capabilities supported by a component.

Technical description

Incremental definition

The task must evolve the current set of quality criteria published in the |QC Document, removing the criteria no more relevant for the UMD distribution and adding the new criteria coming from operational requirements and new capabilities. The document drafts must be disseminated among the EGI technology providers and discussed to collect feedback from the developers. The task must maintain comprehensive wiki pages with the documentation to properly test the criteria, to be used during the verification, as well as the mapping products vs criteria. The task must also analyze the new products, and discuss with the software providers the capabilities relevant for the EGI communities.

Verification of acceptance criteria

All the products released in UMD must be verified against the relevant acceptance criteria. Products must be deployed in a controlled environment. Every product in UMD must have a verification report associated, with the results of the verification process. The verifiers must be familiar with the core products used in EGI, the most common site configurations and third parties components such as DBMS and LRMS.


The task must coordinate the verifications when the process is outsourced to developers or user communities, this means: overview to advancements in the process and collect the reports produced during verification, making sure that the relevant information (GGUS tickets opened, known issues) are properly propagated to the UMD release.


The verification for the most critical UMD components must be performed within this core activity.

Service level targets

Incremental definition

The task must produce a new document version every year, following two public drafts.

Verification of acceptance criteria

The verification activities must support the UMD releases. The estimated number of products to verify in one year is 200 PPA.