Recently I have been involved in collecting requirements for two separate activities; both standards activities though. One is the Service Oriented Architecture Reference Architecture and the other is the Rules Interchange Format WG.
It is interesting how difficult it can be to get technical people to understand what is really meant by requirements; although my experience with the two groups has been very different.
Being clear on requirements is, of course, critical in any venture. This is especially true for projects that are technically difficult. But the real trap, it seems to me, is where the participants already think that know how to solve the problem. For them, requirements capture is one of those necessary evils that the administration imposes but everyone will actually ignore.
Well, necessary or not, I intend to nail people's feet to the floor where requirements are concerned!
This is my first post on this blog. My intention is to cover those aspects of my work which have at least a partial public aspect to them; this means standards work at the moment. I am involved in three efforts currently: SOA, RIF and BPMN.
It is interesting how difficult it can be to get technical people to understand what is really meant by requirements; although my experience with the two groups has been very different.
Being clear on requirements is, of course, critical in any venture. This is especially true for projects that are technically difficult. But the real trap, it seems to me, is where the participants already think that know how to solve the problem. For them, requirements capture is one of those necessary evils that the administration imposes but everyone will actually ignore.
Well, necessary or not, I intend to nail people's feet to the floor where requirements are concerned!
This is my first post on this blog. My intention is to cover those aspects of my work which have at least a partial public aspect to them; this means standards work at the moment. I am involved in three efforts currently: SOA, RIF and BPMN.