Chris:
Regarding your article: You believe that more than one type of behavioral requirement is not needed in, for example, an all encompassing enterprise analysis. Data flow diagrams prove that false.
Tony
Tony,
First, let me emphasize that the purpose of my article was to interpret or paraphrase the BABOK in a more understandable way for those that were having troubles understanding the BABOK categorization of requirements. I'm not saying I fully agree with the the BABOK on this topic.
Second, I'm interested in what you have to say, but I'm not sure that I follow your response.
Sandy,
Very well stated!
So what does a taxonomy (classification) of business requirements actually give us that helps us better model systems and communicate them to the business and builders, etc?
I can't help thinking it smacks of analysis for the sake of it? I'm deeply suspicious of this push towards "requirements engineering". But I confess I haven't taken the time to look at it much.
Kimbo
Chris, Sandy, very good points. I agree that the different categories of requirements are typically uncovered in distinct areas of business analysis, which I alluded to wen I said "... it aligns the various types of requirements with different business analysis activities". The BABOK is still evolving and maturing but I think in many areas it has come a long way since V1.
Chris, I've had the privilege? of being on many projects that are multi-organizational collaborations, so I end up eliciting legitimately conflicting business and stakeholders requirements and work on finding where they align so they can work towards a solution that can meet as many shared needs as possible. It has been challenging but rewarding to figure out how to overcome areas where different groups have almost opposite goals.
On those projects I am not building out complete process definitions for each organization, and won't even necessarily know how each organization does its business in any real level of detail. These groups have sometimes contentious histories and have already been talking about solutions to a problem long before I'm engaged. I've come in when there are hundreds or thousands of requirements that are not tied to processes but describe what they want to occur in the future based on their needs. Classification of requirements has allowed me to help identify the key business and stakeholder requirements that are critical to the project and then clearly show groups where their goals and needs align and how differences can be overcome to arrive at a solution that will achieve the critical business requirements. It's also been handy to show disconnects between business and stakeholder requirements, and gives the people attached to a particular stakeholder requirement pause to think about if what they believe they need is really in line with overarching goals of the organization.
Back to Craig's original post - any other thoughts on what could be done with the Wikipedia page?
Although we've had fun debating the merits of the BABOK taxonomy within this forum, it still is the published knowledge book for the profession and the basis for professional certifications. On that basis, I would expect that the Wikipedia definition should reflect the BABOK definition - though it seems apparent that some further clarification and perhaps some examples would be helpful.
Since Wikipedia articles are expected to cite published / authoritative sources for information, should we be looking for additional reference sources that would expand upon the basic BABOK definitions? There should also be linked references to related topics such as 'enterprise analysis' and 'requirements analysis' that align to BABOK as well, since those are needed to fully understand the requirements definition. And if the BABOK Business Requirement definition is used, then of course enties would be needed for Stakeholder Requirements and Solution Requirements.
The definition of requirements should also not prescribe any format or type of documentation as 'standard' or 'common', since there are a number of factors that could go into the choice of format for any given project. It would be better to just remove this content, or to list the different formats available (for 'Solution Requirements' class).
brought to you by enabling practitioners & organizations to achieve their goals using: