The ways and means in software design, build and test has progressed in leaps and bounds, in recent years. But when it comes to requirements management the IT community is still stuck in stone age. The formal approaches have been tried and have not worked tremendously well in business IT scenario. In one of my earlier posts (Requirements management is crucial) I have tried to analyze why a formal approach may not work well with business IT systems.
That being said, even in a semi formal ways and means that we use for requirements elicitation and management, we can do much better. For example, in my current project one of my business analyst (BA) was complaining about how users are inept at giving requirements. I have heard that umpteen times till now. What we in IT fail to understand is that, business users and IT are two different cultures trying to speak with each other. Not only cultures are different, even languages are different.
My BA holds a workshop to elicit requirements and use cases are his means. But business users concerned, have never heard of the use case terminologies. They cant specify their requirements in a structured way the use case expects them to. It will help them tremendously if we tell them beforehand what we expect from them, in what format. May be a mock excercise or a working example can do the trick.
Another thing we fail to understand is that there are multiple types of requirements, and use case focus on requirement tend to combine them together. There are strategic and policy level requirements, which would be common across multiple use cases, whereas operational requirements will be specific to use cases. When we mix all these together in a use case, we are more often than not going to get requirement changes, because users empowered to specify these different requirements are different. When operational user speaks on behalf of policy makers, he is making a mistake. And we in IT are encouraging him by pressurising him to specify his requirements faster!
We need to have better mechanisms to handle this than plain use cases. I sincerely wish there be more tools in this space to help my BA and users alike. Till then I have to devise manual means to identify operational requirements and strategic requirements, and manage their life-cycles seperately. It will then be clearer with my BA, why is he getting so many requirement changes.
These are my thoughts about various issues faced by an enterprise architect.
Here you will find thoughts related to enterprise architecture, TOGAF, SOA, BPM, MDA, MDD, Web 2.0 etc.
Showing posts with label Requirements. Show all posts
Showing posts with label Requirements. Show all posts
Saturday, December 30, 2006
Subscribe to:
Posts (Atom)
Showing posts with label Requirements. Show all posts
Showing posts with label Requirements. Show all posts
Saturday, December 30, 2006
Requirements elicitation
The ways and means in software design, build and test has progressed in leaps and bounds, in recent years. But when it comes to requirements management the IT community is still stuck in stone age. The formal approaches have been tried and have not worked tremendously well in business IT scenario. In one of my earlier posts (Requirements management is crucial) I have tried to analyze why a formal approach may not work well with business IT systems.
That being said, even in a semi formal ways and means that we use for requirements elicitation and management, we can do much better. For example, in my current project one of my business analyst (BA) was complaining about how users are inept at giving requirements. I have heard that umpteen times till now. What we in IT fail to understand is that, business users and IT are two different cultures trying to speak with each other. Not only cultures are different, even languages are different.
My BA holds a workshop to elicit requirements and use cases are his means. But business users concerned, have never heard of the use case terminologies. They cant specify their requirements in a structured way the use case expects them to. It will help them tremendously if we tell them beforehand what we expect from them, in what format. May be a mock excercise or a working example can do the trick.
Another thing we fail to understand is that there are multiple types of requirements, and use case focus on requirement tend to combine them together. There are strategic and policy level requirements, which would be common across multiple use cases, whereas operational requirements will be specific to use cases. When we mix all these together in a use case, we are more often than not going to get requirement changes, because users empowered to specify these different requirements are different. When operational user speaks on behalf of policy makers, he is making a mistake. And we in IT are encouraging him by pressurising him to specify his requirements faster!
We need to have better mechanisms to handle this than plain use cases. I sincerely wish there be more tools in this space to help my BA and users alike. Till then I have to devise manual means to identify operational requirements and strategic requirements, and manage their life-cycles seperately. It will then be clearer with my BA, why is he getting so many requirement changes.
That being said, even in a semi formal ways and means that we use for requirements elicitation and management, we can do much better. For example, in my current project one of my business analyst (BA) was complaining about how users are inept at giving requirements. I have heard that umpteen times till now. What we in IT fail to understand is that, business users and IT are two different cultures trying to speak with each other. Not only cultures are different, even languages are different.
My BA holds a workshop to elicit requirements and use cases are his means. But business users concerned, have never heard of the use case terminologies. They cant specify their requirements in a structured way the use case expects them to. It will help them tremendously if we tell them beforehand what we expect from them, in what format. May be a mock excercise or a working example can do the trick.
Another thing we fail to understand is that there are multiple types of requirements, and use case focus on requirement tend to combine them together. There are strategic and policy level requirements, which would be common across multiple use cases, whereas operational requirements will be specific to use cases. When we mix all these together in a use case, we are more often than not going to get requirement changes, because users empowered to specify these different requirements are different. When operational user speaks on behalf of policy makers, he is making a mistake. And we in IT are encouraging him by pressurising him to specify his requirements faster!
We need to have better mechanisms to handle this than plain use cases. I sincerely wish there be more tools in this space to help my BA and users alike. Till then I have to devise manual means to identify operational requirements and strategic requirements, and manage their life-cycles seperately. It will then be clearer with my BA, why is he getting so many requirement changes.
Subscribe to:
Posts (Atom)