Every serious project SHOULD have principles and/or requirements defined. Using de-facto standards as add-on for your functional requirements can speed up your project. Below a list of sources of requirements that can speed up business IT projects:
|Business Process Models must be based on BPMN 2.0|
|Name of REQ||Business Process Models must be based on BPMN 2.0|
|despcription||BPMN 2.0 must be used
A standard Business Process Model and Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner. Furthermore, the graphical notation will facilitate the understanding of the performance collaborations and business transactions between the organizations.
|Digital Signature Standard (DSS) (FIPS PUB 186 – 4)|
|Name of REQ||Digital Signature Standard (DSS) (FIPS PUB 186 – 4)|
|despcription||Digital Signature Standard (DSS) - FIPS PUB 186-4
This Standard defines methods for digital signature generation that can be used for the protection of binary data (commonly called a message), and for the verification and validation of those digital signatures. Three techniques are approved.
(1) The Digital Signature Algorithm (DSA) is specified in this Standard. The specification includes criteria for the generation of domain parameters, for the generation of public and private key pairs, and for the generation and verification of digital signatures.
(2) The RSA digital signature algorithm is specified in American National Standard (ANS) X9.31 and Public Key Cryptography Standard (PKCS) #1. FIPS 186-4 approves the use of implementations of either or both of these standards and specifies additional requirements.
(3) The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified in ANS X9.62. FIPS 186-4 approves the use of ECDSA and specifies additional requirements. Recommended elliptic curves for Federal Government use are provided herein.
|FIPS PUB 198-1:The Keyed-Hash Message Authentication Code (HMAC)|
|Name of REQ||FIPS PUB 198-1:The Keyed-Hash Message Authentication Code (HMAC)|
|despcription||FIPS PUB 198-1:The Keyed-Hash Message Authentication Code (HMAC)
Providing a way to check the integrity of information transmitted over or stored in an unreliable medium is a prime necessity in the world of open computing and communications. Mechanisms that provide such integrity checks based on a secret key are usually called message authentication codes (MACs). Typically, message authentication codes are used between two parties that share a secret key in order to authenticate information transmitted between these parties. This Standard defines a MAC that uses a cryptographic hash function in conjunction with a secret key. This mechanism is called HMAC [HMAC]. HMAC shall use an Approved cryptographic hash function [FIPS180-3]. HMAC uses the secret key for the calculation and verification of the MACs.
|Implementation must comply to the”Do Not Track Compliance Policy”|
|Name of REQ||Implementation must comply to the”Do Not Track Compliance Policy”|
|despcription||The website (DNS) is compliant with the privacy-friendly Do Not Track (DNT) Policy of the EFF.org organization.
w3c reference: http://www.w3.org/TR/tracking-dnt/|
|Name of REQ||JSON-LD|
|despcription||JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. JSON-LD is an ideal data format for programming environments, REST Web services, and unstructured databases such as CouchDB and MongoDB.
|Payment Card Industry (PCI) DSS v3.1|
|Name of REQ||Payment Card Industry (PCI) DSS v3.1|
|despcription||The design/implementation must be compliant with the Payment Card Industry (PCI) Data Security Standard version 3.1
PCI DSS provides a baseline of technical and operational requirements designed to protect account data. PCI DSS applies to all entities involved in payment card processing — including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).
Detailed spec on: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf|
|Payment Card Industry (PCI) Point – to – Point Encryption|
|Name of REQ||Payment Card Industry (PCI) Point – to – Point Encryption|
|despcription||Payment Card Industry (PCI) Point - to- Point Encryption Solution Requirements and Testing Procedures Version 2.0
The objective of this standard is to facilitate the development, approval, and deployment of PCI-approved P2PE solutions that will increase the protection of account data by encrypting that data from the point of interaction within the encryption environment where account data is captured through to the point of decrypting that data inside the decryption environment, effectively removing clear-text account data between these two points. The requirements contained within this standard are intended for P2PE solution providers and other entities that provide P2PE components or P2PE applications for use in P2PE solutions, as well as P2PE assessors evaluating these entities. Additionally, merchants benefit from using P2PE solutions due to increased protection of account data and subsequent reduction in the presence of clear -text account data within their environments.
Details specs can be found at: https://www.pcisecuritystandards.org/documents/P2PE_v2_r1-1.pdf|
|Secure Hash Standard (SHS) – FIPS PUB 180 – 4|
|Name of REQ||Secure Hash Standard (SHS) – FIPS PUB 180 – 4|
|despcription||This Standard specifies secure hash algorithms, SHA -1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-
512/256. All of the algorithms are iterative, one-way hash functions that can process a message to produce a condensed representation called a message digest. These algorithms enable the determination of a message’s integrity: any change to the message will, with a very high probability, result in a different message digest.
The digests are used to detect whether messages have been changed since the digests were generated.
|Name of REQ||Semantic Versioning|
|despcription||All version numbering must match Semver 2.0
Given a version number MAJOR.MINOR.PATCH, increment the:
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
|Systems must comply with BIOS Integrity Measurement Guidelines|
|Name of REQ||Systems must comply with BIOS Integrity Measurement Guidelines|
|despcription||The systems must implement measurements as described in the NIST Special Publication 800-155 (BIOS Integrity Measurement Guidelines).
Client computers such as desktops and laptops rely on the Basic Input/Output System (BIOS) to initialize their hardware during boot. The BIOS is firmware, and it can be configured. If the BIOS code or configuration is altered from the intended state, either maliciously or accidentally, the desktop or laptop may experience losses of confidentiality, integrity, and availability, including system instability, system failure, and information leakage.
for more information|
|Web Hypertext Application Technology Working Group (WHATWG)|
|Name of REQ||Web Hypertext Application Technology Working Group (WHATWG)|
|despcription||The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.
The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.