Sharing IT Best Practices with youSharing IT Best Practices with you
Starting DevOps organizations finds it grand to say they are finally relieved of the harness of the frameworks. ‘Fun with Scrum’ is now the credo. No Prince2®, ITIL®, ASL®, BiSL® and more. One of the aspects included is Static or Dynamic requirement management. This aspect is perfectly identified by the Business Information Services Library (BiSL) defined as the “Specify Information Requirements” process. With the advent of DevOps and even with the advent of Business DevOps (DevOps plus Information Management), there are no requirement managers in many organizations. This article is about whether or not this is wise.
A requirement is a description of a demand for functionality or quality. The quality is also called a Non-Functional Requirement (NFR).
A static requirement is a requirement whose lifecycle extends beyond the delivery of the product or service. The service management organisation, uses the requirement again to determine whether the product / service still meets the requirements. Where further discussed in this article about product is also meant service.
A dynamic requirement is a requirement whose life cycle ends at the delivery of the product to which the dynamic requirement is linked.
An acceptance criterion is a requirement imposed on the to be delivered product to be delivered to determine whether it meets the requirements.
A test case is a description of a check on the correct operation and behaviour of a to be delivered product.
Risk-based acceptance is the concept in which the test effort focuses on the identified risks. The risks are based on the identified requirements. Figure 1 shows the relationship between requirements, risks, acceptance criteria and test cases, or reviews and checklists.
The requirements come from all stakeholders and indicate where the product should comply with. These are therefore not only the requirements of the user organization, but also the requirements of the service management organization, legal affairs, etc.
Each requirement must be analysed for the risk that the requirements will not be fulfilled. The risks can to be classified in functional and quality risks. Figure 1 also shows the manageability risk because these risks are related to the service organization and not the user organization. Of course, manageability is also a quality aspect, but it is of such importance that it is shown separately in Figure 1.
It is important to recognize that, in addition to risk-based acceptance, risks are also identified by performing risk analyses based on artefacts of the DevOps process. These risks should be tested against the requirements. Often this leads to additions to the requirement because these aspects have not been considered yet.
The relationship between a requirement and an acceptance criterion is that the product will only be released if the identified risks are controlled (mitigated) or undone (eliminated). This can only be taken if preventive and / or reactive measures are affected during the realization of the product in the DevOps process. The assessment of the effectiveness of these measures is what includes the acceptance criterion.
The test of an acceptance criterion requires a number of tests and / or reviews and / or checks. This is the field of test management. Conversely, there are also many test types that are not linked to an acceptance criterion.
This article discusses the difference between static and dynamic requirements. As shown in Figure 1, requirements are the start of risk management. The article (DevOps from vision to scrumboard) also shows the relationship of a feature and a requirement. A requirement is therefore an object to be administered. There are various attributes that are added to a requirement such as the feature / story, test cases, and object that is claimed.
The core question is what information is required to be administrated to maintain the product after the delivery. The answer is unfortunately not black and white. Well, there are two extremes. Static requirements are written for products that meet one or more of the following:
Conversely, the dynamic requirements are for applications that meet the following requirements:
In addition, a product that meets the criteria for static requirements may also have a dynamic requirement. An example is a temporary requirement or a requirement that is no longer relevant to maintain because it is poured into concrete.
As stated in article (DevOps from vision to scrumboard) a traceability requirement is a very important quality aspect of the deployment pipeline. Partially and partly non-conforming requirements cause some ease but also a lot of inconvenience. There will then be a countdown of whether or not the Static / Dynamic requirement flag is to be Static. And if the flag is set top dynamic, then traceability is still only partly possible.
The question is how much time this actually saves. As soon as the tooling is integrated and is working properly, it does not matter much more anymore. The dynamic requirements must also be tested and preferably automatically. So why throwing away something that works? In case all requirements are manual written in documents and no interfaces with other objects exists, then it might make sense to recognize the dynamic acceptance criteria. In that case the traceability is often also not in place.
So, requirements are still very important objects to register and maintain. Therefore, the best practices of BiSL regarding the process ‘Specify Information Requirements’ should still be taken seriously into account in DevOps. Also, the testing of the requirement by the use of best practices of TMAP is important within DevOps. Last but least are the best practices of ITIL concerning acceptance criteria a control mechanism that cannot be left out of DevOps.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Acceptatiecriteria, ISBN: 9789071501784
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.