The business needs to make commitments to the customer. Most projects I’ve seen commit in rather vague terms. For example: the system shall allow the applicant to enter all their foreign travel. Travel records are stored in reverse chronological order. This sounds simple enough.
I was just using software with those requirements and wow is it annoying. Those requirements were met, but as a user of the system I am far from thrilled. To add a new trip, you have to traverse to the end of the list of all trips, then you are prompted for a new trip. If that trip happens to be the one that is the most recent, the user is sent back to the beginning of the list. Confirmation and navigation dialogs keep popping up. This was very aggravating. (Guessing with no data) I bet a programmer was given vague requirements and came up with this implementation.
I often hear business analysts tell me that stories are too small, and that they don’t write acceptance tests, testers do. The programmers can work out the details. Analysts don’t want to be bothered with the details; the programmers can figure it out.
The problem with this is that even though the commitments are made at high level, the system will be built, evaluated and used at the detail level. To see if the system records foreign travel, someone will have to enter their travel records. The programmers will have invested gobs of time implementing and the analysts will get to try it out. Argh! It meets the requirements, but is almost unusable. The deadline is here. Ship it.
I think commitments will always be made at the high level. At the beginning of the project that is all we have, a vague idea of what is needed. It is critical to realize that acceptance and usage are done at a detailed level. Analysts can’t remove themselves from the more detailed requirements level and expect that they will have their expectations met. A big spec up front may not have made travel input process work any more smoothly. The nature or software development is iterative refinement.
I think it is an important realization that commitments are made at the high level, and usage and acceptance are made at the detailed level. Is this obvious? What do you think? Does this lend support for iterative development or does it make you want a bigger spec?
!commentForm
I was just using software with those requirements and wow is it annoying. Those requirements were met, but as a user of the system I am far from thrilled. To add a new trip, you have to traverse to the end of the list of all trips, then you are prompted for a new trip. If that trip happens to be the one that is the most recent, the user is sent back to the beginning of the list. Confirmation and navigation dialogs keep popping up. This was very aggravating. (Guessing with no data) I bet a programmer was given vague requirements and came up with this implementation.
I often hear business analysts tell me that stories are too small, and that they don’t write acceptance tests, testers do. The programmers can work out the details. Analysts don’t want to be bothered with the details; the programmers can figure it out.
The problem with this is that even though the commitments are made at high level, the system will be built, evaluated and used at the detail level. To see if the system records foreign travel, someone will have to enter their travel records. The programmers will have invested gobs of time implementing and the analysts will get to try it out. Argh! It meets the requirements, but is almost unusable. The deadline is here. Ship it.
I think commitments will always be made at the high level. At the beginning of the project that is all we have, a vague idea of what is needed. It is critical to realize that acceptance and usage are done at a detailed level. Analysts can’t remove themselves from the more detailed requirements level and expect that they will have their expectations met. A big spec up front may not have made travel input process work any more smoothly. The nature or software development is iterative refinement.
I think it is an important realization that commitments are made at the high level, and usage and acceptance are made at the detailed level. Is this obvious? What do you think? Does this lend support for iterative development or does it make you want a bigger spec?
!commentForm
Add Child Page to VagueCommitmentsVsDetailedDelivery