views:

312

answers:

3

At my current employer we generally adopt the old-school approach of writing a traditional functional requirements specification and then performing a full tech design. If the app is big then we break it into smaller chunks and attack it a chunk at a time but following the same basic pattern.

This technique has served me well over the years. With use-case modelling it seems that you need to gather pretty much the same information, it is just organised differently.

So my question is this: what the tangible benefits of following a use-case driven approach to software development?

+1  A: 

Done incorrectly there are no advantages. In this approach, one draws a bunch of pictures of use cases and pretends that by using UML -- the Useless Modelling Language -- you've somehow done design.

Done correctly, Use Cases are a good high level way of thinking about how to flesh out a traditional functional specification, in terms of:

What exactly is the user trying to accomplish in this case.

How must the software support this.

How should the software support this.

I see good use cases as simply a way of questioning stakeholders for input into the functional spec.

John Lockwood
+1  A: 

You are right - it's the same, but has a sexier name. In the 1980s I got SSADM certification (required for some large NGOs, like my at that time employer the BBC), and was suprised to find that you could map its processes fairly easily onto OO design concepts which I was already familiar with.

anon
+3  A: 

While we don't use a very formal use case approach I have found that use cases and the less formal user stories help you envision your product from the user point of view. In the end most of us write software for user that are not ourselves. Formulating use cases helps you get away from an internal view and focus on the outside view of the system that you are building.

In addition to that you get pre-packaged production units to work on for the agile work flow. If you can implement one use case there is one piece of functionality that you system fulfills.

I admit though that I do not have a lot of experience doing classic design upfront requirements gathering. I am sure there are other people that can give you a better answer to this question

Harald Scheirich
Moreover, having actors in your diagram helps making sure you are building functionnalities users want and need. Here we throw functionnalities to trash once in a while when we realise no actor would use it.
Danny T.
+1 for mentioning the "user point of view". The single biggest mistake one could do on a software project is not think from the customer's point of view and end up with a working but unusable system.
Flavius Stef