Given the time I had to prepare for the Requirements sessions, they actually came and went without any big surprises. I met with different groups of end-users, usually by the Role/Job they performed, and fleshed things out here and there. I also met separately with Management about future changes to the business; that was tougher but the artifacts I had did show the differences that that would be needed in the future (essentially new Roles and more locations).
After that, I did have to reformat everything into declarative Requirement Statements, and re-group them into function, data, technical, and other categories; that's the way the current methodology arranges things when presenting to senior management. So, all the content was there, you just have to be ready to present it in different ways depending on your audience.
...and the audience yesterday was senior management on a steering committee and, six hours later, all was received with approval and appreciation.
As usual, the run-up to this review with senior people was tight, took lots of hours, and IT management had two other analysts come on to help meet the review date. So, there were some long work-days, including while I was down DC, but it was worth it in the end.
Next Up: massaging the Requirements into a standard RFP format and getting it out the main vendor we are dealing with...
David Wright
Member, IIBA
"The waterfall is not too long, the river is too wide."
Friday, November 17, 2006
Wednesday, November 15, 2006
OK, I am back from the Business Rule Forum...
...and as usual, I have lots of notes and material and stuff that I don't know when I will get a chance to sift through. I may have more to say in later posts, but for today:
- Business Process Management working in sync with Business Rules Management was the common topic/theme of the conference
- I did my own presentation on "Integrating Requirements Artifacts" which included BPM and BRM with function and data, etc.; got a good response. Again, if you can manage public speaking, and have something to say, submit something to a conference of interest to you, it is great fun...really...
- lunch and sponsored events where you can meet other attendees and exchange info/stories are just as valuable as the conference sessions
- this was my second year at this Forum, and I like it especially because it attracts a mix of both Business and IT people... and the vendors are there too, of course.
- Washington DC is pleasant this time of year, mild with some rain, leaves still in fall colors; being there on election day added some flavour to the week as well. So, not all conferences have to be in Vegas, Phoenix, or Orlando to merit your attention(!)
That's it for now...dww
- Business Process Management working in sync with Business Rules Management was the common topic/theme of the conference
- I did my own presentation on "Integrating Requirements Artifacts" which included BPM and BRM with function and data, etc.; got a good response. Again, if you can manage public speaking, and have something to say, submit something to a conference of interest to you, it is great fun...really...
- lunch and sponsored events where you can meet other attendees and exchange info/stories are just as valuable as the conference sessions
- this was my second year at this Forum, and I like it especially because it attracts a mix of both Business and IT people... and the vendors are there too, of course.
- Washington DC is pleasant this time of year, mild with some rain, leaves still in fall colors; being there on election day added some flavour to the week as well. So, not all conferences have to be in Vegas, Phoenix, or Orlando to merit your attention(!)
That's it for now...dww
Sunday, November 05, 2006
Practical Use of the Zachman Framework For Organizing Information System Requirements: Part 3 - Matrices
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…
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…
Subscribe to:
Posts (Atom)