Do you have a trick or special technique you use to elicit the best information possible when you are in the requirement gathering stage of a project?
Do you depend on your own tacit knowledge more than explicit knowledge? Does your organization or are you expected to follow the rules as defined by explicit knowledge?
Discussion on:
View:
Show:
The difficulty is not in creating requirements from a problem domain, it is in recreating the problem domain from the requirements. Requirements are not lines connecting dots of the problem domain, rather the problem domain is an image and the requirements are dots representing tiny pieces of the image. How many dots and which specific dots are necessary to recreate the image? How many requirements and which specific requirements are necessary to describe the problem to be solved?
The difficulty with defining requirements is that there is no clear determination of how many are sufficient. The first indication of whether the requirements were sufficient is when the software, the developers' interpretation of the requirements, hits the users. This leads to the famous cost of change / cost of correction curve. What is not realized, though, that extending the length of requirement gather increases the cost to address wrong or omitted requirements, but rarely results in the identification new requirements or the correction of mistaken requirements.
There are two things one can do to combat this difficulty.
One, eliminate the middle man. Get the development team out into the users' environment. Seeing the actual work provides an immense amount of information concerning the characterisitcs of automation.
Two, use many, small iterations. By keeping the scope of an iteration small, it becomes easier to fully communicate the needs to be addressed. By keeping the duration of the iteration small, it reduces the cost to address miscommunications.
It is actually quite easy to identify requirements or "exlicit knowledge." The difficulty is recreating the problem area or "tacit knowledge" from these requirements.
The difficulty with defining requirements is that there is no clear determination of how many are sufficient. The first indication of whether the requirements were sufficient is when the software, the developers' interpretation of the requirements, hits the users. This leads to the famous cost of change / cost of correction curve. What is not realized, though, that extending the length of requirement gather increases the cost to address wrong or omitted requirements, but rarely results in the identification new requirements or the correction of mistaken requirements.
There are two things one can do to combat this difficulty.
One, eliminate the middle man. Get the development team out into the users' environment. Seeing the actual work provides an immense amount of information concerning the characterisitcs of automation.
Two, use many, small iterations. By keeping the scope of an iteration small, it becomes easier to fully communicate the needs to be addressed. By keeping the duration of the iteration small, it reduces the cost to address miscommunications.
It is actually quite easy to identify requirements or "exlicit knowledge." The difficulty is recreating the problem area or "tacit knowledge" from these requirements.
I think that fundamentally we agree that the idea of doing broad based,good requirements for an entire system is essentially impossible.
I think that we may disagree about whether the information loss comes on the side of the conversion into explicit knowledge (requirements) or in the expansion of requirements (explicit knowledge) into a final product.
On this point, I may disagree but I doubt that I care. While there is psychological evidence that we struggle to move information between different centers of operation within our brain and the conversion of tacit to explicit knowledge necessarily hits this constraint, at the end of the day we're in the same place.
My view is simply that we need to look at explicit knowledge (requirements) as a skeleton upon which tacit knowledge is hung. Much like our own bodies.
I think that we may disagree about whether the information loss comes on the side of the conversion into explicit knowledge (requirements) or in the expansion of requirements (explicit knowledge) into a final product.
On this point, I may disagree but I doubt that I care. While there is psychological evidence that we struggle to move information between different centers of operation within our brain and the conversion of tacit to explicit knowledge necessarily hits this constraint, at the end of the day we're in the same place.
My view is simply that we need to look at explicit knowledge (requirements) as a skeleton upon which tacit knowledge is hung. Much like our own bodies.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
