About 3 or 4 years ago, we decided Use Cases where the way to document system requirements. RUP says to do this so let’s do it.
Here are some of the problems.
1. No one knows how to write use cases. They are very difficult to document all the details of the requirements.
2. There were no standard ways to write them.
3. The developers end up providing the content and the analysts become technical writers.
4. They take so long to write. The amount of thrashing over little details, formatting and what the system already does goes on for hours. I have seen 2 hour meetings that completed one use case to only change later or be dropped from scope.
5. Maintenance is almost impossible.
6. On some projects, they actually did Business Requirements Specs first and then duplicated the information in use case format. (Months of requirement refinements)
7. Everyone interprets them differently. QA opens defects because the code is not doing what they think it should. Designers create designs that do not really capture what the customer wanted. Developers argue over the meaning of the requirement. All of these problems go back to the customer, what did you mean by this. Even worse, the customer thinks how could I spend this much money to develop the use cases and they still have questions. I could go on and on.
8. There wasn't any formal training. Everyone had the purple book. That was it.
What I realized is we are abusing the use cases. You do not need detailed use cases that are four pages long. What you need is to build trust with your customer and have a collaborative team.
Leaders need to earn the trust of the customer. You only need high level requirements documents. You just need something that you can estimate and understand the goal. If you are doing detailed Use Cases, show the customer their ROI on the document thrashing. Tell them you can save them time and money, they will listen. Ask them to let you take one feature and deliver it your way. See how it works.
The customer needs to understand their role in the project. They have to review the work, expect new things to be added, things can be removed, things can change and evolve the feature over an iteration or two.
The customer must to be comfortable with just focusing on the highest priority items and worry about defining the other features later, IF AT ALL. Focus on a few highest priority Use Cases only and just define the high level user interactions. If you are doing many extensions, you are heading in the wrong direction.
Before you go down this road, you need buy in from the team. They can't bicker over the details. They have to be comfortable with knowing everything is not documented but does it met the spirit of the requirement. Your testers will have a hard time with this, if they are used to fully dressed use case. They generally do not like abstract thinking. They like black or white. It requires the team to understand hand off and forget is not good. The team has to collaborate and be open to this new view.
I do not need to spend too much more time on why detailed documents are expensive, hard to maintain, almost always wrong and simply not necessary. It is pretty obvious. I found a good source of this information in the links below.
All of this is possible, if leaders can set customer expectations, articulate why their ROI is bad and lead the team away from detailed docs to collaborative thinking.
http://www.ddj.com/architect/184415814
http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm#ObtainManagementSupport http://www.agilemodeling.com/essays/agileDocumentation.htm
Here are some of the problems.
1. No one knows how to write use cases. They are very difficult to document all the details of the requirements.
2. There were no standard ways to write them.
3. The developers end up providing the content and the analysts become technical writers.
4. They take so long to write. The amount of thrashing over little details, formatting and what the system already does goes on for hours. I have seen 2 hour meetings that completed one use case to only change later or be dropped from scope.
5. Maintenance is almost impossible.
6. On some projects, they actually did Business Requirements Specs first and then duplicated the information in use case format. (Months of requirement refinements)
7. Everyone interprets them differently. QA opens defects because the code is not doing what they think it should. Designers create designs that do not really capture what the customer wanted. Developers argue over the meaning of the requirement. All of these problems go back to the customer, what did you mean by this. Even worse, the customer thinks how could I spend this much money to develop the use cases and they still have questions. I could go on and on.
8. There wasn't any formal training. Everyone had the purple book. That was it.
What I realized is we are abusing the use cases. You do not need detailed use cases that are four pages long. What you need is to build trust with your customer and have a collaborative team.
Leaders need to earn the trust of the customer. You only need high level requirements documents. You just need something that you can estimate and understand the goal. If you are doing detailed Use Cases, show the customer their ROI on the document thrashing. Tell them you can save them time and money, they will listen. Ask them to let you take one feature and deliver it your way. See how it works.
The customer needs to understand their role in the project. They have to review the work, expect new things to be added, things can be removed, things can change and evolve the feature over an iteration or two.
The customer must to be comfortable with just focusing on the highest priority items and worry about defining the other features later, IF AT ALL. Focus on a few highest priority Use Cases only and just define the high level user interactions. If you are doing many extensions, you are heading in the wrong direction.
Before you go down this road, you need buy in from the team. They can't bicker over the details. They have to be comfortable with knowing everything is not documented but does it met the spirit of the requirement. Your testers will have a hard time with this, if they are used to fully dressed use case. They generally do not like abstract thinking. They like black or white. It requires the team to understand hand off and forget is not good. The team has to collaborate and be open to this new view.
I do not need to spend too much more time on why detailed documents are expensive, hard to maintain, almost always wrong and simply not necessary. It is pretty obvious. I found a good source of this information in the links below.
All of this is possible, if leaders can set customer expectations, articulate why their ROI is bad and lead the team away from detailed docs to collaborative thinking.
http://www.ddj.com/architect/184415814
http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm#ObtainManagementSupport http://www.agilemodeling.com/essays/agileDocumentation.htm
Comments