Many studies have cited the often imprecise and ambiguous nature of business requirements as a major factor contributing to the high costs and low success rates in system development efforts.
It’s easy for narrative descriptions of business processes to be imprecise and ambiguous, and business requirements documents usually focus on business processes. Data requirements, often an
afterthought, are usually relegated to an appendix.
But data is, after all, the only thing that any information system can process. And it’s much easier to be precise when describing data than when describing business processes. So if we could
somehow define business requirements entirely in terms of data and terms related to data, we might be able to make them more precise and unambiguous.
When viewed in relation to data, the types of functions performed by an information system are quite finite. They include Set Operations (creating, retrieving, updating and deleting one or more
instances), Variable Operations (calculations), and Preconditions (necessary or sufficient). Concentrating first and foremost on data requirements and subsequently on what Operations and
Preconditions are required related to what data can yield highly-structured, precise and unambiguous requirements documentation.
Certain prerequisites must be met in order to arrive at this level of precision. All requirements for data, operations and conditions must be integrated in a single physical or virtual location.
Each requirement must be distinctly identified and classified according to a meaningful scheme (i.e. metamodel), down to a very detailed level. In addition, all relationships between
requirements must also be explicitly identified and classified according to a meaningful scheme. The precision resulting from meeting these prerequisites enables accurate dependency analysis
and a clear understanding of the potential impact of adding, removing or rearranging any part of any requirement.
A metamodel that defines such classification schemes for requirements and their relationships is the foundation of Data-Driven Application Engineering (DDAE). This article will show a
bill-of-materials, or tree, view of some example contents of this metamodel. The examples are taken from a prototype DDAE tool implemented in a Microsoft Access database. The screen shots included
here are from an Access Form incorporating a treeview control.
Since the reader may already be familiar with data models, we’ll begin our walkthrough by looking at an application data model presented as a bill of materials, or tree. We’ve named our
example application DMDD Corp. Data Entry. We begin (as all good requirements documentation should) by defining our data model.
A high-level view of this simple data model is shown in Figure 1 below.
Figure 1
Since this representation of a data model is a bit different from an entity-relationship diagram, some explanation may be in order. The entities in this simple application are Order, Customer, Product and Order_Line. Each entity – every requirement instance, in fact – has an identification number that is unique across all requirements.
In this display, this number is appended to the requirement name. Some of the reasons for this will become clear later on.
Notice that in this data model view, three of the entities have plus symbols to their left, indicating that these nodes can be expanded. Order_Line does not, and
we’ll see why in a minute.
Figure 2 drills down into the first three entities. We see that each includes several attributes, and that Order also has two “child” entities, Order_Line and
Payment.
Figure 2
Figure 3 further expands Order_Line to show that it includes four base (non-derivable) attributes: Order_Line_identifier, Order_line_product_identifier,
Order_line_order_identifier and Order_line_units_count.
Figure 3
So far this is fairly typical of what a data model attempts to portray. (Important properties such as text definitions, domains, primary key designations, etc., are not shown, but trust me,
they’re in there.)
The main point here is to demonstrate a bill of materials representation not just for a data model, but to show how DDAE represents requirements as extensions to a data model. We’re going to
leave the familiar world of data models at this point and switch to a different view, shown in Figure 4 below. At the highest level it looks very similar to the tree-view data model we’ve
already looked at. The only difference at this level is that, in addition to the application and entity names, we display meta-relationship types explicitly as nodes in the tree. Meta-relationships
are distinguished by being enclosed in parentheses: (Scope), for example. The reasons for this will become clearer as we move along.
Figure 4
This view shows the operations related to the entities in our requirements model. First we’ll expand the Order_Line entity to see what operations are
required for it. In Figure 5 below, we can see two Set Operations for Order_Line: Create_Order_Line and Retrieve_Order_Line.
We’ll no doubt eventually need to define at least Update_Order_Line and Delete_Order_Line also.
Figure 5
When we drill down into the Set Operation Create_Order_Line in Figure 6 below, we can see that it has SetVarOper relationships
with four Variable Operations, each of which is an assignment (=) operation for one of the persistent attributes of Order_Line_62.
Figure 6
If we expand each assignment operation (see Figure 7), we see that each operation has DepVar and IndVar relationships with the
same data element, which define the two different roles played by the data element in the operation. DepVar signifies a dependent, or output, variable and
IndVar signifies an independent, or input, variable.
Figure 7
Figure 7 shows that Create_Order_Line assigns values only to the base attributes of Order_Line that were shown in Figure 3. Looking at Figure 8, we may begin to
get the idea that Retrieve_Order_Line may be a little more complicated.
Figure 8
Figure 8 shows that Retrieve_Order_Line includes no fewer than seven SetVarOper relationships. Figure 9 expands the last four
of these, which show assignment operations basically identical to those within Create_Order_Line, that is, simple assignments of values to base data elements.
Figure 9
The first three SetVarOpers, however, relate to variable operations that are a little more interesting than basic assignments–they are derivations. Figure 10
expands the first of these, named equals_multiply_107:
Figure 10
As you might guess, equals_multiply_107 is a multiplication variable operation. (The operator type * is actually a property of the variable operation, which is
not shown in this view, but could easily be exposed by mouse-over or click.) The value of the (output) dependent variable Order_line_net_amount is derived by
multiplying (input) independent variable Order_line_units_count by (input) expression element Product_unit_price_amount.
Figure 11 expands the branches of equals_multiply_107 where the preconditions on this variable operation are defined. The condition designated is =_173 is the single necessary and sufficient precondition to the operation. The multiplication operation is valid if and when Order_line_product_identifier_73 is equal to Product_identifier_71.
Figure 11
If we focus back on the most fundamental data requirements – data elements – notice that all nodes are data elements, and data elements are always nodes. Data element nodes will enable
us to understand data dependencies (and subsequently interfaces) very precisely.
In addition, this bill-of-materials requirements statement can be accurately translated into compilable narrative text, given equally precise platform requirements and rules for transforming
requirements into specifications. Here is one example of compilable narrative text equivalent to the requirements above:
create view order_line_net_amount (Order_line_net_amount)
as
select
order_line_units_count * unit_price_amount as Order_line_net_amount
from
Product, Order_Line
where
Product.product_identifier = Order_Line.order_line_product_identifier
In future articles, we’ll describe in detail the significance of data element nodes, as well as the details of platform requirements and transformation rules, within the context of
Data-Driven Application Engineering.
