1. Requirement MatrixConcepts and Implementation An End-to-end Paradigm in Building Quality Applications Bronnie F Tse bronnie@pacific.net.sg 立方体科技
2. Agenda Session I 1 RM basic concepts 2 Key features 3 Precedence & cascade Session II 4 Implements and Implementations 5 RM engine 6 Code generation Session III 7 Automated testing 8 Well known location paradigm 9 Quality cost
3.
4. In forms needing to educate readers: some might not be able to grasp
5. With hidden columns, collapsed outlines: often source of omission in implementation
6. Pseudo code is aplenty embodying a lot of implementation details such as permissible value lists, result codes: too technical and too complex not to miss something
18. The columnordertaking both Rules and Implements together is also insignificantNote the double line separating the Rules and the Implements
19. Requirement Matrix: Key Points Unambiguity This is good for so long as there are only Male and Female. This dimension is termed Invariant, which is a critical dependency in Business Rules. For the above to be “fool-proof”, it needs to be expanded to safeguard against future changes not well communicated. Invariants are often Enumerations. It is always a good practice to communicate the source of error with an error code NMF
20. Requirement Matrix: Dimension Completeness While Truth Table is Bi-state, Requirement Matrix is Tri-state, ie. “T”(rue), “F”(alse) and “” (Ignored), for which the cell is left un-entered Number of cases = 2(number of business rules), thus 2 rules are completely described in 4 cases However, Invariant is a special rulewith enumerated Elements that, in this example: Number of cases = (Number of Elements in Invariant + 1 ) * 2(number of business rules remaining) = (2+1)*21 = 6 Homonyms are collapsed to provide better clarity NMF2 NMF1 NMF Why are there only 5 shown?
21. Requirement Matrix: Systematic There should have been 2 as follows: FOA = Non male over age limit MOA = Non female over age limit FOA MOA
27. If one is employed with an income of SGD3,000 or less, one has to provide Proof of Income, which must be a CPF Contribution Statement
28.
29. Having dealt with income, then the Proof of Income becomes relevantRejection codes & text: E1 Employed with > SGD3,000 but without Proof of Income E2 Employed with SGD3,000 but without Proof of Income E3 Self-employed but without Proof of Income E4 Employment Status not acceptable
34. If one is employed with an income of SGD3,000 or less, one has to provide Proof of Income, which must be a CPF Contribution Statement
35. If one is self-employed, one has to provide Proof of Income, which must be an NTAThere are 2 Invariants, Employment Status (2 elements) and Proof of Income Document (3 elements), and 1 business rule remaining that ( (2+1) * (3+1) ) * 21 = 3 * 4 * 2 = 24 Mathematically, the number of cases to illustrate = ((Number of Elements in Invariant 1 + 1 ) * (Number of Elements in Invariant 2 + 1 ) * 2(number of business rules remaining)
43. Capitalise on pertinent technology: when using MS Excel, hyperlinks can be inserted to provide easy cross-referencing to other material
44. Automate tasks: the sometimes daunting task of compiling a full list of error codes can be achieved promptly through some VBA and/or VSTO implementation/s
45. Contribute to the CMMI Traceability* Critically important to achieving timely Sign-Off and successes in Testing phases
46. Requirement Matrix: Verification … on that requirement is indeed met Depending on the type of application, test cases can be as simple as sets of data being run through a batch program More commonly, each may represent a series of steps in a process flow, which is typical of interaction intensive applications This matrix demonstrates the test coverage drawing clear correlation between Requirement and the Verification of it Traceability is also achieved Functional Requirement FunctionVerification In a separate matrix bound through Test Suite references
47. Agenda Session I 1 RM basic concepts 2 Key features 3 Precedence & cascade
57. in forms like 1, 2, 3 and 4, or E, R, SE and UERulesandImplements(aka Actions) are in the Businessdomain, in which order on columns and rows are insignificant Implementationis in the DesignandDevelopmentdomain, in which order on columns and rows can be, but not necessarily, significant
58. Requirement Matrix: Process Recap For i = 1 To UBound(Rules_Evaluation_Result) Rules_Evaluation_Result(i) = Implemenation(i) Next For i = 1 To UBound(Evaluation_Control) Do For j = 1 To Evaluation_Control(i).Evaluation_Count If Rules_Evaluation_Result(Evaluation_Manifest(Evaluation_Control(i).Evaluation_Start* 2 + (j * 2 - 1))) <> _ Evaluation_Manifest(Evaluation_Control(i).Evaluation_Start* 2 + (j * 2)) Then Exit Do End if Next For j = 1 To Execution_Control(i).Execution_Count x = Implemenatation(Execution_Manifest(Execution_Control(i).Execution_Start + j)) Next Exit Function Loop Until 0 = 0 Next SystemCatastrophe These are high value-add activities. When done RIGHT, the system can be built in very high precision. 1 Matrix the Requirement 2 Add Implementation 3 Transform into programming artefacts 4 Write code 3 Generate Code This appears to be quite complex. However, the steps are very algorithmic thus can be automated. This is actually very deterministic that can be easily automated. Function Implementation(SerialAs Integer) As Integer Select Case Serial Case 1 Implementation = IIf(applicant.ES = 1, 1, 0) Case 2 Implementation = IIf(applicant.ES = 5, 1, 0) Case 3 Implementation = IIf(applicant.Gross > 3000.00, 1, 0) Case 4 Implementation = IIf(applicant.POI = 1, 1, 0) Case 5 Implementation = IIf(applicant.POI = 2 Or applicant.POI = 3, 1, 0) Case 6 Implementation = IIf(applicant.POI = 4, 1, 0) Case 7 Implementation = LoanEligible(7) Case 8 Implementation = LoanEligible(9) Case 9 Implementation = ThrowEx(E1) Case 10 Implementation = ThrowEx(E2) Case 11 Implementation = ThrowEx(E3) Case 12 Implementation = ThrowEx(E4) Case Else SystemCatastrophe End Select Should 1 & 2 be achieved using MSExcel, 3 & 4 can be automated usng VSTO (Visual Studio Tool for Office) Matrix everything that can be matrix-ed Automateeverything that can be matrix-ed
59. Agenda Session I 1 RM basic concepts 2 Key features 3 Precedence & cascade Session II 4 Implements and Implementations 5 RM engine
60. Requirement Matrix: An Optimised Generic Engine 1/2 Function Income_Verification_Implementation(Serial As Integer) As Integer Select Case Serial Case 0 Income_Verification_Implementation = _ IIf(applicant.ES = 1, 1, 0) * 2 ^ 0 OR _ IIf(applicant.ES = 5, 1, 0) * 2 ^ 1 OR _ IIf(applicant.Gross > 3000.00, 1, 0) * 2 ^ 2 OR _ IIf(applicant.POI = 1, 1, 0) * 2 ^ 3 OR _ IIf(applicant.POI = 2 Or applicant.POI = 3, 1, 0) * 2 ^ 4 OR _ IIf(applicant.POI = 4, 1, 0) * 2 ^ 5 Case 1 Income_Verification_Implementation = LoanEligible(7) Case 2 Income_Verification_Implementation = LoanEligible(9) Case 3 Income_Verification_Implementation = ThrowEx(E1) Case 4 Income_Verification_Implementation = ThrowEx(E2) Case 5 Income_Verification_Implementation = ThrowEx(E3) Case 6 Income_Verification_Implementation = ThrowEx(E4) Case Else SystemCatastrophe End Select Upon code being generated the Requirement Matrix engine can sport a more complex design without concern on inadvertant implementation mistakes Object Income_Verification TypeHolon_Descriptor Significance Integer 13, 21, 29, 13, 13, 34, 34, 3 TargetMatch Integer 13, 21, 5, 9, 1, 34, 2, 0 ExecutionPlan Integer 1, 3, 4, 2, 8, 2, 16, 32 Implementation Function _ ‘Income_Verification_Implementation’ Function RM_Engine(RM_Manifest As Holon_Descriptor) k = Execute(RM_Manifest.Implementation(0)) For i = 1 To UBound(RM_Manifest.Significance) If (kAndRM_Manifest.Significance(i))=_ RM_Manifest.TargetMatch(i)Then k = RM_Manifest.ExecutionPlan(i) Do While k <> 0 j = j + 1 If k And (2 ^ (j - 1)) <> 0 Then k = k Xor (2 ^ (j - 1)) x = Execute(RM_Manifest.Implementation(j)) End If Loop Exit Function End If Next SystemCatastrophe Core.RM_Engine(Income_Verification)
69. Precedence and Cascade 2/2 Function RM_Engine(RM_Manifest As Holon_Descriptor) Do Do k = Execute(RM_Manifest.Implementation(0)) For i = 1 To UBound(RM_Manifest.Significance) If (kAndRM_Manifest.Significance(i))=_ RM_Manifest.TargetMatch(i)Then k = RM_Manifest.ExecutionPlan(i) Do While k <> 0 j = j + 1 If k And (2 ^ (j - 1)) <> 0 Then k = k Xor (2 ^ (j - 1)) x = Execute(RM_Manifest.Implementation(j)) End If Loop If RM_Manifest.Recur <> 0 then Exit Do Exit Function End If Next SystemCatastrophe Loop Until 0 = 0 Loop Until Execute(RM_Manifest.Implementation(RM_Manifest.Recur)) = 0 Object Disbursement Type Holon_Descriptor Significance Integer 1, 3, 3 TargetMatch Integer 1, 2, 0 ExecutionPlan Integer 1, 2, 4 Implementation Function _ ‘Disbursement_Implementation’ Recur Integer 4 Function Disbursement_Implementation(Serial As Integer) As Integer Select Case Serial Case 0 Disbursement_Implementation = _ IIf((Credit_Card.Interest + Credit_Card.Spending) > 0, 1, 0) * 2 ^ 0 OR _ IIf(Overdraft.Total > 0, 1, 0) * 2 ^ 1 Case 1 Disbursement_Implementation = _ Core.RM_Engine(Credit_Card_Disbursement) Case 2 Disbursement_Implementation = _ Deduct_Overdraft() Case 3 Disbursement_Implementation = _ AddTo_House_Suspense() Case 4 Disbursement_Implementation =_ IIf(Payment.Amount <> 0, 1, 0) Case Else SystemCatastrophe End Select Renders a simple mechanism to produce neatly structured code Object Credit_Card_Disbursement Type Holon_Descriptor Significance Integer 1, 1 TargetMatch Integer 1, 0 ExecutionPlan Integer 1, 6 Implementation Function _ ‘Credit_Card_Disbursement_Implementation’ Recur Integer 0
70. Enhanced Requirement Matrix: An Optimised Generic Engine ^ with diagnostic information Function RM_Engine(RM_Manifest As Holon_Descriptor) Do Do k = Execute(RM_Manifest.Implementation(0)) For i = 1 To UBound(RM_Manifest.Significance) If (k And RM_Manifest.Significance(i)) = _ RM_Manifest.TargetMatch(i) Then k = RM_Manifest.ExecutionPlan(i) Do While k <> 0 j = j + 1 If k And (2 ^ (j - 1)) <> 0 Then k = k Xor (2 ^ (j - 1)) x = Execute(RM_Manifest.Implementation(j)) End If Loop If RM_Manifest.Recur <> 0 then Exit Do Exit Function End If Next SystemCatastrophe Loop Until 0 = 0 Loop Until Execute(RM_Manifest.Implementation(RM_Manifest.Recur)) = 0 Object Disbursement Type Holon_Descriptor Significance Integer 1, 3, 3 TargetMatch Integer 1, 2, 0 ExecutionPlan Integer 1, 2, 4 Implementation Function ‘Disbursement_Implementation’ Recur Integer 4 ID Text ‘Disbursement’ Function Disbursement_Implementation(Serial As Integer) As Integer Select Case Serial Case 0 Disbursement_Implementation = _ IIf((Credit_Card.Interest + Credit_Card.Spending) > 0, 1, 0) * 2 ^ 0 OR _ IIf(Overdraft.Total > 0, 1, 0) * 2 ^ 1 Case 1 Disbursement_Implementation = _ Core.RM_Engine(Credit_Card_Disbursement) Case 2 Disbursement_Implementation = _ Deduct_Overdraft() Case 3 Disbursement_Implementation = _ AddTo_House_Suspense() Case 4 Disbursement_Implementation = _ IIf(Payment.Amount <> 0, 1, 0) Case Else SystemCatastrophe End Select Core.RulesMatched(k, RM_Manifest) Core.SerialOutOfBound(Serial, _ “Disbursement (0-4)”) Core.RulesNotMatched(k, _ RM_Manifest) Core.RM_Engine(Disbursement)
71. Agenda Session I 1 RM basic concepts 2 Key features 3 Precedence & cascade Session II 4 Implements and Implementations 5 RM engine 6 Code generation
72.
73. Tasks to be performed has 2 priorities: high and normal; high priority tasks should be executed in preference
74. High priority tasks include those not completed at the time the service had an unscheduled break
75.
76.
77. For general review and analysis, development sign-off, regression test benchmarking, etc
78.
79. Agenda Session I 1 RM basic concepts 2 Key features 3 Precedence & cascade Session II 4 Implements and Implementations 5 RM engine 6 Code generation Session III 7 Automated testing 8 Well known location paradigm
84. Total cost benefitsHolon Y Holon A Holon P Holon Q Holon B Data elements in columns Test cases in rows Incident Diagnostic Information Collection Test Harness: 1 Bring in Unit under test 2 Create Data objects 3 Drive test data by row 4 Collect and insert back watch result 5 Time stamping for performance analysis Data access & staging in Well Known Location Data Object Data Objects 1 6 2 3 4 5 Unitunder test
85. Agenda Session I 1 RM basic concepts 2 Key features 3 Precedence & cascade Session II 4 Implements and Implementations 5 RM engine 6 Code generation Session III 7 Automated testing 8 Well known location paradigm 9 Quality cost
86.
87.
88. The later in the Life Cycle Stage when one is found the costlier it will be
89. The cost illustration does not include cost of consequential damagesCost to remove “bug” (note the non linear scale) System Requirement SystemVerification 100,000 Get the requirement right, first time, on time, every time, to curtail cost 10,000 Functional Requirement FunctionVerification 1,000 Component Requirement InteractionVerification 100 Program Requirement Implementation Verification 10 Life Cycle Stage when “bug” found Rollout Test Development Design Requirement
90. Requirement MatrixConcepts & Implementation Building Quality Applications Questions? Thoughts to share? Session I 1 RM basic concepts 2 Key features 3 Precedence & cascade Session II 4 Implements and Implementations 5 RM engine 6 Code generation Session III 7 Automated testing 8 Well known location paradigm 9 Quality cost
