Contents
Background and Hypotheses
Banks provide a decision-rich and data-rich setting in which a couple of emerging analysis techniques – ‘decision modelling’ and using data to improve requirements – could combine to produce better quality requirements and reduce project timescales.
The banking industry is subject to more regulation than almost any other. This burden is not only a function of the sheer volume of regulatory requirements, but also of the obligation to evidence compliance via myriad reports.
Many of these regulatory obligations come down to having to create software to make some sort of decision (e.g. about an account, a customer, a transaction, a complaint, a trade, etc.), and then to report to the regulator on that decision and possibly its rationale. The following are some examples:
Is this account subject to the Foreign Account Tax Compliance Act (FATCA)?
Following the Independent Commission on Banking (ICB), is this activity prohibited in the Retail Bank?
How do we route this trade order to achieve best execution?
Has this customer complaint been handled, recorded and reported in accordance with the FCA’s guidelines?
How should this account be marked according to the EU Deposit Guarantee Scheme Directive (EU DGSD)?
The latter forms the starting point for our worked example below.
One approach to improving requirements is to inject production data into the requirements specification phase of a project. Typically, requirements and data don’t cross paths until the testing phase (test data) or even after a system has gone live (production data). This is rather late in the life-cycle to learn about all the data quality issues and all the corner cases not anticipated when defining the requirements – resulting in a project completion date being pushed out due to necessary rework and data quality issue remediation (Figure 1).
Figure 1 – Typical project life-cycle
A helpful characteristic of banks is that they have vast amounts of production data to help them make decisions like the ones above. By validating business requirements against this data, it is possible to bring forward much of this learning (Figure 2).
Figure 2 – Quicker delivery thanks to better requirements
As a means of introducing data into the requirements specification process, this article promotes the use of an emerging analysis technique called Decision Model & Notation (DMN). For systems that require a decision to be made, it is helpful to use a common language designed for articulating decisioning requirements1. DMN offers a compelling option which is discussed in more detail below. Part of the driver for its creation was that existing modelling techniques, like Business Process Modelling (BPM), don’t provide a convenient way of describing how decisions are made. DMN complements BPM to provide a visual depiction of decisions and the underlying data inputs and business logic.
Both DMN and improving requirements with data bring something to the party. There are, in addition, potential synergies in combining these two ideas. DMN lends itself particularly well to creating testable requirements and test cases. And while it can be used standalone as a way of thinking about and representing requirements, it can also be supplemented by tools which enable the requirements to be tested using real data.
The rest of this article elaborates on these ideas, highlighting the potential benefits to banks.
Using Data to Validate Requirements
By applying production data to the requirements definition process, it is possible to reduce the project life cycle and improve the quality of the software deliverable.
Figure 3 – Aspiration Project Life-cycle
In the simplified project life-cycle above, the requirements phase typically involves analysts interviewing subject matter experts (SMEs) about what they need – i.e. what are the rules, who are the users, what’s got to be done by when, etc., and recording these requirements using a combination of written descriptions and diagrams (e.g. UML, Process flows, etc.). These feed into the next phase with developers coding software, probably with intermediate levels of description such as functional specifications. In parallel, test analysts use the requirements to develop test cases. In the test phase, the code and tests come back together. It is at this stage that some problems are usually discovered, generating rework.
Often, the kind of problems discovered in the test phase result from different interpretations of the requirements. The test analyst and the developer have seen the same set of words but understood something different. Alternatively, a gap in the requirements has been filled by a developer making a design decision, without necessarily informing the tester or revising the requirements documentation. As a result, a more realistic completion date takes into account this rework, as shown below.
Figure 4 – Delays due to rework
The second wave of learning occurs once the project starts running into problems in production due to all of the scenarios that were overlooked, requirements not foreseen, etc. Also, here the project tends to come up against a lot of data quality (DQ) related issues. The system breaks because a data field is not correctly populated. Testing was performed using test data which was constructed on the assumption that the required fields would be complete and correct. In the real world, however, data is at times wrong, corrupt, missing, etc. The net result of having to resolve these DQ issues is another shift of the project completion date.
Figure 5 – Delays due to data quality problems
The progression above highlights two familiar sets of feedback which generate rework and cost in a project. The first prolongs the project life cycle. The second causes problems in live and unhappy users, among other issues.
By employing production data in the process, it is possible to discover those edge cases or more obscure rules prior to handing the requirements over to software developers and test analysts, minimising the number of judgement calls they must make and so leading to less misalignment in the test phase. Another by-product of using lots of test cases is much better test coverage. This leads to far fewer issues in testing. Also, DQ problems are uncovered much earlier in the process. This dramatically speeds rule discovery and improves the quality of the business rules.
Figure 6 – Quicker delivery thanks to better requirements
Benefits Summary
Validating requirements with real data brings the following benefits:
- Data quality issues are uncovered earlier in the project life-cycle;
- Missing / implicit requirements are discovered earlier;
- Better test coverage and fewer failures in live;
- Less rework resulting from change requests;
- The above all contribute to shorter project timescales.
Decision Modelling
In December 2014, the Objects Management Group (OMG)2 approved the Decision Model & Notation (DMN) standard (version 1.0), a modelling notation for decisions that complements the popular Business Process Model & Notation (BPMN) standard. As already mentioned, DMN provides a convenient approach to feeding data into requirements definition.
As discussed above, a proliferation of regulatory requirements, of which reporting requirements make up a large portion, and which have a tendency to be very data-hungry, are driving banks to consider better ways of capturing those requirements and ensuring compliance.
While DMN was not conceived for any specific industry, as an analytical approach it seems to suit the decision-rich and data-rich setting of banks particularly well.
To-date, due to a lack of separation of concerns, decision logic has tended to be buried in code, making it inflexible, hard to maintain, and prone to errors. In the design phase of a project, incorporating business decisions into business process models makes these models overly complex and difficult to interpret. Also, business process gateways (the diamond-shapes that signify a decision in a BPM) typically reveal little about the inputs or the logic underpinning that decision. By separating out the business logic, it is possible to dramatically simplify the business process, and complement it with a much richer description of the business logic.
There are two core elements to DMN worth elaborating on here:
1. Decision Requirements Graphs (DRGs) visually represent the dependencies of decisions on data, business logic/rules, the sources of those rules, and other decisions. This provides an easily digestible breakdown of decisions and their requirements. In particular, it starts to bring out the data requirements which, as we suggest in the next section, may be leveraged to validate the model.
2. Decision Tables articulate the business logic, i.e. the rules, in a tabular format. A Decision Table is not the only way in which to represent rules, but it is the most convenient for software development and testing. Every row in a decision table essentially represents a scenario – a combination of inputs resulting in defined outcomes. Considering the decision logic level of the requirements at this stage encourages the analyst to think about all the combinations of data attributes and values to meet the requirement early on in the process. This becomes very useful, for example, when constructing test data. The economy of decision tables also means that the overall number of rows indicates the minimum number of test cases required to cover all the decisioning requirements.
Figure 7 – Aspects of DMN (Source: http://www.omg.org/spec/DMN/)
Benefits Summary
The benefits of using DMN in requirements definition are that it:
- Provides the constructs that are needed to model decisions, so that organisational decision-making can be readily depicted in diagrams, accurately defined by business analysts, and (optionally) automated.
- Encourages thinking about data requirements early on in the project life-cycle.
- Identifies the minimum number of scenarios test data will need to cover.
A Note on Technologies
DMN can be supplemented by tools to improve the requirements by modelling the requirements against real data to discover missing or implicit requirements.
There is a growing number of emerging technologies to help model and validate decisioning requirements. Since DMN was accepted as an industry standard last December, there is a move to align to its notation language, including DRGs and Decision Tables. Furthermore, an increasing number of tools are starting to include functionality that allows models to be validated with data.
The Decision Management Community helpfully maintains product catalogues that list and compare the latest decision management tools.
Worked DMN Example
HBW has written before about the recast EU Deposit Guarantee Schemes Directive (DGSD).
Our worked example (request here) shows a Business Process Model (BPM) to determine which deposits are required to be included on an FSCS Single Customer View (SCV) file and how they should be ‘marked’ according to the directive. DMN is used to illustrate how the decisions in this BPM are underpinned by a set of business rules and a network of dependencies. It distils into circa 10 slides in PowerPoint some 200 pages of regulation from Consultation Papers CP20/14 and CP4/15.
The example demonstrates how DMN lends itself well to diagrammatically representing the compilation of the SCV file and how it may highlight any deficiencies in data quality.
If you would like to know more or request a demo, please contact Tripple Consulting.
Further Reading
- Object Management Group’s DMN documentation
- Decision Model & Notation (DMN) LinkedIn Discussion Forum
- The Decision Model – a predecessor to DMN with a similar focus on better articulating decisions.
- The Decision Management Community
1. Note: The approaches discussed here are not relevant for those requirements dealing with user interface, performance, permissions, non-functional requirements, etc.↩
2. Computer industry standards consortium who also adopted Unified Modelling Language (UML) and Business Process Model & Notation (BPMN) as standards.↩
