Finishing off my Row 2 artifacts, one thing that came out was that list of 40 to 50 candidate Use Cases. For my business audience, I have started calling them System Use Cases, so there was no ambiguity; these are the required ways to be able to use a solution/system. So, I think I have decided that these are row 3 artifacts, but they also remain in the People/Who column.
Having this list leads to my first cross-reference matrix, ‘User Role’ to ‘System Use Case’; this will be very handy in illustrating who can do what, and just as importantly, who can’t do what.
I am also finding it useful to xref the System Use Cases to the lowest levels of the Functional Decomposition, as mentioned and discussed in my earlier post. I am not sure yet what else the decomposition brings to the overall requirements; certainly many past methodologies used decompositions to get to the lowest level definition of functionality, and after that the higher levels were not used any further in the Requirements.
Another small but illustrative cross-reference is “User Role” to “Location”; from this, one can derive what System Use Cases would be performed at a Location. This is going to help going forward as it is already expected that the new system will be used at more locations than the current systems. This may also include defining some new User Roles as well, which will then drive the questions: “Which System Use Cases will this new User Role need to use? Do they need new System Use Cases?”
For my own satisfaction, I also worked out the classic “Data Entity” cross-referenced to “Function” (Use Case, really), and then manually performed Affinity Analysis to see if any different ‘subject areas’ were revealed. Since the business scope is really about one major entity, a Credit Application, the analysis essentially confirmed that. However, it also organized the functions around the its dependent entity types as well, so one can see how these groupings could possibly lead to de-coupled definitions of sub-systems or components… but that’s for the Developer/Architect to surmise!
And so… that is pretty much where I stopped in creating draft requirement artifacts before heading into requirements sessions with the business. Overlapping with the beginning of those sessions, I did consider what other Row 3 artifacts still might come into play in creating an overall requirements definition.
My current thoughts on Row 3 have been greatly influenced by having recently read “Requirements Analysis: From Business Views to Architecture”, by David C. Hay (Prentice-Hall, 2003). This book does two main things (and some others, too) that helped me:A) It reviewed that past 50 years or so of methodologies and artifacts, and categorizes the artifacts by Zachman Cell; even without that categorization, this is a great piece of IS history that I have seen nowhere else, thank-you Mr. Hay.B) It re-focuses Row 3 from the Designer View to the Architect’s view, and within that classifies Row 2 artifacts as ‘Divergent Models’ and Row 3 artifacts as ‘Convergent Models’, which I found powerful.
The best example of (B) is in the Data Column: your Row 2 model may have entities for Customers, Suppliers, Staff, and the like. Given that, your Row 3 model would be based on a Party/Relationship Model, where all the participants in the business (and new ones when they are defined) are supported by one common, flexible data model, and the data structures you would create from that model. Some call these meta-models, but I avoid the term with business people for the most part. So, the other columns may also have such convergent artifacts, such as Workflow models for the Function column, and Business Rule Models for the Motivation column.
I have still been working on these Row 3 artifacts as I have also been gathering mainly Row 2 level information during Requirements sessions with the business. So, my next blog entries on this will be about what happened in those sessions. It might be a while before I get to posting those, but they will come…