The Old Joel on Software Forum: Part 4 (of 5) - The RUP, Features and Vision Docs

The RUP, Features and Vision Docs

Our company is pretty much a design agency so solid technically methodologies are for the most part non existent, although this is fine for simple microsites, it becomes a problem when you enter the world of integrated systems and complicated functionality.

I have used the RUP over the last couple of years and generally find it all to pervasive to get through small to medium projects, I do however like some of the structure and processes that it can bring to a project.

The problem I have at this stage is using features and the vision document.

Features!! what are they? RUP says they should have a type of requirement but then they are a requirement that should be managed like any other requirement. I understand that a feature represents the end game that you want to get to, so what will the system do to enable a basic user "NEED". e.g.
Need: Saftey is key in the design of this vehicle and so the driver must be able to stop in a safe manner under any circumstance.
Feature: Vechicle will have ABS

My understanding from this point would be to elaborate on the feature and start to develop both the business and technical requirements.

The problem is explaining the difference between feature and requirement and actually getting a client to buy into the concept, they will say "we already know this, this is a waste of time.
Can you just call them requirements from the outset and give them an attribute of parent and then sub reqs are developed from those?

The Vision document, well some say a 1 pager and some say it is a document that grows as the project develops. Both ideas have goods points, the question I have is do you spin off a separate requirements document and later the functional specicifation that contains the techy reqs or do you just keep the reqs in the vision document?

The purpose in our organisation that I see real value in using the vision doc is that both statagey and technology have a single point to put info, in some cases there is a lot of dependancy between the two.

I guess the key problem I have terminology, as an analyst I take these concepts for grnated but get nailed when try to get other departments involved.

Any comments??

Regards,

Anthony.

Anthony
Thursday, April 8, 2004

Your approach seems backwards.

If you say: "The vehicle will have ABS brakes", that is not a requirement. That is a design decision.

The requirement is: "The vehicle needs to stop quickly". It could be done with a length of rope and an anchor, if that satisfied the customer. Specifying ABS brakes crosses the line into design.

Since you're specifying the design first and then developing business and technical requirements from this, isn't that backwards?

I'd also say that if you need to expend energy to get a client to "buy into" a concept, you may not be addressing his business needs. Why should the customer have to buy into anything?

I think you're worrying too much about labels. Capture what the customer really wants, in Swahili if necessary.

anon
Thursday, April 8, 2004

Vision doc:

What is the problem ? (that's why they NEED your solution)

"The problem of <describe the problem> affects <who> and results in <lots of problems>. The benefits of a solution (ours of course :-)) are: <list of benefits>"

We will solve your problem through:

- list of "features"

e.g.

- there will be support for search
- ability to maintain user profiles
- we will use the company graphical guidelines
- storage has to keep 2 years of logging
- support for on-line payments
- ...

Those entries are "features", not detailed enough but that's how people talk when they try to approach and solve the problem.

They should be baselined (what's to keep, what's to left out).

Use priority (like : must, should, could, won't - have)

Customer will tell you the priorities

You as a team will tell the effort & risk

Then out of that, you can make a commitment for a given price (or prestudy project if too risky).

Out of the features, software requirements will flow (detailed use cases, UI, logging, workflow, security, performance etc). As well as some design constraints put on you.

All of the "Features", "software requirements" & "design constraints" are "requirements".

Just that "Features" lead to "software requirements" and "design constraint" limit your choice of technologies in the solution most of the time.

But, all in all, create a GUI prototype, it's what works with the users...

Philippe Back
Thursday, April 8, 2004