Advent of "Requirements Capture Language" (RCL), an alternative to the UML Use Case Diagrams
By econcinnity
“IT Requirements”, the very word means a “pack of ambition” to own a software system that enables businesses & communities in excelling / smoothening the execution of their business / community processes that ultimately goal towards better customer / user base retention and new base build up.
IT Departments of businesses and / or IT Services companies, typically, serve as host to this ambition pack and ensure that the ambition is executed well and the system is in place, as desired, on time and with the acceptable quality and supported thereafter.
One of the biggest challenges in becoming a host, as in the context above, is that the picture in the heads of business masters needs to be clearly copied to the heads of IT people and most of us will agree that this is not easy, if, not impossible.
We definitely are not the first ones who are trying to research the area. In fact, we have giant standards existing to address this challenge, for e.g., UML Use Cases and other diagrams. We wanted to device a means that enables us to not only capture requirements but also allows auto system size count early in the lifecycle and with such refinement capabilities that when system reaches final implementations stages, the size count also becomes stable and precise.
We examined Use Case Points Analysis method of counting software size and found it good enough to provide early estimates. It lacked in refinement of counts with maturing system. On the other hand, Function Points Analysis is not only suited for early estimates but also for when systems are in production. It gives, thus far, the best view about the software size at any stage and when counted using standard methods as suggested by IFPUG, count is consistent irrespective of who counted it.
Another limitation we felt with Use Case way of requirements capture is that it is away from how the world really exists. Some of you who have studied data structures in deep would realize that they are the derived patterns from how the things are structured around you in the real world. One such structure is “Tree” Structure. In our opinion, it is the super structure of all structures and encapsulates all of the others. A Collection (all its forms) can be considered as siblings under same parent, Stack can be one of the routes taken from a leaf to super parent and Queue is reverse of that and so on.
Our basic claim is that this world exists as a Tree structure when seen from a very high level. For eg, World contains Countries, Countries contain Cities, Cities house businesses, Businesses have departments, Departments have Sub Departments, People and Processes. People also exist in hierarchy in any business and hierarchy is basically a tree structure. The parents and their children in this tree structure constantly generate and consume events at various levels which might lead to change of structure and / or consumption or creation of Resources (Time, Money, People, Material & Information) as part of a process trigger. The tree structure together with event generation and consumption capability brings dynamics in the system.
Since all of this exist as Tree structure and so (a big SO), the ideal way of capturing requirements should also be as a tree structure with parallel provision of event route capture as well. This structure is what is missing today with Use Case way of requirements capture.
To sum up our objectives, we wanted to be able to capture requirements in a tree structure form along with the underlying dynamics such that it also facilitates automatic software sizing, starting from initial phases in development lifecycle down up to when the system is implemented and comes under support.
Let us now discuss above with an example. Assume a simple retail process involving a customer buying a product, paying for it and going out of the store. Following is the picture that gets painted in the mind.
1) Customer comes in the store.
2) Walks to the gallery where goods are at display with the shopping cart.
3) Picks up items and moves to billing
4) Cashier bills and Customer pays.
5) Customer moves out of the store.
6) Billing has triggered inventory update behind the scenes and it was found that replenishment was needed for one of the products
7) A message was sent to the warehouse where extra supply is maintained.
8) Warehouse sends replenishment to the store.
This whole perspective can “so beautifully” be captured as a Tree structure, as follows
World
Store (Premise)
Actors
Customer (Actor)
Cashier (Actor)
Resources
Material
Goods
Processes
Shopping cart fill up (Excluded as it has no IT touch point being a manual process.)
Billing
Triggered By
Customer
Cashier
Impacts
Goods (Decrease)
Generates Event
Replenishment Needed (Event)
Warehouse (Premise)
Processes
Replenishment
Triggered By
Replenishment Needed (Event)
Impacts
Material
Store.Goods (Increase)
Please note that the events are bringing dynamics to the system and can so beautifully be captured along with the tree. We feel that the capture of requirements / business perspective in this way can convey the pictures more clearly between business and IT minds.
In the future releases, we will enhance RCL to capture business flow within each process node and then the finer details will be captured along with this flow. It will include capture of screen navigation and logical data model as well. Currently, we have a corresponding single screen where we can submit complexity of business process details but flow capture is not possible with this release.
Another beauty of having this structure is that it allows you to apply Function Point counting techniques to arrive at software size at higher level and also enables to drill down to an extent that even the finer details are possible to be filled in thus enabling more precise capture of information required to calculate stable Function Points count towards end of system implementation.
When we count Function Points, we basically count External Inputs, External Outputs and Queries made by each process and the logical data model (external and internal) accessed by the process execution.
When requirements are captured as RCL, we repeat following for each process present in the Tree in order to capture Function Point elements corresponding to each process and then sum up at the end.
1) Each process can be triggered by following and thus qualify for being External Inputs to that process
a. Events
b. Actors
c. Another Process
2) Each process can do following as a result of its execution and it qualifies to become External Outputs by that process
a. Trigger other processes
b. Generate Events
3) Following can be queried per process.
a. Each actor that triggered the process can be queried within the process
b. Each event can be used within the process to save the event information or query at least one other resource or actor entity within the Premise with reference to the event data brought in by the event.
c. Resources impacted by the process.
4) Logical Data Model (Internal) is formed by
a. Actor Entities that Trigger the process
b. Events that trigger the process. There could be files where event data is stored as they arrive.
c. Resource Entities impacted by the process.
d. Premise entity where the process is running. (A process can be made to span across multiple premises by using Multi Housing capabilities of our RCL tool.)
5) Logical Data Model (External) is formed by the same set as above but the Events, Actors and Resources used to determine external model would be shown directly within the world and not within any premise, per se. An example of the process that gets triggered by external events is “Asset Allocation Process” within a bank based on the external Equity, Bond and Foreign exchange prices / rates. It can be shown as
World
Events
Bond Yield Change (External Event)
Equity Pricing Change (External Event)
Foreign Exchange Rate Change (External Event)
Bank (Premise)
Processes
Asset Allocation
Triggered By
Bond Yield Change
Equity Pricing Change
Foreign Exchange Rate Change
Note that external events shown above are not housed within any premise. They are directly shown below world.
The RCL tool we have published at the link below facilitates capture of the requirement tree structure as described above and once the capture is over (with finer details fill up), user can click the “Estimate” button to check Person Days estimation figure. User may optionally hit “See RCL as FP” button to check the dissection of RCL elements as Function Points.
http://www.econcinnity.com/eConcinnity/faces/work/estimation/rcl/RequirementsCapture.jsp
Way forward, we will make RCL capable enough to not only capture the high level requirements but also the business process flows (for each process node), screen navigations, logical data model, other design elements corresponding to each process, and hopefully the test cases and execution results etc, thus, facilitating full traceability capture as the lifecycle progresses. Finer details will then be derived out of this capture. We will also enable it to be used by business and IT groups at the same time and grow different portions of the Tree, together. Requirement Review workflow features will also be enabled. It will definitely take time and will evolve over a period of time.
But, before we develop this further, a large portion of the community would need to show agreement to the basic premise that the requirements are best captured as a tree structure.
Please send in your valuable comments at feedback@econcinnity.com with the subject “RCL - Conceptual Discussion” and contribute your ideas to grow the concept.
Please see a somewhat detailed RCL Tutorial, here.
Comments
No comments yet.
