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…
Wednesday, October 18, 2006
Practical Use of the Zachman Framework For Organizing Information System Requirements: Part 2 - Business Model
Row 2
The Zachman Framework is notable first for being just that, a framework for different approaches to use to organize their artifacts; further, some writers have customized the framework to rename some of the rows/views. Despite this, Row 2 is still mainly about the Business specifics, be it the Business Model (conceptual view), or the Business Owner’s View. I am going to use the original “Business Model” terminology for Row 2, but may diverge when I get to Row 3…
As I write this part of my article, I have finished using all my source documents to flesh out a Business Model that I can take into requirements sessions with business staff and various subject matter experts. Those will be taking place shortly, so I expect to add to this article after the sessions, to document the experience and analyze for myself how much variance exists between my draft Model and the Model after the sessions.
Let us start with each cell in the row again, but after that, I also have some column-to-column cross-reference matrices that I expect to help me in actual analysis and validation of the Model as a set of Requirements.
Row 2 (Business Model) and Column 1 (Data / “What”):
The scope of this project is a major process of the company, one of five that have been defined. So, what I found is that the 14 things of interest I defined in Row 1 were not Subject Areas with many entities to discover; the business process is mainly concerned with the life-cycle of one core entity type and its dependent entities. At this point, I think I can identify that this core ‘thing’ is a Credit Application without revealing any proprietary information. The rest of the 14 mainly equate to single entity types as well, which fall into the following three categories:
o Entities for data that exists for the process to use but does not maintain, such as Product data,
o Entities for data that are dependent on the Credit Application, like the items/assets being financed (although these may turn out to be independent entities from a wider enterprise perspective),
o and Entities for data that is created by the Process that is used downstream in the business, like contract and account data.
Further, just applying 1st normal form would drive out a few more entity types, but I don’t think this is absolutely necessary in row 2, especially depending on your business audiences comfort level with ER diagrams. The business participants at my company are, as I have described, very comfortable with process flow models from six sigma process improvement efforts, but data models are unknown, and my previous use of them in smaller projects has been met with indifference. As a result, I expect to use an alphabetical list of entity types, with list of attributes for each one, all in business terms; relationships will have to be covered as statements, but business rule formats can help that (see column six).
I do have a lot of attributes already, given the detail in the process maps, current systems, and those previous data models. I have not started to define the attributes yet, many definitions already exist in current systems and glossaries, but I do plan to build a Glossary of Terms for this project in the sessions as needed, especially to document aliases, and resolve different uses of a term.
Row 2 (Business Model) and Column 2 (Function/ ‘How’):
The existing process maps relate to the six ‘boxes’ of the High-Level Process Map almost 1 to 1; however, they are several layers more detailed, each map having 40 to 60 steps, many decision points (diamonds) and dependence on use, and limitations, of existing systems. At this level, process maps are too detailed and too volatile to be useful information system requirements, so I tracked back to the six ‘boxes’ and started a functional decomposition. Groupings of process steps coalesce into more stable functions, and I derived a small functional hierarchy, no deeper than three levels, with about 20 root-level functions. At the same time, some of the process steps look like candidate use cases… or lowest-level CRUD functions.
Here I return to my previous thoughts that Column 2 has the most artifact choices, and I have been looking at process maps, a functional decomposition, and use cases… but looking ahead to column 4, some say that use cases are a Role/User artifact, and maybe they are Row 3(?). Perhaps those are the ‘concrete’ use cases as defined by RUP, but RUP also supports conceptual use cases for analysis of a domain before design. I do expect that I will end up with use cases as part of the Requirements, if only because they are a common artifact that my business users have seen in earlier projects, but at this point in the project it will may actually be a list of use case names and short descriptions; detailing them would come later after selecting the solution approach.
Use Cases can be considered as artifacts that span columns, as they (at least) document roles through Actors, and system activity. Again, the Framework does not dictate artifacts, so it is up to the analyst to categorize artifacts into the framework in the way that works best for capturing the business model, and then communicating the model as well. It is interesting that if one does categorize use cases as column 4 artifacts, I can see how it is useful to cross-reference them back to the root functions of the decomposition in Column 2.
Row 2 (Business Model) and Column 3 (Network / ‘Where’):
This cell is very skimpy at this point for my project. Is it because the ‘network’ is ubiquitous? Maybe, but the one thing one can highlight here is that the various locations communicate in multiple ways that might fall within the scope of an information system to manage.
This starts with good old snail-mail, and its rabbit cousins, the various express couriers. Even in the latter, the recording media is paper, which has not gone away; the ‘computer network’ as most perceive it does not assist with this communication (unless you count checking the status of your delivery at a courier company’s website).
A close parallel is, of course, the fax machine, which has been with us since the 1930’s. Again, a business’s own network requirements will probably still assume the perceivable separate existence of a voice network which can transmit faxes.
(Here’s my tech question of the moment; is anyone using VOIP to send faxes, presumably to take that cost off the long distance bill?)
… but what if paper documents are scanned to create PDF files? That can then be sent by email, or uploaded/downloaded inside a company’s VPN using Portals, and all that? Does that unstructured data file need to be managed by the business’s information system(s)? That’s one question I will be asking in this project, along with older-style imaging and document management. I can see how the requirements emerging from these topics will end up back in column 1, since not all data of interest to the business can be recorded as zeroes and ones.
That leaves email (in general) and voice communications between people at different locations, or within one location as well. I have already seen newer transaction systems being augmented by management of emails related to a transaction, especially in systems where transactions are generated by a field sales force and sent to a head office for completion. As for voice communications, we are all familiar with the phrase “your call may be recorded for training or other purposes”, which will be managed by customer call centre systems. Will recording and management of phone calls move beyond the call centre, and be part of transaction systems? I can’t see why not.
As I move into the requirements sessions with the business for my project at hand, I do already know that fax is still expected to be a primary means of communicating between any and all locations; everyone we do business with, within or beyond arms-length, will accept a fax and has a process for dealing with them when they arrive; that still can’t be said for email even at this state of its maturity.
Row 2 (Business Model) and Column 4 (People/Roles, or ‘Who’):
At this point, I think the Roles I had in Row 1 probably belong in this cell, with an overall Org Chart in the Row 1 cell; or, Use Cases are a Row 2 artifact. I am not overly concerned with the specific Rows, right now, only that I have the Roles that are going to be Actors in Use Cases. Again, maybe a list of candidate Use Cases is something to gather at this level, and they do appear to match to system-related steps in the Process Models.
Row 2 (Business Model) and Column 5 (Time, or ‘When’):
In this cell, I have looked at Entity Type Life-Cycles as the time view on key data. In this process, there is the one major entity type, Credit Application. The basic states are ‘submitted’, followed by ‘approved’ or ‘declined’, with a few other states mixed in for control.
Row 2 (Business Model) and Column 6 (Motivation, or ‘Why’):
As mentioned before, I already have collected a set of company policies, from which I can derive specific Business Rules. It was a this point that I dug out some previous R&D work I did on Business Rules a few years ago, with many of the Rules being related to this project’s business process. Again I am wondering, are the Rules a row 2 or row 3 artifact? I think this will resolve itself as I examine Row 3 completely.
Next, Row 3? Or Cross-Reference Matrices?
Row 3 on the Framework is noted to be a Designer’s view, but I have also seen some writers show Requirements artifacts in Row 3 of some columns, so I expect to look more at Row 3 next time, including the issue if whether Row 3 is simply a translation of Row 2, or if it the move from 2 to 3 involves some transformation as well.
I also have some of those matrices coming along, will have to see how to describe those in blog format…
The Zachman Framework is notable first for being just that, a framework for different approaches to use to organize their artifacts; further, some writers have customized the framework to rename some of the rows/views. Despite this, Row 2 is still mainly about the Business specifics, be it the Business Model (conceptual view), or the Business Owner’s View. I am going to use the original “Business Model” terminology for Row 2, but may diverge when I get to Row 3…
As I write this part of my article, I have finished using all my source documents to flesh out a Business Model that I can take into requirements sessions with business staff and various subject matter experts. Those will be taking place shortly, so I expect to add to this article after the sessions, to document the experience and analyze for myself how much variance exists between my draft Model and the Model after the sessions.
Let us start with each cell in the row again, but after that, I also have some column-to-column cross-reference matrices that I expect to help me in actual analysis and validation of the Model as a set of Requirements.
Row 2 (Business Model) and Column 1 (Data / “What”):
The scope of this project is a major process of the company, one of five that have been defined. So, what I found is that the 14 things of interest I defined in Row 1 were not Subject Areas with many entities to discover; the business process is mainly concerned with the life-cycle of one core entity type and its dependent entities. At this point, I think I can identify that this core ‘thing’ is a Credit Application without revealing any proprietary information. The rest of the 14 mainly equate to single entity types as well, which fall into the following three categories:
o Entities for data that exists for the process to use but does not maintain, such as Product data,
o Entities for data that are dependent on the Credit Application, like the items/assets being financed (although these may turn out to be independent entities from a wider enterprise perspective),
o and Entities for data that is created by the Process that is used downstream in the business, like contract and account data.
Further, just applying 1st normal form would drive out a few more entity types, but I don’t think this is absolutely necessary in row 2, especially depending on your business audiences comfort level with ER diagrams. The business participants at my company are, as I have described, very comfortable with process flow models from six sigma process improvement efforts, but data models are unknown, and my previous use of them in smaller projects has been met with indifference. As a result, I expect to use an alphabetical list of entity types, with list of attributes for each one, all in business terms; relationships will have to be covered as statements, but business rule formats can help that (see column six).
I do have a lot of attributes already, given the detail in the process maps, current systems, and those previous data models. I have not started to define the attributes yet, many definitions already exist in current systems and glossaries, but I do plan to build a Glossary of Terms for this project in the sessions as needed, especially to document aliases, and resolve different uses of a term.
Row 2 (Business Model) and Column 2 (Function/ ‘How’):
The existing process maps relate to the six ‘boxes’ of the High-Level Process Map almost 1 to 1; however, they are several layers more detailed, each map having 40 to 60 steps, many decision points (diamonds) and dependence on use, and limitations, of existing systems. At this level, process maps are too detailed and too volatile to be useful information system requirements, so I tracked back to the six ‘boxes’ and started a functional decomposition. Groupings of process steps coalesce into more stable functions, and I derived a small functional hierarchy, no deeper than three levels, with about 20 root-level functions. At the same time, some of the process steps look like candidate use cases… or lowest-level CRUD functions.
Here I return to my previous thoughts that Column 2 has the most artifact choices, and I have been looking at process maps, a functional decomposition, and use cases… but looking ahead to column 4, some say that use cases are a Role/User artifact, and maybe they are Row 3(?). Perhaps those are the ‘concrete’ use cases as defined by RUP, but RUP also supports conceptual use cases for analysis of a domain before design. I do expect that I will end up with use cases as part of the Requirements, if only because they are a common artifact that my business users have seen in earlier projects, but at this point in the project it will may actually be a list of use case names and short descriptions; detailing them would come later after selecting the solution approach.
Use Cases can be considered as artifacts that span columns, as they (at least) document roles through Actors, and system activity. Again, the Framework does not dictate artifacts, so it is up to the analyst to categorize artifacts into the framework in the way that works best for capturing the business model, and then communicating the model as well. It is interesting that if one does categorize use cases as column 4 artifacts, I can see how it is useful to cross-reference them back to the root functions of the decomposition in Column 2.
Row 2 (Business Model) and Column 3 (Network / ‘Where’):
This cell is very skimpy at this point for my project. Is it because the ‘network’ is ubiquitous? Maybe, but the one thing one can highlight here is that the various locations communicate in multiple ways that might fall within the scope of an information system to manage.
This starts with good old snail-mail, and its rabbit cousins, the various express couriers. Even in the latter, the recording media is paper, which has not gone away; the ‘computer network’ as most perceive it does not assist with this communication (unless you count checking the status of your delivery at a courier company’s website).
A close parallel is, of course, the fax machine, which has been with us since the 1930’s. Again, a business’s own network requirements will probably still assume the perceivable separate existence of a voice network which can transmit faxes.
(Here’s my tech question of the moment; is anyone using VOIP to send faxes, presumably to take that cost off the long distance bill?)
… but what if paper documents are scanned to create PDF files? That can then be sent by email, or uploaded/downloaded inside a company’s VPN using Portals, and all that? Does that unstructured data file need to be managed by the business’s information system(s)? That’s one question I will be asking in this project, along with older-style imaging and document management. I can see how the requirements emerging from these topics will end up back in column 1, since not all data of interest to the business can be recorded as zeroes and ones.
That leaves email (in general) and voice communications between people at different locations, or within one location as well. I have already seen newer transaction systems being augmented by management of emails related to a transaction, especially in systems where transactions are generated by a field sales force and sent to a head office for completion. As for voice communications, we are all familiar with the phrase “your call may be recorded for training or other purposes”, which will be managed by customer call centre systems. Will recording and management of phone calls move beyond the call centre, and be part of transaction systems? I can’t see why not.
As I move into the requirements sessions with the business for my project at hand, I do already know that fax is still expected to be a primary means of communicating between any and all locations; everyone we do business with, within or beyond arms-length, will accept a fax and has a process for dealing with them when they arrive; that still can’t be said for email even at this state of its maturity.
Row 2 (Business Model) and Column 4 (People/Roles, or ‘Who’):
At this point, I think the Roles I had in Row 1 probably belong in this cell, with an overall Org Chart in the Row 1 cell; or, Use Cases are a Row 2 artifact. I am not overly concerned with the specific Rows, right now, only that I have the Roles that are going to be Actors in Use Cases. Again, maybe a list of candidate Use Cases is something to gather at this level, and they do appear to match to system-related steps in the Process Models.
Row 2 (Business Model) and Column 5 (Time, or ‘When’):
In this cell, I have looked at Entity Type Life-Cycles as the time view on key data. In this process, there is the one major entity type, Credit Application. The basic states are ‘submitted’, followed by ‘approved’ or ‘declined’, with a few other states mixed in for control.
Row 2 (Business Model) and Column 6 (Motivation, or ‘Why’):
As mentioned before, I already have collected a set of company policies, from which I can derive specific Business Rules. It was a this point that I dug out some previous R&D work I did on Business Rules a few years ago, with many of the Rules being related to this project’s business process. Again I am wondering, are the Rules a row 2 or row 3 artifact? I think this will resolve itself as I examine Row 3 completely.
Next, Row 3? Or Cross-Reference Matrices?
Row 3 on the Framework is noted to be a Designer’s view, but I have also seen some writers show Requirements artifacts in Row 3 of some columns, so I expect to look more at Row 3 next time, including the issue if whether Row 3 is simply a translation of Row 2, or if it the move from 2 to 3 involves some transformation as well.
I also have some of those matrices coming along, will have to see how to describe those in blog format…
Saturday, September 16, 2006
Practical Use of the Zachman Framework For Organizing Information System Requirements ... Part 1 - Scope (cont.)
...continuing from previous post.
That is just how I started, either gathering or copying existing content as needed. My main source was the Six Sigma process models, which in themselves can be a row a Two Process Artifact. They also typically show Roles, Items of Interest, Inputs , Deliverables and more, so populating the other columns can be started from these maps.
So, lets begin with…
Row 1 (Scope) and Column 1 (Data, although some writers prefer ‘What”)
I now have a ‘List of Things that are Important to the Enterprise.” It contains 14 items which, as expected contain items such as Customers and Products, and other things more specific to the in-scope process of the Enterprise. A data modeler would certainly look at this list and suggest they are all major Subject Areas of the Business, from which data models may be detailed. (I am going to be purposely vague about the specifics of the process, as I in no way wish to describe proprietary and private aspects of the company.)
Row 1 (Scope) and Column 2 (Function, or generalized to ‘Activity’, along with ‘How’ to align with ‘What’ above ):
This cell, and the rest below it in this column, are prime examples of one of the main concepts of the Zachman Framework; it organizes your artifacts by resource and perspective, but does not dictate the artifacts to use. Back in Column 1, the ER Data Model is pretty much the default, irrespective of some people still trying to use UML for persistent data requirements. Here in Column 2, there is some variety of choice, so you have to choose an artifact. A company may already have a standard, usually within a Methodology. I am finding you may need more than one to capture all aspects of ‘Activity’.
For my Feasibility Study, I have located a high-level Process Map that was used in a similar project in another country (my employer is a unit of a multi-national). It is six sequential boxes. In that sense, the boxes could also be the first level of a Functional Decomposition, so I have not decided yet which kind of artifact it is(!). In any case, the existing detail Process Maps can be cross-referenced fairly directly to these boxes/ functions, which will help greatly in subsequent rows.
Further, I have indications at this point that the Business Process Scope includes or interacts with Processes located at other sites or performed by other parties, e.g. the manufacturer of items being serviced by my company’s business process, and retailers of the items being serviced as well. Some half-dozen low level steps performed by these parties are shown the Process Maps, so I am listing these as other Row 1 functions, at least to start.
Row 1 (Scope) and Column 3 (Network, or ‘Where’):
The first and main location is the head office for the unit providing the service. As mentioned, other locations will include one (maybe two) locations for the product manufacturer, and many retailer locations (100+) as well.
The other interesting location of note is ‘mobile’. My unit has a sales team that is organized by geographic regions, where those team members are located and spend a lot of time visiting retailers, so they need to be able to carry out their functions from wherever they happen to be at a point in time. Yes, using the Web to connect our ‘traveling sales mean and women’ is pretty much a given, but treating ‘mobile’ as a location at the scope level illustrates its importance.
Sidebar: As far as I know, I don’t have to deal with physical locations that move; I worked with an insurance data model once that allowed P&C companies to insure buildings on the Arctic ice-pack, which moves about(!).
Row 1 (Scope) and Column 4 (People, or ‘Who’):
This column does not have any commonly used artifacts beyond the ubiquitous Org Chart. I do think its good to have the latest one on hand when you start, knowing that it will change, and that it will not really be used as you model your business in the way needed to support Information System Requirements; but you do need to know the names and titles of the people impacted by the Information System(s) that will eventually be delivered.
For this project, I am populating this cell with about a dozen different Roles played by various employees and other participants in the Process. I picked these up right from the swim-lanes of those detailed Process Maps mentioned back at the beginning of this article. One thing of note is that Role ‘names’ don’t match to current job titles, but past experience has shown that titles come and go, but basic Roles remain.
Row 1 (Scope) and Column 5 (Time, or ‘When’):
I am using this cell to list the major external Events that the in-scope Business Process must recognize and respond to. Again, the detailed Process Maps are the source for these Events, and there are actually only two. Each one fires process executions of some length, with a lot of internal events or hand-offs, but I am not concerned with the latter at this level.
Row 1 (Scope) and Column 6 (Motivation, or ‘Why’):
I am looking forward to driving down this column to the detailed Business Rules, but at this level, I have gathered already well-documented motivational items: Company Core Values, the Mission Statement, and Strategic Goals. I have also already gathered the appropriate company policies for row 2, but more on that later.
So, that’s what I have for Row 1 at this time, based on existing available documentation. When the project starts officially, the first thing to do will be to review these definitions of scope with the Business participants, and have them confirmed or adjusted as needed.
I am also well into creating Row 2 artifacts based on the available documentation, so I will write about those in future posts...
That is just how I started, either gathering or copying existing content as needed. My main source was the Six Sigma process models, which in themselves can be a row a Two Process Artifact. They also typically show Roles, Items of Interest, Inputs , Deliverables and more, so populating the other columns can be started from these maps.
So, lets begin with…
Row 1 (Scope) and Column 1 (Data, although some writers prefer ‘What”)
I now have a ‘List of Things that are Important to the Enterprise.” It contains 14 items which, as expected contain items such as Customers and Products, and other things more specific to the in-scope process of the Enterprise. A data modeler would certainly look at this list and suggest they are all major Subject Areas of the Business, from which data models may be detailed. (I am going to be purposely vague about the specifics of the process, as I in no way wish to describe proprietary and private aspects of the company.)
Row 1 (Scope) and Column 2 (Function, or generalized to ‘Activity’, along with ‘How’ to align with ‘What’ above ):
This cell, and the rest below it in this column, are prime examples of one of the main concepts of the Zachman Framework; it organizes your artifacts by resource and perspective, but does not dictate the artifacts to use. Back in Column 1, the ER Data Model is pretty much the default, irrespective of some people still trying to use UML for persistent data requirements. Here in Column 2, there is some variety of choice, so you have to choose an artifact. A company may already have a standard, usually within a Methodology. I am finding you may need more than one to capture all aspects of ‘Activity’.
For my Feasibility Study, I have located a high-level Process Map that was used in a similar project in another country (my employer is a unit of a multi-national). It is six sequential boxes. In that sense, the boxes could also be the first level of a Functional Decomposition, so I have not decided yet which kind of artifact it is(!). In any case, the existing detail Process Maps can be cross-referenced fairly directly to these boxes/ functions, which will help greatly in subsequent rows.
Further, I have indications at this point that the Business Process Scope includes or interacts with Processes located at other sites or performed by other parties, e.g. the manufacturer of items being serviced by my company’s business process, and retailers of the items being serviced as well. Some half-dozen low level steps performed by these parties are shown the Process Maps, so I am listing these as other Row 1 functions, at least to start.
Row 1 (Scope) and Column 3 (Network, or ‘Where’):
The first and main location is the head office for the unit providing the service. As mentioned, other locations will include one (maybe two) locations for the product manufacturer, and many retailer locations (100+) as well.
The other interesting location of note is ‘mobile’. My unit has a sales team that is organized by geographic regions, where those team members are located and spend a lot of time visiting retailers, so they need to be able to carry out their functions from wherever they happen to be at a point in time. Yes, using the Web to connect our ‘traveling sales mean and women’ is pretty much a given, but treating ‘mobile’ as a location at the scope level illustrates its importance.
Sidebar: As far as I know, I don’t have to deal with physical locations that move; I worked with an insurance data model once that allowed P&C companies to insure buildings on the Arctic ice-pack, which moves about(!).
Row 1 (Scope) and Column 4 (People, or ‘Who’):
This column does not have any commonly used artifacts beyond the ubiquitous Org Chart. I do think its good to have the latest one on hand when you start, knowing that it will change, and that it will not really be used as you model your business in the way needed to support Information System Requirements; but you do need to know the names and titles of the people impacted by the Information System(s) that will eventually be delivered.
For this project, I am populating this cell with about a dozen different Roles played by various employees and other participants in the Process. I picked these up right from the swim-lanes of those detailed Process Maps mentioned back at the beginning of this article. One thing of note is that Role ‘names’ don’t match to current job titles, but past experience has shown that titles come and go, but basic Roles remain.
Row 1 (Scope) and Column 5 (Time, or ‘When’):
I am using this cell to list the major external Events that the in-scope Business Process must recognize and respond to. Again, the detailed Process Maps are the source for these Events, and there are actually only two. Each one fires process executions of some length, with a lot of internal events or hand-offs, but I am not concerned with the latter at this level.
Row 1 (Scope) and Column 6 (Motivation, or ‘Why’):
I am looking forward to driving down this column to the detailed Business Rules, but at this level, I have gathered already well-documented motivational items: Company Core Values, the Mission Statement, and Strategic Goals. I have also already gathered the appropriate company policies for row 2, but more on that later.
So, that’s what I have for Row 1 at this time, based on existing available documentation. When the project starts officially, the first thing to do will be to review these definitions of scope with the Business participants, and have them confirmed or adjusted as needed.
I am also well into creating Row 2 artifacts based on the available documentation, so I will write about those in future posts...
Saturday, September 09, 2006
Practical Use of the Zachman Framework For Organizing Information System Requirements ... Part 1 - Scope
I am doing some pre-project gathering of Requirements for an upcoming Feasibility Study to implement a new systems solution for my employer’s main process for delivery of its services to its customers. The scope and options of this study were drafted, debated and changed, until they basically aligned with my favourite phrase:
“Re-Use before Buy, Buy before Build, Build for Re-Use.”
Some even earlier pre-work to the Study has already identified several alternatives across the Re-Use and Buy options, so the study will evaluate two most ‘popular’ alternatives in order to select one as the recommended solution approach. It is possible, though not probable, that neither of these two alternatives will be recommended, after which we will move on to other identified alternatives.
So, here is what I have in terms of existing documentation to help me draft some Requirements before working with the business;(I hate a blank page as a starting point):
… Detailed Process Maps of the Business Process created by Process Pros in Six Sigma improvement projects.
… documentation on current systems (implemented before I joined the company), and my own experience on a couple of fix and enhancement projects on those systems.
… as an application, the main current system is somewhat unwieldy; I have been told it was developed based on an even earlier system without much user involvement, and was implemented before it was finished, not a great start.
… on the other hand the data model and physical database used by the application is very good, pretty much in 3NF that I can see; it was developed separately from the application, and the application is worse off because of this.; but the detail data requirements that will eventually be needed will be able to draw much from the current model and database, but this will be after the Feasibility Study.
The Feasibility Study will define high-level requirements, considered sufficient to evaluate alternatives. I have often seen such High-Level Requirements delivered as pages and pages of Requirement Statements: “the System/Solution must (do something, store something, etc.)”. The quality of a group of such statement can be very high, but the volume makes them hard to manage.
As a result I am going to use the Zachman Framework (www.zifa.com) as way of , having gathered Requirements in some form, to document them using various models/artifacts, and organize them by the rows/columns (“cells”) of the Framework. I have yet to decide if I will eventually extract a list of Requirement Statements from the artifacts, but it is quite possible I may need to so in order that a wide audience can review the Requirements without having to understand ER Models, for instance.
From a Business Analysts’ perspective, we are talking mainly about Row 2 for Requirements artifacts, what David C. Hay calls the Business Owner Viewpoint. However, if Row 1 (Scope) artifacts don’t yet exist for the business domain to be analyzed, it is best to create them for reference; the Row 1 content may already exist in various places and forms, but gathering and documenting in Row 1 is a good place to start the requirements activities for a project.
That is just how I started, to be continued...
“Re-Use before Buy, Buy before Build, Build for Re-Use.”
Some even earlier pre-work to the Study has already identified several alternatives across the Re-Use and Buy options, so the study will evaluate two most ‘popular’ alternatives in order to select one as the recommended solution approach. It is possible, though not probable, that neither of these two alternatives will be recommended, after which we will move on to other identified alternatives.
So, here is what I have in terms of existing documentation to help me draft some Requirements before working with the business;(I hate a blank page as a starting point):
… Detailed Process Maps of the Business Process created by Process Pros in Six Sigma improvement projects.
… documentation on current systems (implemented before I joined the company), and my own experience on a couple of fix and enhancement projects on those systems.
… as an application, the main current system is somewhat unwieldy; I have been told it was developed based on an even earlier system without much user involvement, and was implemented before it was finished, not a great start.
… on the other hand the data model and physical database used by the application is very good, pretty much in 3NF that I can see; it was developed separately from the application, and the application is worse off because of this.; but the detail data requirements that will eventually be needed will be able to draw much from the current model and database, but this will be after the Feasibility Study.
The Feasibility Study will define high-level requirements, considered sufficient to evaluate alternatives. I have often seen such High-Level Requirements delivered as pages and pages of Requirement Statements: “the System/Solution must (do something, store something, etc.)”. The quality of a group of such statement can be very high, but the volume makes them hard to manage.
As a result I am going to use the Zachman Framework (www.zifa.com) as way of , having gathered Requirements in some form, to document them using various models/artifacts, and organize them by the rows/columns (“cells”) of the Framework. I have yet to decide if I will eventually extract a list of Requirement Statements from the artifacts, but it is quite possible I may need to so in order that a wide audience can review the Requirements without having to understand ER Models, for instance.
From a Business Analysts’ perspective, we are talking mainly about Row 2 for Requirements artifacts, what David C. Hay calls the Business Owner Viewpoint. However, if Row 1 (Scope) artifacts don’t yet exist for the business domain to be analyzed, it is best to create them for reference; the Row 1 content may already exist in various places and forms, but gathering and documenting in Row 1 is a good place to start the requirements activities for a project.
That is just how I started, to be continued...
Thursday, August 31, 2006
I start some vacation today...and boy, do I need it.
Has anyone ever distributed a Requirements document/deliverable to a team to get feedback (or prepare for a walkthrough), and have the main business user instead send back an edited version of the document with the changes they want, and then demand that it be the version reviewed by the rest of the team, or then flatly state that their version is the final version to be created, and signoff their own version?
I know that's a long question, but it reflects my exasperation with recent experience. I don't want to say more publicly at this point, but I have privately written a description of this experience, mainly so I could get it out of my head and move on. Its a fine piece of writing, IMHO, and I may share some of it at a better time, allowing for some distance first.
In the meantime, does anyone have any similar 'war stories' that they want to share? I have only one from the past, as follows:
In 20 years of Requirements work, I have only ever had one ‘User from Hell’, an underwriter at an insurance company where I worked 10 years ago. While gathering CRM requirements with 3 business people, using multiple day-long sessions, this person complained/whined about why this needed to be done, and would not accept questions about the business; she just wanted us to blindly accept her input as the Requirements. I eventually turned her attitude around on this, to the point where she was presenting/defending the Requirements to other people outside the Project. However, when a new phase started for which requirements were needed, she now thought she could do all the Requirements and documenting herself, and would not meet with me at all;. I escalated this to the joint Project Managers, one IT and one Business (which actually worked well...) and they decided that since the underwriter was a long-time employee and well-known for being stubborn, they would let her go ahead while I started work on another phase that did not involve this person. Well, the results were not good, and I had to re-work everything in time to meet the target date. At this point, the underwriter was just mainly silent but did answer questions when I had them. I didn't know whether she had grudgingly accepted the situation, or would suddenly 'go postal' on us.
Anyway, I had already been looking for another job for totally un-related reasons, and left soon after this all happened. The project was slotted to go on for another couple of years, but within a year, the company was taken over and absorbed by one of the really big insurance companies, so I don't know what happened after that. Underwriters are always in demand, so I know that my 'user from hell' probably survived it all or moved on as well.
OK, now its your turn.
I know that's a long question, but it reflects my exasperation with recent experience. I don't want to say more publicly at this point, but I have privately written a description of this experience, mainly so I could get it out of my head and move on. Its a fine piece of writing, IMHO, and I may share some of it at a better time, allowing for some distance first.
In the meantime, does anyone have any similar 'war stories' that they want to share? I have only one from the past, as follows:
In 20 years of Requirements work, I have only ever had one ‘User from Hell’, an underwriter at an insurance company where I worked 10 years ago. While gathering CRM requirements with 3 business people, using multiple day-long sessions, this person complained/whined about why this needed to be done, and would not accept questions about the business; she just wanted us to blindly accept her input as the Requirements. I eventually turned her attitude around on this, to the point where she was presenting/defending the Requirements to other people outside the Project. However, when a new phase started for which requirements were needed, she now thought she could do all the Requirements and documenting herself, and would not meet with me at all;. I escalated this to the joint Project Managers, one IT and one Business (which actually worked well...) and they decided that since the underwriter was a long-time employee and well-known for being stubborn, they would let her go ahead while I started work on another phase that did not involve this person. Well, the results were not good, and I had to re-work everything in time to meet the target date. At this point, the underwriter was just mainly silent but did answer questions when I had them. I didn't know whether she had grudgingly accepted the situation, or would suddenly 'go postal' on us.
Anyway, I had already been looking for another job for totally un-related reasons, and left soon after this all happened. The project was slotted to go on for another couple of years, but within a year, the company was taken over and absorbed by one of the really big insurance companies, so I don't know what happened after that. Underwriters are always in demand, so I know that my 'user from hell' probably survived it all or moved on as well.
OK, now its your turn.
Thursday, August 24, 2006
Free membership at Requirements Networking Group
Was just at http://www.requirementsnetwork.com/ , and the main page has a button to get free membership (for a limited time, it says). So, I recommend anyone reading this post head over there and join up, ASAP!
Tuesday, August 22, 2006
Requirements Networking Group, and other stuff...
If you are reading this for the first time, and/or have been here before, do leave a comment to let me know if anyone is reading this.
I have also been blogging over at http://www.requirementsnetwork.com/ as well, re-working some previous posts from this original blog and waxing on about other things; one thing it tracks is how many people have read your entries. There is also a good forum section, and some notable people are using the site, like Alastair Cockburn and David Hay. You need to join the site, which has fee, but leave a comment here saying you would like to join, and provider a little info about yourself, and your email,... I can send you an invite to join free.
Speaking of David Hay, I am reading through his book that I mentioned in an earlier post, "Requirements Analysis: From Business Views to Architecture". The meat of the book is a chapter for each Zachman Framework column. As expected, Data and Process columns have a lot of material and model types, but his chapter on People starts with saying there are virtual no common models for this column;so, he looks at Beer's Cybernetic models as a method for documenting how an Organization works as a system, made up of lower-level sub-systems. I think I will be reading that chapter again to absorb more, if I can.
I think I said earlier that I would review this book, but at the halfway point I think can succintly praise it as a book I wish I had written(!).
That's all for now...
I have also been blogging over at http://www.requirementsnetwork.com/ as well, re-working some previous posts from this original blog and waxing on about other things; one thing it tracks is how many people have read your entries. There is also a good forum section, and some notable people are using the site, like Alastair Cockburn and David Hay. You need to join the site, which has fee, but leave a comment here saying you would like to join, and provider a little info about yourself, and your email,... I can send you an invite to join free.
Speaking of David Hay, I am reading through his book that I mentioned in an earlier post, "Requirements Analysis: From Business Views to Architecture". The meat of the book is a chapter for each Zachman Framework column. As expected, Data and Process columns have a lot of material and model types, but his chapter on People starts with saying there are virtual no common models for this column;so, he looks at Beer's Cybernetic models as a method for documenting how an Organization works as a system, made up of lower-level sub-systems. I think I will be reading that chapter again to absorb more, if I can.
I think I said earlier that I would review this book, but at the halfway point I think can succintly praise it as a book I wish I had written(!).
That's all for now...
Thursday, August 10, 2006
Optimal Trace: Analysis or Design Tool?
I got the following email today, about the Optimal Trace product for Compuware. It is marketed as a requirements tool, but it looks more like an external design tool. Has anyone used this tool?
Hello David,
The Optimal Trace (formerly SteelTrace) product primarily covers the front end of the application lifecycle, that is the activities concerned with gathering, documenting and managing the correct and appropriate business and technical requirements in a structured fashion. It forms the foundation for the downstream activities of design development and testing. Therefore Optimal Trace is primarily used in analysis and then forms the bedrock of the 'contract' by which design, development & testing is conducted. Other of the Compuware family of products such as OptimalJ, DevPartner, QACenter etc. support these other phases of the lifecycle. I've attached an information sheet from the Optimal Trace website at www.compuware.com/products/optimaltrace/ for your reference. It should help you understand the value offered.
You can get other downloads at: http://www.steeltrace.com/support/downloads.php TRIALS. You may download Optimal Trace and receive a 15-day trial license at http://www.compuware.com/products/optimalj/1797_ENG_HTML.htm. RECORDED WEBEXs.
You can get a real good feel for Optimal Trace by viewing recorded product WebExs at http://www.steeltrace.com/products/demo.php. I will follow-up with you within a few days, but do not hesitate to contact me if you have questions or need clarification.
Sincerely,
...................
Java Development and Performance Management Inside Sales Representative
Compuware Corporation www.compuware.com/products
Hello David,
The Optimal Trace (formerly SteelTrace) product primarily covers the front end of the application lifecycle, that is the activities concerned with gathering, documenting and managing the correct and appropriate business and technical requirements in a structured fashion. It forms the foundation for the downstream activities of design development and testing. Therefore Optimal Trace is primarily used in analysis and then forms the bedrock of the 'contract' by which design, development & testing is conducted. Other of the Compuware family of products such as OptimalJ, DevPartner, QACenter etc. support these other phases of the lifecycle. I've attached an information sheet from the Optimal Trace website at www.compuware.com/products/optimaltrace/ for your reference. It should help you understand the value offered.
You can get other downloads at: http://www.steeltrace.com/support/downloads.php TRIALS. You may download Optimal Trace and receive a 15-day trial license at http://www.compuware.com/products/optimalj/1797_ENG_HTML.htm. RECORDED WEBEXs.
You can get a real good feel for Optimal Trace by viewing recorded product WebExs at http://www.steeltrace.com/products/demo.php. I will follow-up with you within a few days, but do not hesitate to contact me if you have questions or need clarification.
Sincerely,
...................
Java Development and Performance Management Inside Sales Representative
Compuware Corporation www.compuware.com/products
Wednesday, August 02, 2006
OK, no more rants on Agile from me...
I posed the issue about Agile saying "don't do requirements up front, because they will change" in a forum at http://www.requirementsnetwork.com/ and Scott Ambler himself weighed with the best answer yet on this, so go on over there and check it out. An email conversation with Peter Coffee has also helped me a great deal.
My conclusion is that originators of Agile did not see it as Extreme, but rather as Flexible; that I can understand. So, no more rants from me on Agile... but now I want to what in our profession is still bugging everyone out there. Please leave a comment, and if i get enough stuff, I will publish a "top ten' list.
My conclusion is that originators of Agile did not see it as Extreme, but rather as Flexible; that I can understand. So, no more rants from me on Agile... but now I want to what in our profession is still bugging everyone out there. Please leave a comment, and if i get enough stuff, I will publish a "top ten' list.
Thursday, July 27, 2006
Agile, Schmagile...
Here's an email I got from the Yahoo Business Analysis group I belong to:
From: "ginitram" <ginitram@yahoo.fr>
Reply-To: agileanalysis@yahoogroups.com
To: agileanalysis@yahoogroups.com
Subject: [agileanalysis] Article on Agile Adoption at British Telecom
Date: Wed, 26 Jul 2006 10:53:37 -0000
The Methods & Tools newsletter has just released in its archivesection the article "Agile Delivery at British Telecom". This articledescribes the approach used by British Telecom to move towards anAgile development process
http://www.methodsandtools.com/archive/archive.php?id=43
First, I recommend joining the group, it has a medium amount of intersting activity.
OK, here was my reply:
Hasn't this been published somewhere before? It looks familiar.
First, it's time that Agile proponents know that everyone gets it, smaller is better than bigger, delivery something on a regular basis is better than a big bang at the end of the project,... enough already. As I have said elsewhere, it's not that the waterfall is too long, it's that the river is too wide.
Ok, here are some snippets with my comments in brackets:
"Capturing requirements certainly isn’t a bad thing (well, duh). On typical large programmes however,
- Individual business stakeholders are anxious to incorporate all of their known requirements into the first / next release (sure, so the business must define the $ benefit of their pet requirements, while IT estimates the $ cost, and then present results in a cost-benefit analysis to the Sponsor, the one who is paying for the system, and it will be clear waht is in and out of the first/next release)
- "Gold users" generate hundreds, if not thousands of detailed requirements that often bear little relationship to the business problems that needs to be addressed (same answer as above, plus if you literally get hundreds of requirements, declarative statements I presume, then you need to partition the project)
- Most if not all requirements are given a high priority (so rank them by highest return on investment)
- The requirements themselves, at best, represent today’s view, which will certainly have changed by the time the requirements are actually implemented (good analysis include stability analysis, documenting potential business changes and how the system will accomodate change. A systems' ability to incorporate change after delivery is also a requirement for all projects).
Given the sheer number of requirements, the design community finds itself spending most if its time trying to figure out what they mean. Meanwhile,
-The requirements analysts move on to other projects, taking with them important tacit knowledge (this reflects poor documenting standards, all knowledge gathered by the Analyst must be documented.)
- Some stakeholders become concerned that their requirements are not being adequately addressed, and therefore refuse to sign off the designs (what raises the stakeholders concerns? In any case, requirements are to be traced through design and into testing, so stakeholders really know what requirement is being supported where...)
- Other stakeholders unearth more requirements or raise change requests, diverting scarce design expertise onto impact analyses (this is scope management, the first evaluation of a change request is to determine if it is in scope or not. If it is in-scope, can it be added to the release without material impact on cost or delivery date? If not, this should go on a change request list for re-consideration in the next release.)
That's all I have to say right now...dww
From: "ginitram" <ginitram@yahoo.fr>
Reply-To: agileanalysis@yahoogroups.com
To: agileanalysis@yahoogroups.com
Subject: [agileanalysis] Article on Agile Adoption at British Telecom
Date: Wed, 26 Jul 2006 10:53:37 -0000
The Methods & Tools newsletter has just released in its archivesection the article "Agile Delivery at British Telecom". This articledescribes the approach used by British Telecom to move towards anAgile development process
http://www.methodsandtools.com/archive/archive.php?id=43
First, I recommend joining the group, it has a medium amount of intersting activity.
OK, here was my reply:
Hasn't this been published somewhere before? It looks familiar.
First, it's time that Agile proponents know that everyone gets it, smaller is better than bigger, delivery something on a regular basis is better than a big bang at the end of the project,... enough already. As I have said elsewhere, it's not that the waterfall is too long, it's that the river is too wide.
Ok, here are some snippets with my comments in brackets:
"Capturing requirements certainly isn’t a bad thing (well, duh). On typical large programmes however,
- Individual business stakeholders are anxious to incorporate all of their known requirements into the first / next release (sure, so the business must define the $ benefit of their pet requirements, while IT estimates the $ cost, and then present results in a cost-benefit analysis to the Sponsor, the one who is paying for the system, and it will be clear waht is in and out of the first/next release)
- "Gold users" generate hundreds, if not thousands of detailed requirements that often bear little relationship to the business problems that needs to be addressed (same answer as above, plus if you literally get hundreds of requirements, declarative statements I presume, then you need to partition the project)
- Most if not all requirements are given a high priority (so rank them by highest return on investment)
- The requirements themselves, at best, represent today’s view, which will certainly have changed by the time the requirements are actually implemented (good analysis include stability analysis, documenting potential business changes and how the system will accomodate change. A systems' ability to incorporate change after delivery is also a requirement for all projects).
Given the sheer number of requirements, the design community finds itself spending most if its time trying to figure out what they mean. Meanwhile,
-The requirements analysts move on to other projects, taking with them important tacit knowledge (this reflects poor documenting standards, all knowledge gathered by the Analyst must be documented.)
- Some stakeholders become concerned that their requirements are not being adequately addressed, and therefore refuse to sign off the designs (what raises the stakeholders concerns? In any case, requirements are to be traced through design and into testing, so stakeholders really know what requirement is being supported where...)
- Other stakeholders unearth more requirements or raise change requests, diverting scarce design expertise onto impact analyses (this is scope management, the first evaluation of a change request is to determine if it is in scope or not. If it is in-scope, can it be added to the release without material impact on cost or delivery date? If not, this should go on a change request list for re-consideration in the next release.)
That's all I have to say right now...dww
New site for Requirements practitioners
The Requirements Networking Group at http://www.requirementsnetwork.com/
I have just had an article published on the site, and have started a new blog there as well. I am going to keep both going for now, with the new one re-publishing some of the material from this blog that is relevant to the site.
So, follow the link, join up and participate in forum discussions and blog responses and all that good stuff.
I have just had an article published on the site, and have started a new blog there as well. I am going to keep both going for now, with the new one re-publishing some of the material from this blog that is relevant to the site.
So, follow the link, join up and participate in forum discussions and blog responses and all that good stuff.
Tuesday, July 25, 2006
...in which Peter Coffee replies and we start an interesting conversation.
Peter C was gracious to reply to my slightly flammable email, starting with:
> Oh, and please give the word "Agile" back to the English language
It wasn't me who appropriated it...
- Peter
...which I answered with:
Yeah, perhaps I should re-direct that to Scott Ambler. The last time I saw him his advice to Business Analysts was "Learn how to code...".
My other question about Agile is technology selection: when do you determine that the new system will be developed with the technology at hand, presumably the languages and such that the programmers are already using? At what point does Agile say "maybe we should buy a COTS solution"? How does Agile recognize that the solution may not be new software but use of generalized infrastructure options like Workflow/BPM tools, or Business Rule Engines?
I have seen other writers' descriptions of Agile as falling into the characterization of "If all you have is a hammer, everything looks a nail". Thoughts on that?
..which he replied to with:
> At what point does Agile say "maybe we should buy a COTS solution"?
One of the principles of agile development is that "Simplicity--the art of maximizing the amount of work not done--is essential." I would certainly interpret this as implying that a team should consider available off-the-shelf packages, or externally hosted services, as preferable alternatives to writing new code.
> How does Agile recognize that the solution may not be new software but use of generalized infrastructure options
The Agile label's full expansion is "Agile Software Development," not "Agile Systems Construction." I see no reason why a systems development process that includes a development team following "Agile" practices could not also include a dynamic, collaborative uber-team that's looking at other options besides writing new code, but we should be fair to those who use the "Agile" label: they're trying to solve the genuine problem that writing new code is a task that needs to be done better, not the equally genuine but much more general problem that defining problems and developing solutions needs to be done better.
...which I liked very much, as it may clear up some confusion on the topic. I am going to reply with a follow-up, will post it later...
> Oh, and please give the word "Agile" back to the English language
It wasn't me who appropriated it...
- Peter
...which I answered with:
Yeah, perhaps I should re-direct that to Scott Ambler. The last time I saw him his advice to Business Analysts was "Learn how to code...".
My other question about Agile is technology selection: when do you determine that the new system will be developed with the technology at hand, presumably the languages and such that the programmers are already using? At what point does Agile say "maybe we should buy a COTS solution"? How does Agile recognize that the solution may not be new software but use of generalized infrastructure options like Workflow/BPM tools, or Business Rule Engines?
I have seen other writers' descriptions of Agile as falling into the characterization of "If all you have is a hammer, everything looks a nail". Thoughts on that?
..which he replied to with:
> At what point does Agile say "maybe we should buy a COTS solution"?
One of the principles of agile development is that "Simplicity--the art of maximizing the amount of work not done--is essential." I would certainly interpret this as implying that a team should consider available off-the-shelf packages, or externally hosted services, as preferable alternatives to writing new code.
> How does Agile recognize that the solution may not be new software but use of generalized infrastructure options
The Agile label's full expansion is "Agile Software Development," not "Agile Systems Construction." I see no reason why a systems development process that includes a development team following "Agile" practices could not also include a dynamic, collaborative uber-team that's looking at other options besides writing new code, but we should be fair to those who use the "Agile" label: they're trying to solve the genuine problem that writing new code is a task that needs to be done better, not the equally genuine but much more general problem that defining problems and developing solutions needs to be done better.
...which I liked very much, as it may clear up some confusion on the topic. I am going to reply with a follow-up, will post it later...
Today I give an Enterprise Architect some advice...
Greg Fullard is starting a series of articles about 'Business Objects" (conceptual ones, not the BI software) in Object Orientation at the IT Toolbox blogs,and he is a good writer. See:
http://blogs.ittoolbox.com/cio/modeling/archives/how-to-design-beautiful-business-objects-part-1-10718#
But he has a question I felt I could answer:
"Aren't these business objects that I keep talking about just the same as the Entities that my grandpa used to tell me about?"
The simple answer is... No.
Object Orientation has always been about producing better software, easier to maintain and primed for re-use. Entities, Relationships and Data Modeling in general has always been about producing better databases, usually (if not always) relational databases that eliminate data redundancy and are accessible without physical limitations (like old hierarchical DBMS's).
Where OO and Data Modeling look the same is their focus on key items of interest to the domain (business, government, non-profit, etc.), so good models will likely have the same-named things in them, like Customer. So what's the difference?
1) A Customer Class in OO is usually focused on one occurrence (Object) at a time, and the behaviors associated with it. A working OO system instantiates at object at some point, some methods (behaviors) are exercised, and then the object is gone. The only wrinkle on this is OO's recognition that some Objects are persistent, that they may be stored somehow and be used again.
2) A Customer Entity in a Data Model is usually focused on defining all the data attributes that need to be stored for any and all occurrences of Customer for the domain. As a blueprint for a relational table, the focus here is on managing many occurrences of Customer, as many as the domain needs to keep track of.
So, two different models, because they are two different things. The interrelationship between them occurs when a persistent Object needs to be instantiated; where do OO systems get that data? Far and way it is from relational databases, since I have not seen a (commercially) viable OO database yet.
So, two different models, and don't believe anyone who says a Class Model and a Data Model are equivalent, they are not... but you can derive a Class from an existing data model. Does anyone want to know how?
http://blogs.ittoolbox.com/cio/modeling/archives/how-to-design-beautiful-business-objects-part-1-10718#
But he has a question I felt I could answer:
"Aren't these business objects that I keep talking about just the same as the Entities that my grandpa used to tell me about?"
The simple answer is... No.
Object Orientation has always been about producing better software, easier to maintain and primed for re-use. Entities, Relationships and Data Modeling in general has always been about producing better databases, usually (if not always) relational databases that eliminate data redundancy and are accessible without physical limitations (like old hierarchical DBMS's).
Where OO and Data Modeling look the same is their focus on key items of interest to the domain (business, government, non-profit, etc.), so good models will likely have the same-named things in them, like Customer. So what's the difference?
1) A Customer Class in OO is usually focused on one occurrence (Object) at a time, and the behaviors associated with it. A working OO system instantiates at object at some point, some methods (behaviors) are exercised, and then the object is gone. The only wrinkle on this is OO's recognition that some Objects are persistent, that they may be stored somehow and be used again.
2) A Customer Entity in a Data Model is usually focused on defining all the data attributes that need to be stored for any and all occurrences of Customer for the domain. As a blueprint for a relational table, the focus here is on managing many occurrences of Customer, as many as the domain needs to keep track of.
So, two different models, because they are two different things. The interrelationship between them occurs when a persistent Object needs to be instantiated; where do OO systems get that data? Far and way it is from relational databases, since I have not seen a (commercially) viable OO database yet.
So, two different models, and don't believe anyone who says a Class Model and a Data Model are equivalent, they are not... but you can derive a Class from an existing data model. Does anyone want to know how?
Monday, July 24, 2006
Today's post, in which I argue with Peter Coffee
Peter Coffee is waxing strongly on the benefits of agile development at:
http://www.eweek.com/article2/0,1895,1993420,00.asp?kc=EWITAEMNL072406EOAD
I know I am sounding like a broken record, but he asked for feedback by email, so this what I sent:
"As every good electrical engineer knows, the longer the signal path, the greater the parasitic losses due to inductance."…
An analogy that just rolls of the tongue… and has no relevance at all to the topic. Let's try another one: when I have my dream house built some day, I want to deal with the architect and maybe the overall contractor, I do not want to talk to the carpenters/bricklayers/plumbers/etc.
Business people do not want to invest time in software projects if they have to deal with the programmers; their respective frames of reference are so different they cannot communicate effectively.
That’s when a System/Business Analyst is needed, to get the business needs and develop the blue prints for the system. S/B Analysts speak both languages, and are the interpreter between the business and the programmer.
Why does agile have to react so well to change? Because the programmers did not hear what the business wanted in the first place, so odds are the software will be wrong. The SOFTWARE has to change because it is wrong, not because the business changed.
Oh, and please give the word "Agile" back to the English language; agility is not restricted to one methodology. Call yours "Programmer-Driven Development", no one can argue with that name.
David Wright
Comments, anyone?
http://www.eweek.com/article2/0,1895,1993420,00.asp?kc=EWITAEMNL072406EOAD
I know I am sounding like a broken record, but he asked for feedback by email, so this what I sent:
"As every good electrical engineer knows, the longer the signal path, the greater the parasitic losses due to inductance."…
An analogy that just rolls of the tongue… and has no relevance at all to the topic. Let's try another one: when I have my dream house built some day, I want to deal with the architect and maybe the overall contractor, I do not want to talk to the carpenters/bricklayers/plumbers/etc.
Business people do not want to invest time in software projects if they have to deal with the programmers; their respective frames of reference are so different they cannot communicate effectively.
That’s when a System/Business Analyst is needed, to get the business needs and develop the blue prints for the system. S/B Analysts speak both languages, and are the interpreter between the business and the programmer.
Why does agile have to react so well to change? Because the programmers did not hear what the business wanted in the first place, so odds are the software will be wrong. The SOFTWARE has to change because it is wrong, not because the business changed.
Oh, and please give the word "Agile" back to the English language; agility is not restricted to one methodology. Call yours "Programmer-Driven Development", no one can argue with that name.
David Wright
Comments, anyone?
Thursday, July 20, 2006
Business Analysis / Architecture "Quote of the Day", 20/07/2006
"Today, with the Zachman Framework as a foundation...we now know that if two people discussing a prospective system cannot understand each other, it is probably because each is operating in a different cell of the framework. Neither professional is necessarily incorrect or incomplete, but simply viewing the same problem space from a different perspective"
... Barbara van Halle, from her Foreword to 'REQUIREMENTS ANALYSIS: From Business Views to Architecture' by David C. Hay (Prentice-Hall, 2002)
... Barbara van Halle, from her Foreword to 'REQUIREMENTS ANALYSIS: From Business Views to Architecture' by David C. Hay (Prentice-Hall, 2002)
Wednesday, July 19, 2006
That book on Requirements Analysis was just delivered...
"Requirements Analysis: From Business Views to Architecture" by David C. Hay.
I have just finished the Forwards and Introduction, and I believe Mr. Hay may have already written the book I have thought about writing myself (assuming one can actually write a book just because you want to...).
I could wax on about specific quotes and lines of interest, but the Introduction is excerpted in full at amazon.com ("Look Inside The Book"), along with the Table of Contents, so I recommend all Business Analysts go to Amazon and read it... and then I am sure you will want to buy the book.
http://www.amazon.com/gp/product/0130282286/ref=si3_rdr_bb_product/104-5814185-0628700?ie=UTF8
Why is this a book I wish I had written? It is not a sales pitch for any one methodology, it is the sum experience of a working Business Analys/Consultant who has seen ALL the methods and models out there, now and in the past, and has taken Zachman's Framework and populated all the row 2 and 3 cells with all the Artifacts one might use; and then he sweeps across the columns speaking to all the artifacts and how you might use them. He emphasizes that the Data and Activity columns have the most artifacts, because that is where most of the analysis work has been done over the last 30 years; but he then states he is going to keeping moving to the right to those columns where not many have gone before, all the way to Motivation, and mentions some artifacts that will be unfamiliar to most people ("filters", "attenuators?").
So, on to Chapter One: "A Framework for Architecture"...
I have just finished the Forwards and Introduction, and I believe Mr. Hay may have already written the book I have thought about writing myself (assuming one can actually write a book just because you want to...).
I could wax on about specific quotes and lines of interest, but the Introduction is excerpted in full at amazon.com ("Look Inside The Book"), along with the Table of Contents, so I recommend all Business Analysts go to Amazon and read it... and then I am sure you will want to buy the book.
http://www.amazon.com/gp/product/0130282286/ref=si3_rdr_bb_product/104-5814185-0628700?ie=UTF8
Why is this a book I wish I had written? It is not a sales pitch for any one methodology, it is the sum experience of a working Business Analys/Consultant who has seen ALL the methods and models out there, now and in the past, and has taken Zachman's Framework and populated all the row 2 and 3 cells with all the Artifacts one might use; and then he sweeps across the columns speaking to all the artifacts and how you might use them. He emphasizes that the Data and Activity columns have the most artifacts, because that is where most of the analysis work has been done over the last 30 years; but he then states he is going to keeping moving to the right to those columns where not many have gone before, all the way to Motivation, and mentions some artifacts that will be unfamiliar to most people ("filters", "attenuators?").
So, on to Chapter One: "A Framework for Architecture"...
Tuesday, July 11, 2006
Business Architecture?
My past experience has included stints as an 'Architect', rather than 'Analyst', and one of those titles was truly involved in Architecture, with a focus on Models and the Zachman Framework.
That was a few years ago, but I was recently asked for my views on what "Business Architecture" is, and here is what I wrote:
Three key aspects of Architecture:
1) It is not an end in itself; Architecture exists because things need to be built.
2) Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.
3) Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.
The most common and oldest form of architecture is construction of buildings: dwellings, work-places, etc.. The need for Architecture arose centuries ago when construction failed or the end result collapsed. All of the above three aspects are inherent in this field: the known and desired end product, defining and integrating all components needed, and the layering: from a high-level floor plan, to blueprints, to wiring diagrams and other detailed specifications.
A Business, any Business, has the same need for Architecture, and presents further challenges than constructing a building. Buildings are complicated, being made up of many pieces that have to fit together, but they are finite; you can count and describe all the pieces which will be in place when the building is complete. A Business, and really Enterprises of any kind, are complex, meaning that they change over time; pieces may be re-arranged to fit together in a different way (e.g. org chart re-organizations or process improvements), and some pieces may be revamped or enhanced (like Information Systems), while other pieces are retired/discarded and new pieces added to the Enterprise (like Equipment).
In the end, the most commonly identified pieces of an Enterprise are its resources (people, capital, raw material) and the systems/processes that use the resources to produce an end product or service. Enterprises use many different kinds of systems in their operations, many of which are highly cohesive and de-coupled (their relationships to other pieces are few and well-defined), e.g. different assembly lines of a manufacturing company.
On the other hand, Information Systems used by an Enterprise in support of its operations increasingly need to be aware of the full scope of the Business, across all resources and processes. This presents its own Architectural requirements, such that a complete, all-encompassing Enterprise Architecture for Information Systems is needed, if systems and technologies (the “pieces” of the Information Systems) are to built/acquired, deployed and used effectively, without the redundancy, duplication and inconsistency of information systems delivered in the past.
Architecture within a discipline comes to depend on common practices and standards over time to increase efficiency and eliminate unnecessary re-invention; it is commonly stated that Information Systems delivery as a discipline is still too young to have developed such commonality, but work has begun, notably by John Zachman and his and his Enterprise Architecture Framework of the late 1980’s.
See http://www.zifa.com/ .
Here are your Resources (the columns) and your layered views (the rows) that will take a Business from its highest-level context through to functioning Information Systems.
They key row to me is Row 2, the Business Model. Row 1 provides, as its says context/scope. It is very important to understand the scope/boundary of the Enterprise for which the architecture is being created, especially when large Businesses define themselves as being constituted of multiple ‘Enterprises’. Once that is defined, which should not take very long, the critical development of the Row 2 Business Models can proceed; these must accurately represent the in-scope enterprise/business at a detail level, otherwise the remaining lower rows (where most of the money is spent) will not lead to building the right Information Systems for the Business.
Finally, Zachman always states that he has defined a Framework, not a methodology to populate the cells, or define what types of models should be used. Given the framework, different methods/models can be used for creating (and communicating!) an Enterprise Architecture for a Business, often with a focus on accelerated or prioritized delivery; most owe some debt to the original Information Engineering developed by Finklestein in the 70’s and popularized by Martin in the 80’s. The key point here (and the last one in this dissertation) is that it does not matter which methodology you use, as long as you pick one and use it for all it is worth, both to create systems, and as a language common to all participants in the Systems Delivery Process (SDP).
That was a few years ago, but I was recently asked for my views on what "Business Architecture" is, and here is what I wrote:
Three key aspects of Architecture:
1) It is not an end in itself; Architecture exists because things need to be built.
2) Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.
3) Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.
The most common and oldest form of architecture is construction of buildings: dwellings, work-places, etc.. The need for Architecture arose centuries ago when construction failed or the end result collapsed. All of the above three aspects are inherent in this field: the known and desired end product, defining and integrating all components needed, and the layering: from a high-level floor plan, to blueprints, to wiring diagrams and other detailed specifications.
A Business, any Business, has the same need for Architecture, and presents further challenges than constructing a building. Buildings are complicated, being made up of many pieces that have to fit together, but they are finite; you can count and describe all the pieces which will be in place when the building is complete. A Business, and really Enterprises of any kind, are complex, meaning that they change over time; pieces may be re-arranged to fit together in a different way (e.g. org chart re-organizations or process improvements), and some pieces may be revamped or enhanced (like Information Systems), while other pieces are retired/discarded and new pieces added to the Enterprise (like Equipment).
In the end, the most commonly identified pieces of an Enterprise are its resources (people, capital, raw material) and the systems/processes that use the resources to produce an end product or service. Enterprises use many different kinds of systems in their operations, many of which are highly cohesive and de-coupled (their relationships to other pieces are few and well-defined), e.g. different assembly lines of a manufacturing company.
On the other hand, Information Systems used by an Enterprise in support of its operations increasingly need to be aware of the full scope of the Business, across all resources and processes. This presents its own Architectural requirements, such that a complete, all-encompassing Enterprise Architecture for Information Systems is needed, if systems and technologies (the “pieces” of the Information Systems) are to built/acquired, deployed and used effectively, without the redundancy, duplication and inconsistency of information systems delivered in the past.
Architecture within a discipline comes to depend on common practices and standards over time to increase efficiency and eliminate unnecessary re-invention; it is commonly stated that Information Systems delivery as a discipline is still too young to have developed such commonality, but work has begun, notably by John Zachman and his and his Enterprise Architecture Framework of the late 1980’s.
See http://www.zifa.com/ .
Here are your Resources (the columns) and your layered views (the rows) that will take a Business from its highest-level context through to functioning Information Systems.
They key row to me is Row 2, the Business Model. Row 1 provides, as its says context/scope. It is very important to understand the scope/boundary of the Enterprise for which the architecture is being created, especially when large Businesses define themselves as being constituted of multiple ‘Enterprises’. Once that is defined, which should not take very long, the critical development of the Row 2 Business Models can proceed; these must accurately represent the in-scope enterprise/business at a detail level, otherwise the remaining lower rows (where most of the money is spent) will not lead to building the right Information Systems for the Business.
Finally, Zachman always states that he has defined a Framework, not a methodology to populate the cells, or define what types of models should be used. Given the framework, different methods/models can be used for creating (and communicating!) an Enterprise Architecture for a Business, often with a focus on accelerated or prioritized delivery; most owe some debt to the original Information Engineering developed by Finklestein in the 70’s and popularized by Martin in the 80’s. The key point here (and the last one in this dissertation) is that it does not matter which methodology you use, as long as you pick one and use it for all it is worth, both to create systems, and as a language common to all participants in the Systems Delivery Process (SDP).
Tuesday, June 27, 2006
Computerworld on Requirements, revisited
The CW blog I wrote about early in June has had some more comments added, and I had to add a new one as well:
http://www.computerworld.com/blogs/node/2657#comment-6399
One comment was:
Great comments all but everyone failed to mention the obvious. It seems business requirements change constantly. End users know this and developers know this. Both parties struggle with the frustration created by such an environment.
So, I replied with:
Just checked back to see how this conversation, looks pretty good.
However, I must challenge the "Business Requirements change constantly" statement. In stating that, you are saying that all Business Requirements are the same in form or shape, which is absurd. Business Requirements vary in their purpose and perspective, and I classify them into at minimum the following categories:
- Business Processes
- Business Rules
- Function / System Use (Use case)
- Data Requirements
This is a ranked list, from the requirements that change the most to the ones that change the least.
Business Processes change frequently: new steps, re-ordering of steps, new restrictions. If you are building today's business process into your information system, you have built an instant legacy system. The business will start to work-around your system almost immediately. This is what workflow and and business process management systems are for. They may be computerized, but they are not 'Information' Systems.
Business Rules change less frequently, but often enough that they now have their own automation systems, known as Business Rule Engines. Do a web search to learn what you need to know about those.
That leaves your core Information system requirements, the data you store and the main functions that CRUD the data. These do change, but not very often. Creating a new customer with name and address is the same now as it was 20 years ago and will be 20 years from now.
So, understand your Business Requirements and that development of software and databases is not the only method available in meeting those requirements.
http://www.computerworld.com/blogs/node/2657#comment-6399
One comment was:
Great comments all but everyone failed to mention the obvious. It seems business requirements change constantly. End users know this and developers know this. Both parties struggle with the frustration created by such an environment.
So, I replied with:
Just checked back to see how this conversation, looks pretty good.
However, I must challenge the "Business Requirements change constantly" statement. In stating that, you are saying that all Business Requirements are the same in form or shape, which is absurd. Business Requirements vary in their purpose and perspective, and I classify them into at minimum the following categories:
- Business Processes
- Business Rules
- Function / System Use (Use case)
- Data Requirements
This is a ranked list, from the requirements that change the most to the ones that change the least.
Business Processes change frequently: new steps, re-ordering of steps, new restrictions. If you are building today's business process into your information system, you have built an instant legacy system. The business will start to work-around your system almost immediately. This is what workflow and and business process management systems are for. They may be computerized, but they are not 'Information' Systems.
Business Rules change less frequently, but often enough that they now have their own automation systems, known as Business Rule Engines. Do a web search to learn what you need to know about those.
That leaves your core Information system requirements, the data you store and the main functions that CRUD the data. These do change, but not very often. Creating a new customer with name and address is the same now as it was 20 years ago and will be 20 years from now.
So, understand your Business Requirements and that development of software and databases is not the only method available in meeting those requirements.
Monday, June 26, 2006
"Requirements Analysis: From Business Views to Architecture"
"Requirements Analysis: From Business Views to Architecture" is a book by David Hay I just discovered at Amazon.ca, I think this link will work:
Requirements Analysis: From Business Views to Architecture
It is from about 2002, and I have bought it because of its rejection of OO-analysis, and the content seems to be focused on Requirements Artifacts as organized by the Zachman Framework. So, I will report back on its complete merits when I have received and read it.
I must admit, I bought a fairly inexpensive copy through eBay, but when we BA's are compensated in measure with our actual value, perhaps I will start buying retail.... :-)
Requirements Analysis: From Business Views to Architecture
It is from about 2002, and I have bought it because of its rejection of OO-analysis, and the content seems to be focused on Requirements Artifacts as organized by the Zachman Framework. So, I will report back on its complete merits when I have received and read it.
I must admit, I bought a fairly inexpensive copy through eBay, but when we BA's are compensated in measure with our actual value, perhaps I will start buying retail.... :-)
Thursday, June 08, 2006
"The Executive Briefing on the Issues Surrounding Getting Business Requirements Right"
Digital Mosaic is a vendor in the Requirements space, and they have released a white paper to communicate the importance of Requirements to Executive-level Management. I recommend its use if you need to do just that... and it is also just a well-written piece, so you can follow the link below to have a look.
TITLE: "The Executive Briefing on the Issues Surrounding Getting Business Requirements Right"
http://www.bitpipe.com/data/detail?id=1149175510_232&type=RES&src=KA_RES_20060607
PUBLISHER: Digital Mosaic
TYPE: White Paper
TITLE: "The Executive Briefing on the Issues Surrounding Getting Business Requirements Right"
http://www.bitpipe.com/data/detail?id=1149175510_232&type=RES&src=KA_RES_20060607
PUBLISHER: Digital Mosaic
TYPE: White Paper
The Waterfall is not too long, the River is too wide...
Bob Lewis at his Infoworld blog/column is answering a reader question; "What is Waterfall methodology?"
Bob defines it, and trots out the old standbys about how it takes too long, and you can never go back to a previous phase, etc... and several commenters chimed in to agree, Agile proponents I presume... so I had to leave a comment too:
http://weblog.infoworld.com/lewis/archives/2006/06/what_waterfall.html?source=NLC-ADVICE2006-06-07
...which said:
The problem isn't with (the) Waterfall steps, its that the River is too wide. If you have a large project, good heavens, don't do all the requirements at once. Scope out an overall architecture, and break it up into pieces. Plan for multiple phases and releases, then do the first one, then the next one, etc. etc.. You look at any 'alternative' methodology, they will end up doing the same waterfall steps, but in iterations or some other cleverly-named approach. Sounds the same to me.
Bob defines it, and trots out the old standbys about how it takes too long, and you can never go back to a previous phase, etc... and several commenters chimed in to agree, Agile proponents I presume... so I had to leave a comment too:
http://weblog.infoworld.com/lewis/archives/2006/06/what_waterfall.html?source=NLC-ADVICE2006-06-07
...which said:
The problem isn't with (the) Waterfall steps, its that the River is too wide. If you have a large project, good heavens, don't do all the requirements at once. Scope out an overall architecture, and break it up into pieces. Plan for multiple phases and releases, then do the first one, then the next one, etc. etc.. You look at any 'alternative' methodology, they will end up doing the same waterfall steps, but in iterations or some other cleverly-named approach. Sounds the same to me.
Friday, June 02, 2006
Computerworld on Requirements
A Computerworld blogger has written about Requirements, and how tough it is to get the right requirements. After getting over the shock of seeing this discussed within Computerworld, I read the blog entry and, of course, it mentions users and developers, but not Business Analysts, so I had to add a comment.
See the blog and my comments at http://www.computerworld.com/blogs/node/2657
See the blog and my comments at http://www.computerworld.com/blogs/node/2657
Wednesday, May 17, 2006
PM/BA World Presentations - 1
Agile Project Management
Managing in the face of ever-changing
requirements
Kevin Aguanno, PMP, MAPM
OK, here is the first one I have looked at that has ‘Agile’ in the title. It is basically an Agile overview, by a published author on the topic.
My comments/thoughts:
… why are ‘traditional’ methods always described as forcing the Requirements to be ‘locked down’, ie. no changes allowed during development? A simple Change Management process can be used to address any and all possible changes to a project, not just requirement changes. The aim of such a process is not just to identify a change, but to document its impact on the project. Agile projects seem to live in a fantasy world where the sponsor did not demand to know the cost, effort and target date before agreeing to pay for the project, so I guess Agile sponsors don’t care about changes that could increase cost or delay delivery.
…my favourite Agile principle: ‘Working software over comprehensive documentation’… how many times have you heard a maintenance programmer a few years down the road after implementation complain that the system documentation he/she has to work with is ‘too comprehensive’?
…Agile project characteristic: ‘Early and continuous delivery of usable deliverables’… Agreed, so why can’t you know what you will deliver before you start, if each delivery is small? The presenter describes Feature Driven Development as an Agile methodology, where it says the first thing to do is build a model for the whole domain, then start iterating. Well, what is in that model? Your requirements!: a function model, a data model, a process model, whatever… those are documentation of Requirements.
…about Features (in the SCRUM methodology too); what does a feature look like? How to you document it? How do you know what data is needed for a Feature? Cute names don't an artifact make.
OK, that’s it for now. I have looked at about a dozen other presentations as well, all of them pretty good but nothing has jumped out at me to comment on. I know there are at least a few more on Agile I have yet to look at, but I won’t write about Agile again unless something really interesting comes up.
Managing in the face of ever-changing
requirements
Kevin Aguanno, PMP, MAPM
OK, here is the first one I have looked at that has ‘Agile’ in the title. It is basically an Agile overview, by a published author on the topic.
My comments/thoughts:
… why are ‘traditional’ methods always described as forcing the Requirements to be ‘locked down’, ie. no changes allowed during development? A simple Change Management process can be used to address any and all possible changes to a project, not just requirement changes. The aim of such a process is not just to identify a change, but to document its impact on the project. Agile projects seem to live in a fantasy world where the sponsor did not demand to know the cost, effort and target date before agreeing to pay for the project, so I guess Agile sponsors don’t care about changes that could increase cost or delay delivery.
…my favourite Agile principle: ‘Working software over comprehensive documentation’… how many times have you heard a maintenance programmer a few years down the road after implementation complain that the system documentation he/she has to work with is ‘too comprehensive’?
…Agile project characteristic: ‘Early and continuous delivery of usable deliverables’… Agreed, so why can’t you know what you will deliver before you start, if each delivery is small? The presenter describes Feature Driven Development as an Agile methodology, where it says the first thing to do is build a model for the whole domain, then start iterating. Well, what is in that model? Your requirements!: a function model, a data model, a process model, whatever… those are documentation of Requirements.
…about Features (in the SCRUM methodology too); what does a feature look like? How to you document it? How do you know what data is needed for a Feature? Cute names don't an artifact make.
OK, that’s it for now. I have looked at about a dozen other presentations as well, all of them pretty good but nothing has jumped out at me to comment on. I know there are at least a few more on Agile I have yet to look at, but I won’t write about Agile again unless something really interesting comes up.
Saturday, May 13, 2006
BA World - afterthoughts
So, my presentation covered the content of a lot of my early posts on this blog, i.e:
-what is an Information System Requirement...
- you need multiple documenting artifacts to capture different types of requirements
- the multiple artifacts need to be integrated to eliminate duplication/redundancy
My sense of the audience that came to see me.... ..........wait, I have to say that I am beyond thrilled that upwards of 50 people did come to see me, certainly encourages me to do it again..... ..... anyway, I think I was speaking to some people who are not (yet) getting to use any artifacts, and are still churning out paragraph-based documents... and some people are only getting to use one artifact and trying to cram everything into it, the best evidence for 'one artifact does not fit all'. So, I hope I gave people some ideas that will help them back in their work-places.
I was also a little surprised that when I asked if there were any data modelers in the room, only one person raised their hand; and that person seemed to be young enough not to know who Ron Ross is, or was to data modeling. I am still not sure what to make of that, Data Modeling is still the senior method/artifact to me, everything else builds on the data, in Use Cases, in Business Rules, and more.
In the meantime, I have started scanning through some of the other presentations, so will report next on the highlights next time...
-what is an Information System Requirement...
- you need multiple documenting artifacts to capture different types of requirements
- the multiple artifacts need to be integrated to eliminate duplication/redundancy
My sense of the audience that came to see me.... ..........wait, I have to say that I am beyond thrilled that upwards of 50 people did come to see me, certainly encourages me to do it again..... ..... anyway, I think I was speaking to some people who are not (yet) getting to use any artifacts, and are still churning out paragraph-based documents... and some people are only getting to use one artifact and trying to cram everything into it, the best evidence for 'one artifact does not fit all'. So, I hope I gave people some ideas that will help them back in their work-places.
I was also a little surprised that when I asked if there were any data modelers in the room, only one person raised their hand; and that person seemed to be young enough not to know who Ron Ross is, or was to data modeling. I am still not sure what to make of that, Data Modeling is still the senior method/artifact to me, everything else builds on the data, in Use Cases, in Business Rules, and more.
In the meantime, I have started scanning through some of the other presentations, so will report next on the highlights next time...
Friday, May 12, 2006
The day after BA World
First off, it took me 3 hours to drive home, downtown Toronto to K/W (assuming u know where that is..)
Other than presenting, the most fun I had was listening to Scott Ambler dissing Business Analysts, but not Business Analysis, on a panel discussion. I had one innocent question when one of the other panelists mentioned offshoring, but after some other questions from the floor that had Scott complaining about 'useless documentation produced by BAs' and 'BAs should learn to code', I got the mike back and vented on him a bit about how BAs like me work successfully with developers every day... then when things slowed down, I got the mike again and the MC (good Ms. Kerton!) warned me to ask a question only, which I was going to do, as I started to speak Scott called me an 'evil man'! All in good jest, of course, and I accept it as a compliment. I must see if he has a forum and continue the discussion, if possible. He is certainly one of the most recognized proponent of Agile approaches, so I give him full credit for coming to BA World and participating on the panel (about the future of the BA role). Our wonderfull IIBA president, Kathleen Barret, was also on the panel and had plenty of chances to mix it up with Scott as well, but they agreed on a few things too.It is somewhat amazing/exciting that we actually have a controversial subject to discuss, so also full credit to BA World for addressing it. I had to duck out before the session ended to get ready for my own little show, so if anyone else was there and has any news on how it ended, do let me know.
The other new and good event was roundtable group discussions on various topics like where does the BA role belong in an organization, and BAs as PMs, and (my favourite) Agile Analysis. Volunteers facilitated the sessions, and groups of 5 or 6 people made for great discussions; there were roundtables on PM subjects too (as BA World is partnered with the longer-running Project World), so I hope the PMs enjoyed theirs as well.
That's it for now. I am gathering more thoughts on how my presentation went, and the very good discussions I had with some attendees afterwards, plus I have some business cards and email addresses to check up on, and all the the presentations I didn't see on CD to go over... so more on BA World in my next post.
Other than presenting, the most fun I had was listening to Scott Ambler dissing Business Analysts, but not Business Analysis, on a panel discussion. I had one innocent question when one of the other panelists mentioned offshoring, but after some other questions from the floor that had Scott complaining about 'useless documentation produced by BAs' and 'BAs should learn to code', I got the mike back and vented on him a bit about how BAs like me work successfully with developers every day... then when things slowed down, I got the mike again and the MC (good Ms. Kerton!) warned me to ask a question only, which I was going to do, as I started to speak Scott called me an 'evil man'! All in good jest, of course, and I accept it as a compliment. I must see if he has a forum and continue the discussion, if possible. He is certainly one of the most recognized proponent of Agile approaches, so I give him full credit for coming to BA World and participating on the panel (about the future of the BA role). Our wonderfull IIBA president, Kathleen Barret, was also on the panel and had plenty of chances to mix it up with Scott as well, but they agreed on a few things too.It is somewhat amazing/exciting that we actually have a controversial subject to discuss, so also full credit to BA World for addressing it. I had to duck out before the session ended to get ready for my own little show, so if anyone else was there and has any news on how it ended, do let me know.
The other new and good event was roundtable group discussions on various topics like where does the BA role belong in an organization, and BAs as PMs, and (my favourite) Agile Analysis. Volunteers facilitated the sessions, and groups of 5 or 6 people made for great discussions; there were roundtables on PM subjects too (as BA World is partnered with the longer-running Project World), so I hope the PMs enjoyed theirs as well.
That's it for now. I am gathering more thoughts on how my presentation went, and the very good discussions I had with some attendees afterwards, plus I have some business cards and email addresses to check up on, and all the the presentations I didn't see on CD to go over... so more on BA World in my next post.
Thursday, May 11, 2006
Live from BA World
Hi all, just a quick note at 3:30 pm at Business Analyst World in Toronto... did my presentation at 1:15, and all seems to have gone well. It was still a little nervewracking, and the clipon microphone came off twice, but I finished early, took some questions, and had some good after-presentation discussions with a few people. Verbal reviews were encouraging, now just have to wait for the feedback sheets(!).
I recommend speaking at a conference like this, if you have something you want to share. What you may think is normal or well-known, still might news to others... anyway, I will post some more on BA World over the next few days.
I recommend speaking at a conference like this, if you have something you want to share. What you may think is normal or well-known, still might news to others... anyway, I will post some more on BA World over the next few days.
Tuesday, May 09, 2006
PM/BA World this week.
OK, Project Management and Business Analyst World are on this week in Toronto; I make my presentation on Thursday (May 11).
My subject is Integrating Business Analysis Artifacts (including Business Rules).The details are available at :http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646
I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld. See http://www.projectworldcanada.com/ for details.So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.
My subject is Integrating Business Analysis Artifacts (including Business Rules).The details are available at :http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646
I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld. See http://www.projectworldcanada.com/ for details.So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.
Wednesday, April 26, 2006
Anyone familiar with 'Profesy' from SOFEA Inc.?
Overall I have not been impressed with automated Requirements tools from vendors like Rational or MKS; they just seem to be just list managers with change control... but I would like to hear from anyone using one of these products who finds them useful.
The main reason for today's post is a white paper I read today, from SOFEA Inc about their 'Customer Oriented Software Development' Methodology, which is supported by their Profesy tool (which is a pretty aggresive, self-confident name, even if it is spelled with an 'f' insteaf of 'ph').
The white paper is a pretty good, almost entertaining read for 15 pages, laying out how getting the right Requirements is the most important part of software development ( a little ego-stroking for us Business Analysts) but the methods used in the past (waterfall) could not ensure getting it right, and newer methods (CMMI or Agile) that were supposed to improve this have not made any impact.
So, what is SOFEA suggesting? ...that Requirements can't really capture the 'Customer Idea' that initiates software projects, you need to transform the 'Customer Idea' into 'Customer Needs' first, and from those you can generate all the rest of the usual development artifacts, starting with the Requirements... and then the White paper ends! No example of a Customer Need! or how it is different than what a Requirement would be!
I have been cruising their website (www.sofeainc.com) and have not seen any more detail; there are a few more documents available to download, but they make you identify yourself and your company before you can get the document ( I hate websites that do that!) , and I am not yet ready to contribute my identity to their marketing database. Perhaps they consider the definition and content of a 'Customer Need' to be a company secret, but they have to give it up at some point.
So, is anyone out there using Profesy? or has at least seen some more details that they could share? If so, post a comment to let me know. I am pretty much prepared to be underwhelmed if or when I get more details, but the white paper was just so good as far as it went, I can only hope they really have something good here.
The main reason for today's post is a white paper I read today, from SOFEA Inc about their 'Customer Oriented Software Development' Methodology, which is supported by their Profesy tool (which is a pretty aggresive, self-confident name, even if it is spelled with an 'f' insteaf of 'ph').
The white paper is a pretty good, almost entertaining read for 15 pages, laying out how getting the right Requirements is the most important part of software development ( a little ego-stroking for us Business Analysts) but the methods used in the past (waterfall) could not ensure getting it right, and newer methods (CMMI or Agile) that were supposed to improve this have not made any impact.
So, what is SOFEA suggesting? ...that Requirements can't really capture the 'Customer Idea' that initiates software projects, you need to transform the 'Customer Idea' into 'Customer Needs' first, and from those you can generate all the rest of the usual development artifacts, starting with the Requirements... and then the White paper ends! No example of a Customer Need! or how it is different than what a Requirement would be!
I have been cruising their website (www.sofeainc.com) and have not seen any more detail; there are a few more documents available to download, but they make you identify yourself and your company before you can get the document ( I hate websites that do that!) , and I am not yet ready to contribute my identity to their marketing database. Perhaps they consider the definition and content of a 'Customer Need' to be a company secret, but they have to give it up at some point.
So, is anyone out there using Profesy? or has at least seen some more details that they could share? If so, post a comment to let me know. I am pretty much prepared to be underwhelmed if or when I get more details, but the white paper was just so good as far as it went, I can only hope they really have something good here.
Wednesday, April 12, 2006
Requirements are a means to an end.
A scan through my previous entries will confirm that I view documented Requirements as an essential artifact for systems development.
Given that, I don't want to imply that Requirements are 'sacred' in some way or worse yet, an end in themselves. They are a vital but intermediate deliverable along the way to delivering the solution that your business needs to succeed.
This brings me to the often-cited problem in Requirements work most commonly known as 'analysis paralysis'. Requirements gathering, analysis, and documentation cannot be some endless task that defers delivering the Requirements because of uncertainties or changes in the details of the Requirements. It does require sufficient time, but historically I have seen the effort spent on Requirements average around 25% of a total systems project. If you are spending more than 25% on a regular basis, you might have some paralysis going on.
(Sidebar: the other 75%? Typically I see 50% on design, build, and unit testing, and 25% on the rest of Testing: System, User, Acceptance, Volume, Regression, and probably more I am forgetting.)
How can you avoid paralysis?
- Define a clear scope of the Business process or function that is to be supported by the solution. If you have or can quickly put together a process map (start by defining all the external events the business must respond to), then it can be shown what you are are gathering Requirements for, and what you are not. Having that Process Map also helps identify units of work in process steps that can be documented as Use Cases.
- If nailing scope down is difficult, then time-box the work; take what you do have defined as likely in scope, and spend 2 to 3 weeks of focussed work with business involvement, and you will be surprised the volume of Requirements you will produce. Stop at the end of the time-box, and re-group/review with your Sponsor. You may have enough to start a round of development/delivery, or a better view of how much time you need to finish a complete set of Requirements.
It is also important to recognize the Requirements will change, but not necessarily for the reasons you might think. For example, you may document a portion of the requirements and review it with the business staff involved in the gathering, and you just may have written it down wrong or misunderstood what they told you; reviews/walkthroughs are essential for any quality product. If you can succeed in getting agreement that the documented Requirements are correct from the business, the amount of change after that point will be minimal.
(Agile methods proponents will tell you the business changes too much and too often for documented requirements to remain valid; don't believe it. Core information systems requirements about collecting, storing and using data do not change much over time; what does change the most is process/procedural activities, the main reason why an Information System should not automate business process, especially now that BPM tools are available that are designed to accommodate procedure changes. As author Steve McConnell recently said, the main reasons requirements change during agile development is that the requirements were not fully investigated before development started.)
The last advice I would offer to fellow BA's is that you document the Requirements, but you do not own them; they belong to the business. So, don't agonize over what may happen to Requirements after you have delivered them. There is a quote about working whose source I must track down, as it guides me every day; it is:…
"Show up on time, do your best, don't get attached to the results".
Wise words. Besides, there is always another project up next that needs its Requirements documented, so get to it!…
Wednesday, April 05, 2006
Discussion of Agile and Business Analysis/Analysts, continues
Here's an email message set from the Agile Analysis Yahoo Group...
From : Chris Matts
Reply-To :
Sent : Wednesday, March 29, 2006 2:17 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Hi Jeff, Kent. Long time no speak. Hello David
Lets get something straight. There is a place for business analysts within Agile. Business Analysis is not about writing documents though.Lets get something else straight. The reason Agile says they do not need them is because approximately 98% of BAs are crap. I should know I have interviewed close to 100 in the last year or so. One of the problems is that no one knows what a BA is. I do (from my perspective) and as a result I have tried to train the 20 people in my department to do the role. Guess what..... they are lazy/scared and do not want to change.........
Does this sound like Agile?Drop me a line and we can chat when I'm sober.
Chris
From : David Wright
Reply-To : agileanalysis@yahoogroups.com
Sent : Thursday, March 30, 2006 6:03 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Chris, what are you drinkin'? I think I could use some too...
"Business Analysis is not about writing documents though."
Right, it is about documenting Requirements, which is different.
I have written about this a fair bit at
http://www.businessanalysis56.blogspot.com/
From : Kevin Brennan
Reply-To :
Sent : Thursday, March 30, 2006 7:41 PM
To : agileanalysis@yahoogroups.com
Subject : Re: [agileanalysis] Any activity in this Group?
Chris Matts wrote:> Lets get something else straight. The reason Agile says they do not need> them is because approximately 98% of BAs are crap....
That's one of the big reasons the IIBA got started. The goal behind developing the Body of Knowledge and associated certification activities is to try and get people to understand what a BA does and does not do. I agree, it's hard to find someone with the right general skills.A big part of the problem is that a lot of BAs are "accidental"; they get seconded to the job as part of an IT project and then become a"Business Analyst" because their old job got filled while the poject was going. The result is that many BAs are little more than above-average end users with no special training or aptitude for the role.-------------------------------------
Kevin Brennan, PMPCo-Chair, IIBA Body of Knowledge Committeekevin.brennan@theiiba.org
From : Jeff Patton
Reply-To : agileanalysis@yahoogroups.com
Sent : Friday, March 31, 2006 8:24 AM
To :
Subject : RE: [agileanalysis] Any activity in this Group?
:-) Good to hear from you Chris! Although Chris might be drunk, his point isn't completely off. I'll be honest. I work alongside business analysts in agile contexts, and struggle with their thought processes at times. I consider myself an interaction designer. I work with end users and business stakeholders, talk with them about their goals, build models, think hard, and work to arrive at solutions that optimize business's return on investment while meeting user goals. I call that work design. The BAs I work with do very much the same work, only they refer to it as requirements capturing. I struggle with the term requirements capture vs. design. For me design implies some creativity and invention - and most importantly some responsibility. Requirements capture doesn't imply any of those things to me - sounds sort of like a passive thing that requires good listening and recording skills. Although I know that if I pick up any decent book on requirements work, I'll find the words creativity and invention in it - I just won't find the words design in it -at least not in reference to what the BA does. I sometimes wonder if that posture of elicitation and capture vs. a posture of responsible design isn't part of the key to their effectiveness - or lack thereof.
Although I'm not drunk, my plane is over 3 hours late and I'm ticked off and stuck at the airport. So if this sounds inflammatory to BAs - I'll blameUnited Airlines.
Cheers,-Jeff
From : David Wright
Reply-To :
Sent : Friday, March 31, 2006 9:58 AM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
In short, having Requirements first supports the choice of solution, which may not always be to design and develop something new.I can't recall where I first heard this mantra-like statement, but it has stayed with me:
"Re-Use before Buy, Buy before Build, Build for Re-Use".
Requirements are like blue-prints, especially those using models. If system delivery and software development (which are not always the same thing) are to move beyond being a craft to a real discipline, we have to stop starting with Design and know What to build before we decide How.
Dave Wright
>From: "Kent J. McDonald" mailto:kent@kentmcdonald.com
Reply-To: agileanalysis@yahoogroups.com>
To: agileanalysis@yahoogroups.com>
Subject: RE: [agileanalysis] Any activity in this Group?>
Date: Fri, 31 Mar 2006 21:13:11 -0600>>
Is it necessarily a bad thing that Software Development is a craft?
>-->Kent J. McDonald>kent@kentmcdonald.com>http://www.kentmcdonald.com>Words to lead by: Collaborate; Iterate; Serve the Team; Consider Context;>Practice Excellence; Reflect and Adapt; Deliver Value
From :
David Wright
Reply-To :
Sent :
Saturday, April 1, 2006 9:22 PM
To : agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
"Is it necessarily a bad thing that Software Development is a craft?"
A craft-work approach to delivery implies custom-made, low-volume and high-cost results. Shoes haven't made by cobblers for a century or two, and just because software is a relatively new and uniquely malleable product, this does not mean it won't and shouldn't be produced using engineering-based production methods. This will be the way software will become a product where quality is assumed, not just hoped for.
What implications does this have for programming as we know it? It will become less and less of a technical creation skill amd more of an assembly role, putting together software components to create systems.
(If that upsets any programmers reading this, well, I have been out drinking some single-malt tonight, so my opinions may be a little direct by this time of night.... :-) )Dave W
From : Chris Matts
Reply-To :
Sent : Wednesday, March 29, 2006 2:17 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Hi Jeff, Kent. Long time no speak. Hello David
Lets get something straight. There is a place for business analysts within Agile. Business Analysis is not about writing documents though.Lets get something else straight. The reason Agile says they do not need them is because approximately 98% of BAs are crap. I should know I have interviewed close to 100 in the last year or so. One of the problems is that no one knows what a BA is. I do (from my perspective) and as a result I have tried to train the 20 people in my department to do the role. Guess what..... they are lazy/scared and do not want to change.........
Does this sound like Agile?Drop me a line and we can chat when I'm sober.
Chris
From : David Wright
Reply-To : agileanalysis@yahoogroups.com
Sent : Thursday, March 30, 2006 6:03 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Chris, what are you drinkin'? I think I could use some too...
"Business Analysis is not about writing documents though."
Right, it is about documenting Requirements, which is different.
I have written about this a fair bit at
http://www.businessanalysis56.blogspot.com/
From : Kevin Brennan
Reply-To :
Sent : Thursday, March 30, 2006 7:41 PM
To : agileanalysis@yahoogroups.com
Subject : Re: [agileanalysis] Any activity in this Group?
Chris Matts wrote:> Lets get something else straight. The reason Agile says they do not need> them is because approximately 98% of BAs are crap....
That's one of the big reasons the IIBA got started. The goal behind developing the Body of Knowledge and associated certification activities is to try and get people to understand what a BA does and does not do. I agree, it's hard to find someone with the right general skills.A big part of the problem is that a lot of BAs are "accidental"; they get seconded to the job as part of an IT project and then become a"Business Analyst" because their old job got filled while the poject was going. The result is that many BAs are little more than above-average end users with no special training or aptitude for the role.-------------------------------------
Kevin Brennan, PMPCo-Chair, IIBA Body of Knowledge Committeekevin.brennan@theiiba.org
From : Jeff Patton
Reply-To : agileanalysis@yahoogroups.com
Sent : Friday, March 31, 2006 8:24 AM
To :
Subject : RE: [agileanalysis] Any activity in this Group?
:-) Good to hear from you Chris! Although Chris might be drunk, his point isn't completely off. I'll be honest. I work alongside business analysts in agile contexts, and struggle with their thought processes at times. I consider myself an interaction designer. I work with end users and business stakeholders, talk with them about their goals, build models, think hard, and work to arrive at solutions that optimize business's return on investment while meeting user goals. I call that work design. The BAs I work with do very much the same work, only they refer to it as requirements capturing. I struggle with the term requirements capture vs. design. For me design implies some creativity and invention - and most importantly some responsibility. Requirements capture doesn't imply any of those things to me - sounds sort of like a passive thing that requires good listening and recording skills. Although I know that if I pick up any decent book on requirements work, I'll find the words creativity and invention in it - I just won't find the words design in it -at least not in reference to what the BA does. I sometimes wonder if that posture of elicitation and capture vs. a posture of responsible design isn't part of the key to their effectiveness - or lack thereof.
Although I'm not drunk, my plane is over 3 hours late and I'm ticked off and stuck at the airport. So if this sounds inflammatory to BAs - I'll blameUnited Airlines.
Cheers,-Jeff
From : David Wright
Reply-To :
Sent : Friday, March 31, 2006 9:58 AM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
In short, having Requirements first supports the choice of solution, which may not always be to design and develop something new.I can't recall where I first heard this mantra-like statement, but it has stayed with me:
"Re-Use before Buy, Buy before Build, Build for Re-Use".
Requirements are like blue-prints, especially those using models. If system delivery and software development (which are not always the same thing) are to move beyond being a craft to a real discipline, we have to stop starting with Design and know What to build before we decide How.
Dave Wright
>From: "Kent J. McDonald" mailto:kent@kentmcdonald.com
Reply-To: agileanalysis@yahoogroups.com>
To: agileanalysis@yahoogroups.com>
Subject: RE: [agileanalysis] Any activity in this Group?>
Date: Fri, 31 Mar 2006 21:13:11 -0600>>
Is it necessarily a bad thing that Software Development is a craft?
>-->Kent J. McDonald>kent@kentmcdonald.com>http://www.kentmcdonald.com>Words to lead by: Collaborate; Iterate; Serve the Team; Consider Context;>Practice Excellence; Reflect and Adapt; Deliver Value
From :
David Wright
Reply-To :
Sent :
Saturday, April 1, 2006 9:22 PM
To : agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
"Is it necessarily a bad thing that Software Development is a craft?"
A craft-work approach to delivery implies custom-made, low-volume and high-cost results. Shoes haven't made by cobblers for a century or two, and just because software is a relatively new and uniquely malleable product, this does not mean it won't and shouldn't be produced using engineering-based production methods. This will be the way software will become a product where quality is assumed, not just hoped for.
What implications does this have for programming as we know it? It will become less and less of a technical creation skill amd more of an assembly role, putting together software components to create systems.
(If that upsets any programmers reading this, well, I have been out drinking some single-malt tonight, so my opinions may be a little direct by this time of night.... :-) )Dave W
Tuesday, April 04, 2006
Agile falls short, says author
Software development concept hasn’t blossomed: McConnell
By: Paul Krill(31 Mar 2006)
From Computerworld Canada: www.itworldcanada.com
The article is at http://www.itworldcanada.com//Pages/Docbase/ViewArticle.aspx?ID=idgml-8e5499c3-e4fe-49ac-8230-9fa5a564512e
but you might have to register to read it.
Steve McConnell lists his worst ideas of Agile, my favourites being:
•Requirements are always changing.”[The] single most common source of changing requirements [is] requirements that were not significantly investigated in the first place,” said McConnell.
• Requirements can be gathered or they just drop out of the sky like manna from Heaven.
• Entrepreneurial companies cannot be afraid of risk.
• One single development approach will work best for all projects.
Mr. McConnell is a published author on software topics; while I don't know what his original views of Agile might have been, he has certainly laid a shot over the bow of agile proponents.
Comments, anyone?
By: Paul Krill(31 Mar 2006)
From Computerworld Canada: www.itworldcanada.com
The article is at http://www.itworldcanada.com//Pages/Docbase/ViewArticle.aspx?ID=idgml-8e5499c3-e4fe-49ac-8230-9fa5a564512e
but you might have to register to read it.
Steve McConnell lists his worst ideas of Agile, my favourites being:
•Requirements are always changing.”[The] single most common source of changing requirements [is] requirements that were not significantly investigated in the first place,” said McConnell.
• Requirements can be gathered or they just drop out of the sky like manna from Heaven.
• Entrepreneurial companies cannot be afraid of risk.
• One single development approach will work best for all projects.
Mr. McConnell is a published author on software topics; while I don't know what his original views of Agile might have been, he has certainly laid a shot over the bow of agile proponents.
Comments, anyone?
Friday, March 31, 2006
Discussion on Agile, and Methodologies in General, Part 3
From :
Kent J. McDonald
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 7:33 PM
To :
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry to hear you were under the weather. That seems to be going aroundhere as well. I've moved up the sections I am replying to and cutting therest out. Hope that's ok (want to keep the message from getting too long).
DAVEW....1) How much time (hours per day) do Agile developers need to be withcustomers/users? Finding available time on key people's schedules is aconstant challenge for me; I basically have to prepare ahead for a veryfocused 60 to 90 minutes that I might get a day (or every 2 days) to gatherrequirements. I often end up addressing multiple projects with differentbusiness people in parallel in order to keep productive. In fact, mycompany expects partcipation in multiple projects at the same time.
Kent... It depends on the environment. Reality dictates that you figure outwhat works within the constraints you are working in. Working on multipleprojects at the same time is not ideal, but I know it happens quite often.
-----------------------------------------------------------
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifactsshould ensure that what is delivered is of value, and no more; I don't havetime to produce content that is not used. ...and any good methodology andartifact set will evolve over time to capture what is required, and dropwhat is no longer required.
Kent...A good methodology is only part of the story. The real key is how do peopleimplement that methodology. Take the RUP for example. Rational decidedthat they were going to make the UP into a product, and wanted to make surethat they provided artifacts to cover as many different types of projects aspossible. The trouble is, more than a few people ignore the advice to craftthe methodology to fit the needs of that particular project and end up doingmore than they need because the methodology "requires" it. More often thennot, the "and drop what is no longer required" does not occur in practice.The ability to do that, to me, is a sign of a mature developmentorganization.
----------------------------------------------------------->
Kent... I actually think analyzing the business is doing more than creating the >requirements, it should also be about collaborating with the customers >to help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for thebusiness; if you have already started developing software, you have probablyselected the technical architecture and operating environment. How do youknow if you shouldn't have gone in a very different direction? Where do youmake the choice to re-use an existing system, or buy instead of build?
Kent...I'm not sure that I was implying that you started developing software. WhenI said "help them arrive at the best solution to their business problem." Iwas thinking things such as understanding what the problem really is andlooking at all possible approaches, which may not include a technologysolution. I should have also made a comment about helping the customerdetermine if they really have a problem, or if they are focusing on thewrong problem.
------------------------------------------------------------
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of aproject between delivering the best solution and delivering it on time isbest resolved as an external discussion between 2 people, rather than aninternal dilemna for one person... at least that's what works for me.
Kent... 2 Heads is always better than one. I just happen to be a believer that ifthose 2 heads are experienced in a variety of skill sets (with obviousspecialties in one or two fields) the result will be better becausecollaboration is more likely to happen vs when people only specialize andfeel the need to do extensive "Hand offs" between functions. Of course youcannot always get people that are able to and enjoy doing a variety ofdifferent tasks, but it is always something for which to strive.
--------------------------------------------------------------
DAVEWYes, methodologies and documented processes for any activity that producesdifferent deliverables each time (like Information Systems) should not betreated as written in stone. Certification is a long-standing approach tocreating and perpetuating a profession; in fact, there is an ISO standardfor doing it. Managers and HR directors for years have been telling me howimportant it is to 'act professional' and all, I think I would like toactually be recognized as one.
Kent... I don't think you have to be certified to "act professionally", and Isuspect that there are some people with certifications that do not always"act professionally." Certifications have their place, but they have theirflaws as well. My advice to Managers and HR would be to "use with caution."
Kent J. McDonaldkent@kentmcdonald.com
http://www.kentmcdonald.com
Words to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value
Kent J. McDonald
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 7:33 PM
To :
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry to hear you were under the weather. That seems to be going aroundhere as well. I've moved up the sections I am replying to and cutting therest out. Hope that's ok (want to keep the message from getting too long).
DAVEW....1) How much time (hours per day) do Agile developers need to be withcustomers/users? Finding available time on key people's schedules is aconstant challenge for me; I basically have to prepare ahead for a veryfocused 60 to 90 minutes that I might get a day (or every 2 days) to gatherrequirements. I often end up addressing multiple projects with differentbusiness people in parallel in order to keep productive. In fact, mycompany expects partcipation in multiple projects at the same time.
Kent... It depends on the environment. Reality dictates that you figure outwhat works within the constraints you are working in. Working on multipleprojects at the same time is not ideal, but I know it happens quite often.
-----------------------------------------------------------
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifactsshould ensure that what is delivered is of value, and no more; I don't havetime to produce content that is not used. ...and any good methodology andartifact set will evolve over time to capture what is required, and dropwhat is no longer required.
Kent...A good methodology is only part of the story. The real key is how do peopleimplement that methodology. Take the RUP for example. Rational decidedthat they were going to make the UP into a product, and wanted to make surethat they provided artifacts to cover as many different types of projects aspossible. The trouble is, more than a few people ignore the advice to craftthe methodology to fit the needs of that particular project and end up doingmore than they need because the methodology "requires" it. More often thennot, the "and drop what is no longer required" does not occur in practice.The ability to do that, to me, is a sign of a mature developmentorganization.
----------------------------------------------------------->
Kent... I actually think analyzing the business is doing more than creating the >requirements, it should also be about collaborating with the customers >to help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for thebusiness; if you have already started developing software, you have probablyselected the technical architecture and operating environment. How do youknow if you shouldn't have gone in a very different direction? Where do youmake the choice to re-use an existing system, or buy instead of build?
Kent...I'm not sure that I was implying that you started developing software. WhenI said "help them arrive at the best solution to their business problem." Iwas thinking things such as understanding what the problem really is andlooking at all possible approaches, which may not include a technologysolution. I should have also made a comment about helping the customerdetermine if they really have a problem, or if they are focusing on thewrong problem.
------------------------------------------------------------
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of aproject between delivering the best solution and delivering it on time isbest resolved as an external discussion between 2 people, rather than aninternal dilemna for one person... at least that's what works for me.
Kent... 2 Heads is always better than one. I just happen to be a believer that ifthose 2 heads are experienced in a variety of skill sets (with obviousspecialties in one or two fields) the result will be better becausecollaboration is more likely to happen vs when people only specialize andfeel the need to do extensive "Hand offs" between functions. Of course youcannot always get people that are able to and enjoy doing a variety ofdifferent tasks, but it is always something for which to strive.
--------------------------------------------------------------
DAVEWYes, methodologies and documented processes for any activity that producesdifferent deliverables each time (like Information Systems) should not betreated as written in stone. Certification is a long-standing approach tocreating and perpetuating a profession; in fact, there is an ISO standardfor doing it. Managers and HR directors for years have been telling me howimportant it is to 'act professional' and all, I think I would like toactually be recognized as one.
Kent... I don't think you have to be certified to "act professionally", and Isuspect that there are some people with certifications that do not always"act professionally." Certifications have their place, but they have theirflaws as well. My advice to Managers and HR would be to "use with caution."
Kent J. McDonaldkent@kentmcdonald.com
http://www.kentmcdonald.com
Words to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value
Wednesday, March 29, 2006
Discussion on Agile, and Methodologies in General, Part 2
From :
David Wright
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 6:52 PM
To :
agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry, been under the weather for a few days... so let me review and return the favour! DaveW>>
>The key to your statement above is *formal*. Agile methods recognize the>importance of requirements just as much as other methodologies, they just>have the philosphy that given a choice between recording the key points and>then having the ability to collaborate directly with the customer/user when>software development is underway vs documenting everything and throwing the>document over the wall to the developers, they would choose the former. We>all know that real life fits somewhere in the middle. A common agile>requirement mechanism is the user story, which typically consists of a>statement in the form AS A I Want so that>. Where the details are expressed as acceptance tests>so that the requirement artifact can provide multiple uses. Agile>approaches also discourage requirements inventory where all of the>requirements for a project are fully elaborated at the beginning of the>project. Rather they suggest that the requirements are listed at a very>high level at the beginning of the project for scoping purposes, then they>are elaborated upon during the iteration in which that particular chunk of>functionality is built.>
DAVEW....1) How much time (hours per day) do Agile developers need to be with customers/users? Finding available time on key people's schedules is a constant challenge for me; I basically have to prepare ahead for a very focused 60 to 90 minutes that I might get a day (or every 2 days) to gather requirements. I often end up addressing multiple projects with different business people in parallel in order to keep productive. In fact, my company expects partcipation in multiple projects at the same time.2) High-level Requirements are common when scoping a project, either as "I need..." or "The solution must..." statements. I am currently working on a project where high-level requirements were used to define 4 separate phases. Benefits and costs estimated for each phase were used to prioritize the work, and I am now working with the business on detailed requirements for the first phase. I will be feeding those requirements to the assigned designer as they stabilize, who will start development of the first phase while I proceed to detailing the requirements for the second phase, and so on.WIll the results be 'formal'? I suppose, since they will be documented, communicated and approved, and form a baseline for development that virtually eliminates mis-understandings..
>>>>>>>I think if you look at software development overall (including the >Analysis,>development, testing, etc.) from a value perspective, you may find yourself>asking how rigorous should your requirements activities be in order to>provide the information that developers need without performing non value>added work. Where that line falls varies between teams and projects.>
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifacts should ensure that what is delivered is of value, and no more; I don't have time to produce content that is not used. ...and any good methodology and artifact set will evolve over time to capture what is required, and drop what is no longer required.......
"Business Analyst". It is not bad title, and it is one I>have had off and on since 1984, and it does describe what we do --- analyze>the business --- but not what we create: the Requirements.>>>I actually think analyzing the business is doing more than creating the>requirements, it should also be about collaborating with the customers to>help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for the business; if you have already started developing software, you have probably selected the technical architecture and operating environment. How do you know if you shouldn't have gone in a very different direction? Where do you make the choice to re-use an existing system, or buy instead of build?
>>.....I think this is part of the reason that, when some companies hire a Business>Analyst, they believe they are also getting a Project Manager and Software>Tester (the latter better known as Quality Assurance Analysts). I have also>met Business Analysts who would agree with this. I would certainly agree>that having multiple skills will make you more marketable, but it should be>clear that these are three separate skill-sets that are not always>compatible.>
>I would be one of those BA's that agree with that statement.>
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of a project between delivering the best solution and delivering it on time is best resolved as an external discussion between 2 people, rather than an internal dilemna for one person... at least that's what works for me.>>
<snip>>>....................................................If you consider yourself a Business>Analyst, it is imperative you seek out the IIBA, and highly recommended >that>you join.>>
>The good thing about the IIBA is that it is provide a source for BA's to go>for information about Business Analysis and providing a network for people>to expand their knowledge about the subject.>>I would caution about putting too much stock in certifications and BOK's.>Certifications indicate someone's ability to learn one set of knowledge>about a given area and take a test on it, they do not provide a reliable>measure of that person's ability in the subject area that they are being>certified on. BOK's are great because they provide a compiled set of some>knowledge about an area. They become dangerous when people start to>interpret that set of knowledge as *the only correct* thinking for a given>field, and people forget that items in the BOK do not work equally well in>all situations.>>I would agree that you should join the IIBA if you consider yourself a BA >(I>myself am a member). Just remember what a certification is really telling>you, and remember that just because some practices do not find their way>into the BOK does not mean that they are not correct or useful in certain>situations.> >
DAVEWYes, methodologies and documented processes for any activity that produces different deliverables each time (like Information Systems) should not be treated as written in stone. Certification is a long-standing approach to creating and perpetuating a profession; in fact, there is an ISO standard for doing it. Managers and HR directors for years have been telling me how important it is to 'act professional' and all, I think I would like to actually be recognized as one.>
Dave Wright
David Wright
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 6:52 PM
To :
agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry, been under the weather for a few days... so let me review and return the favour! DaveW>>
DAVEW....1) How much time (hours per day) do Agile developers need to be with customers/users? Finding available time on key people's schedules is a constant challenge for me; I basically have to prepare ahead for a very focused 60 to 90 minutes that I might get a day (or every 2 days) to gather requirements. I often end up addressing multiple projects with different business people in parallel in order to keep productive. In fact, my company expects partcipation in multiple projects at the same time.2) High-level Requirements are common when scoping a project, either as "I need..." or "The solution must..." statements. I am currently working on a project where high-level requirements were used to define 4 separate phases. Benefits and costs estimated for each phase were used to prioritize the work, and I am now working with the business on detailed requirements for the first phase. I will be feeding those requirements to the assigned designer as they stabilize, who will start development of the first phase while I proceed to detailing the requirements for the second phase, and so on.WIll the results be 'formal'? I suppose, since they will be documented, communicated and approved, and form a baseline for development that virtually eliminates mis-understandings..
>>
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifacts should ensure that what is delivered is of value, and no more; I don't have time to produce content that is not used. ...and any good methodology and artifact set will evolve over time to capture what is required, and drop what is no longer required.......
"Business Analyst". It is not bad title, and it is one I>have had off and on since 1984, and it does describe what we do --- analyze>the business --- but not what we create: the Requirements.>>
DAVEWRequirements definition is crucial to selecting the best solution for the business; if you have already started developing software, you have probably selected the technical architecture and operating environment. How do you know if you shouldn't have gone in a very different direction? Where do you make the choice to re-use an existing system, or buy instead of build?
>>.....I think this is part of the reason that, when some companies hire a Business>Analyst, they believe they are also getting a Project Manager and Software>Tester (the latter better known as Quality Assurance Analysts). I have also>met Business Analysts who would agree with this. I would certainly agree>that having multiple skills will make you more marketable, but it should be>clear that these are three separate skill-sets that are not always>compatible.>
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of a project between delivering the best solution and delivering it on time is best resolved as an external discussion between 2 people, rather than an internal dilemna for one person... at least that's what works for me.>>
<snip>>>....................................................If you consider yourself a Business>Analyst, it is imperative you seek out the IIBA, and highly recommended >that>you join.>>
DAVEWYes, methodologies and documented processes for any activity that produces different deliverables each time (like Information Systems) should not be treated as written in stone. Certification is a long-standing approach to creating and perpetuating a profession; in fact, there is an ISO standard for doing it. Managers and HR directors for years have been telling me how important it is to 'act professional' and all, I think I would like to actually be recognized as one.>
Dave Wright
Discussion on Agile, and Methodologies in General
I recently sent the following email to a Yahoo group I belong to on Agile Analysis...
It has been quiet at this group for some months now... anyone out there doing what they consider to be agile analysis on current/recent projects?I'll be honest, I am still skeptical on this topic... see http://businessanalysis56.blogspot.com/2006/01/information-system-requirements-still.html ...but I am still open to being persuaded.Dave W
..and ended up starting a conversation on the topic that started with the following reply from Kent Mcdonald:
David,I would say yes there are people doing what they consider to be agileanalysis on current/recent projects, they just don't happen to be posting tothis list. The most active discussion surrounding agile analysis typeactivities appear on the Agile Modeling list.(http://groups.yahoo.com/group/agilemodeling/) This list is moderated byScott Ambler who has done a lot of writing on Analysis related activities. Isuggest you read his writtings and join the mailing list. Based on readingyour blog post, I think you may find some of it interesting.
As a matter of fact, when I first started this list, I got a bit of pushbackasking if a list focusing on Agile Analysis was really necessary and whether it continued the fractionalization of the software development community.You can look back in the archives and follow the discussion. My thought basically was that we would "let the market decide" and based on your observation about traffic, they may have been right. None the less, I believe there still is value in talking about doing analysis in an agile manner. This has different meanings for different projects in different environments. In those environments that support full blown agile, that means developers working with customers directly. In environments thataren't quite ready for agile, that means that analysts collaborating with both developers and customers to make sure they are working with the customers to understand their needs and with the developers to understand what information they need to properly develop what the customer needs.
David, I read the blog entry that you referenced and had some thoughts. Ihope you don't mind that I replied to parts of it in this message.-----------------------------------------------------------------------------------------------------------------------If you are familiar with newer Agile or Extreme methods for developingsoftware, you will know that they disdain formal requirements, preferring towork directly with end-users to deliver software in small increments. Ibelieve that these methods are a natural reaction to software developers'long-standing frustrations with receiving poor, incorrect or no Requirementsto work with. Developers should be focused on creating software, and timethey spend trying to find out what they should develop, or developing thewrong software, is a waste of their valuable time.
The key to your statement above is *formal*. Agile methods recognize theimportance of requirements just as much as other methodologies, they justhave the philosphy that given a choice between recording the key points andthen having the ability to collaborate directly with the customer/user whensoftware development is underway vs documenting everything and throwing thedocument over the wall to the developers, they would choose the former. Weall know that real life fits somewhere in the middle. A common agilerequirement mechanism is the user story, which typically consists of astatement in the form AS A I Want so that. Where the details are expressed as acceptance testsso that the requirement artifact can provide multiple uses. Agileapproaches also discourage requirements inventory where all of therequirements for a project are fully elaborated at the beginning of theproject. Rather they suggest that the requirements are listed at a veryhigh level at the beginning of the project for scoping purposes, then theyare elaborated upon during the iteration in which that particular chunk offunctionality is built.
Why do Developers get poor Requirements? There is often no common disciplineor accepted practices being used when creating Requirements in a softwaredevelopment project; but, if Developers do get good Requirements, theresulting software is better is almost every way, primarily that it willmeet the needs of the business that requested and paid for it.
Agree here.
As a discipline, Project Management faced similar problems in the past, buttoday its practitioners all recognize common approaches and techniques: WorkBreakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, andmore. They also have seen their work coalescing as a profession through thePMI and its PMP certification. Project Managers also started with theadvantage that their job title actually describes what they do - ProjectManagers manage projects. Software Developers have the same advantages,although the wide variety of languages and environments mean no singlecertification can be had.
There are positives and negatives to being considered a "profession" and tocertification. More comments on that later.
So, I think Model Driven Architecture will play an increasing role overtime; in the mean-time, if it shows that methods for producing requirementscan be rigorous enough (good enough) to generate code, then why not use suchmethods to document Requirements for developers to use for the rest ofsoftware development
I think if you look at software development overall (including the Analysis,development, testing, etc.) from a value perspective, you may find yourselfasking how rigorous should your requirements activities be in order toprovide the information that developers need without performing non valueadded work. Where that line falls varies between teams and projects.
An ancient Chinese saying tells us that 'All wisdom begins with callingthings by their right names.' So, the job of gathering and documentingRequirements needs a Name. I am being somewhat disingenuous here, as thereis well-known job name already, but it is not always used the same way; I amtalking about the "Business Analyst". It is not bad title, and it is one Ihave had off and on since 1984, and it does describe what we do --- analyzethe business --- but not what we create: the Requirements.
I actually think analyzing the business is doing more than creating therequirements, it should also be about collaborating with the customers tohelp them arrive at the best solution to their business problem.
I think this is part of the reason that, when some companies hire a BusinessAnalyst, they believe they are also getting a Project Manager and SoftwareTester (the latter better known as Quality Assurance Analysts). I have alsomet Business Analysts who would agree with this. I would certainly agreethat having multiple skills will make you more marketable, but it should beclear that these are three separate skill-sets that are not alwayscompatible.
I would be one of those BA's that agree with that statement.
The last question about the Business Analyst job is the importance ofspecific business knowledge and experience, aside from analytical andrequirements-related skills. Again, companies will ask for Business Analysiswith experience in Supply Chain Logistics or Life Insurance or ExpressDelivery or Human Resources or Commercial Credit or Finance/Accounting.Well, I have worked in all of these business 'domains' and more withoutneeding to change how I do my job. In the end, the business people beingserved by Information Systems - executives/sponsors, managers, end-users ---are the ones who need to know their business; what I need to do is be ableto quickly understand their business in order to gather and document theirInformation Systems Requirements.
Agree completely. It has also been my experience that someone who does notnecessarily have a long history in a particular industry, but is able toquickly pick it up, is often not influenced by filters, and would be morelikely to ask those probing questions that could lead to groundbreakingchanges in how the business works based on borrowing ideas from otherindustries.
Finally, you may ask how technical a Business Analyst needs to be. My basicrecommendation is you need to understand what technology can do in order todeliver the solutions that meet the Requirements, but you don't need to knowhow the technology will do it. I started as a PL1 and IMS programmer beforemoving to Business Analysis; since then, I have done Requirements forsystems implemented on mainframes, minis and PCs, using environments fromTSO to OS2 to Windows to Browsers; again, the technology to be used to didnot really change how I did my job; in fact, the best Requirements are thosethat can be implemented in multiple technical environments.
Knowing the technology certainly does not hurt. And sometimes it's nice toknow when a technologist is giving you bad information, especially whenworking with the developers to realize the requirements.
And about certification for Business Analysts, we can now look to theInternational Institute of Business Analysis, at www.iiba.com . It is beingcreated and developed following the appropriate ISO standard forprofessional certification organizations and, much like the PMI, isdeveloping a Body of Knowledge for Business Analysis andcertification/testing based on that BOK. If you consider yourself a BusinessAnalyst, it is imperative you seek out the IIBA, and highly recommended thatyou join.
The good thing about the IIBA is that it is provide a source for BA's to gofor information about Business Analysis and providing a network for peopleto expand their knowledge about the subject.I would caution about putting too much stock in certifications and BOK's.Certifications indicate someone's ability to learn one set of knowledgeabout a given area and take a test on it, they do not provide a reliablemeasure of that person's ability in the subject area that they are beingcertified on. BOK's are great because they provide a compiled set of someknowledge about an area. They become dangerous when people start tointerpret that set of knowledge as *the only correct* thinking for a givenfield, and people forget that items in the BOK do not work equally well inall situations.I would agree that you should join the IIBA if you consider yourself a BA (Imyself am a member). Just remember what a certification is really tellingyou, and remember that just because some practices do not find their wayinto the BOK does not mean that they are not correct or useful in certainsituations.
Looking forward to anyone's thoughts.Kent J. McDonaldkent@kentmcdonald.comhttp://www.kentmcdonald.comWords to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value-----Original Message-----
It has been quiet at this group for some months now... anyone out there doing what they consider to be agile analysis on current/recent projects?I'll be honest, I am still skeptical on this topic... see http://businessanalysis56.blogspot.com/2006/01/information-system-requirements-still.html ...but I am still open to being persuaded.Dave W
..and ended up starting a conversation on the topic that started with the following reply from Kent Mcdonald:
David,I would say yes there are people doing what they consider to be agileanalysis on current/recent projects, they just don't happen to be posting tothis list. The most active discussion surrounding agile analysis typeactivities appear on the Agile Modeling list.(http://groups.yahoo.com/group/agilemodeling/) This list is moderated byScott Ambler who has done a lot of writing on Analysis related activities. Isuggest you read his writtings and join the mailing list. Based on readingyour blog post, I think you may find some of it interesting.
As a matter of fact, when I first started this list, I got a bit of pushbackasking if a list focusing on Agile Analysis was really necessary and whether it continued the fractionalization of the software development community.You can look back in the archives and follow the discussion. My thought basically was that we would "let the market decide" and based on your observation about traffic, they may have been right. None the less, I believe there still is value in talking about doing analysis in an agile manner. This has different meanings for different projects in different environments. In those environments that support full blown agile, that means developers working with customers directly. In environments thataren't quite ready for agile, that means that analysts collaborating with both developers and customers to make sure they are working with the customers to understand their needs and with the developers to understand what information they need to properly develop what the customer needs.
David, I read the blog entry that you referenced and had some thoughts. Ihope you don't mind that I replied to parts of it in this message.-----------------------------------------------------------------------------------------------------------------------If you are familiar with newer Agile or Extreme methods for developingsoftware, you will know that they disdain formal requirements, preferring towork directly with end-users to deliver software in small increments. Ibelieve that these methods are a natural reaction to software developers'long-standing frustrations with receiving poor, incorrect or no Requirementsto work with. Developers should be focused on creating software, and timethey spend trying to find out what they should develop, or developing thewrong software, is a waste of their valuable time.
Why do Developers get poor Requirements? There is often no common disciplineor accepted practices being used when creating Requirements in a softwaredevelopment project; but, if Developers do get good Requirements, theresulting software is better is almost every way, primarily that it willmeet the needs of the business that requested and paid for it.
As a discipline, Project Management faced similar problems in the past, buttoday its practitioners all recognize common approaches and techniques: WorkBreakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, andmore. They also have seen their work coalescing as a profession through thePMI and its PMP certification. Project Managers also started with theadvantage that their job title actually describes what they do - ProjectManagers manage projects. Software Developers have the same advantages,although the wide variety of languages and environments mean no singlecertification can be had.
I think if you look at software development overall (including the Analysis,development, testing, etc.) from a value perspective, you may find yourselfasking how rigorous should your requirements activities be in order toprovide the information that developers need without performing non valueadded work. Where that line falls varies between teams and projects.
An ancient Chinese saying tells us that 'All wisdom begins with callingthings by their right names.' So, the job of gathering and documentingRequirements needs a Name. I am being somewhat disingenuous here, as thereis well-known job name already, but it is not always used the same way; I amtalking about the "Business Analyst". It is not bad title, and it is one Ihave had off and on since 1984, and it does describe what we do --- analyzethe business --- but not what we create: the Requirements.
I think this is part of the reason that, when some companies hire a BusinessAnalyst, they believe they are also getting a Project Manager and SoftwareTester (the latter better known as Quality Assurance Analysts). I have alsomet Business Analysts who would agree with this. I would certainly agreethat having multiple skills will make you more marketable, but it should beclear that these are three separate skill-sets that are not alwayscompatible.
Finally, you may ask how technical a Business Analyst needs to be. My basicrecommendation is you need to understand what technology can do in order todeliver the solutions that meet the Requirements, but you don't need to knowhow the technology will do it. I started as a PL1 and IMS programmer beforemoving to Business Analysis; since then, I have done Requirements forsystems implemented on mainframes, minis and PCs, using environments fromTSO to OS2 to Windows to Browsers; again, the technology to be used to didnot really change how I did my job; in fact, the best Requirements are thosethat can be implemented in multiple technical environments.
And about certification for Business Analysts, we can now look to theInternational Institute of Business Analysis, at www.iiba.com . It is beingcreated and developed following the appropriate ISO standard forprofessional certification organizations and, much like the PMI, isdeveloping a Body of Knowledge for Business Analysis andcertification/testing based on that BOK. If you consider yourself a BusinessAnalyst, it is imperative you seek out the IIBA, and highly recommended thatyou join.
Looking forward to anyone's thoughts.Kent J. McDonaldkent@kentmcdonald.comhttp://www.kentmcdonald.comWords to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value-----Original Message-----
Subscribe to:
Posts (Atom)