Sparx Systems Forum

Discussion => Uml Process => Topic started by: sargasso on March 04, 2004, 05:32:41 pm

Title: "Alternative" requirements
Post by: sargasso on March 04, 2004, 05:32:41 pm
I have not come across this before and thought I would put it to you folks for some input.

We have situation where the client has specified a set of alternative requirements and asked for input as to the impacts and costs of each alternative.

By way of example, one of the primary requirements is that a webserver failover feature be implemented that includes the need to mirror some active files between two file systems.

The (very reasonable) client has suggested that we could mirror at two levels
- total mirroring whereby the synchronization is done at a periodicity less than the heartbeat period for the failover
- occasional mirroring done at a less frequent interval, say every 30 minutes.

They have asked for infomational material regarding the alternatives in order to make a decision on which way they want to go.

My problem is "how to model alternative requirments".  Each of the scenarios above has implications that affect subsequent requirements and on the use case, component and deployment models.

b.t.w. we are using external requirments at this stage of the project.

Has anyone had a similar experience and can you offer your "best way" to build a set of models to represent the impact of the alternatives?

Title: Re: "Alternative" requirements
Post by: JourneymanDave on March 04, 2004, 08:37:39 pm
Great question.  I would argue that w/o a reasonably firm set of requirements, it's not possible to model a system  because of the lack of traceability from the requirements through to the realized elements of the system.

- and therefore that both of these alternate sets of requirements cannot be modeled within one model (redundant, I know).  I think it may take two, which is probably a case for making only a high-level pass at this point.  

It sounds like the client's trying to be reasonable, and by all means you want to reciporicate.  Is it unreasonable (or cost prohibitive) to prototype the systems first to get a firmer decision?  I don't think it would be totally unreasonable to expect the client to pay for two design efforts if you have to fully design the systems to get to a decision point either.

I often explain to clients that the early part of the design process is somewhat exploratory and that for some solutions, a bit of experimentation is necessary to fully comprehend the challenges and options.  It would usually be in bad faith to try to convince them that a full-blown design is required to get them enough information to make an informed decision, but that's not usually required in place of a prototype/proof-of-concept cycle.  I would follow-up after that with a robust design model.
Title: Re: "Alternative" requirements
Post by: mchiuminatto on March 05, 2004, 12:17:33 pm
Ive never face this problem before but this is what Id do

As a first approach I would start modeling the alternative that best fit the desired or needed solution (probably the most expensive).  Then go to the client and ask him, is this solution within budget?. If the answer is yes you are done. If the answer is no, I'd model the next alternative and so on.

Other alternative is, start with two or more (as needed) parallel modeling efforts until to reach the point you have the information necessary to make good cost/benefit analysis. This point should be the end of the elaboration phase (as known in RUP).

Hope it helps and I would appreciate a lot you keep on telling me about the evolution of this problem.

Title: Re: "Alternative" requirements
Post by: sargasso on March 05, 2004, 03:53:54 pm
A bit more information that I didn't put into the original post...

The system - in the main - has already been designed and built.  IOW, we are currently at release 0.9beta

There were some unresolved implementation items deferred from the original design phase as, not unreasonably, they had some issues and did not impact on the core system material too much!  As the example above indicates they tend to be implementation choices where the true user requirement is unclear because they do not understand the issues.

My core issue is that the design - a huge EA model - could easily be disturbed while we work out these issues and everyone will get too confused.

I have had an idea overnight that it might be possible to use new Project Root Nodes to investigate the alternatives.  I'll give it a go and see if it helps.  It would be nice if we could make the original root node elements read only though!.

It appears that the latter releases of EA support "localised" colouring of elements at the diagram level. I have not investigated how far this goes, i.e. does it apply to all models.  What we might be able to do is use colours to highlight the impacted elements by alternative!  Here's hoping.


Title: Re: "Alternative" requirements
Post by: mchiuminatto on March 05, 2004, 03:59:26 pm
I have already done it, using colours I mean, to show the impact of new requirements in the use case model.

Nice week end for every one
Title: Re: "Alternative" requirements
Post by: sargasso on March 05, 2004, 04:15:51 pm

This looks like its the easiest way to achieve what I want.  I'll keep you posted


P.S. Geoff, if your listening what I need is one of the following alternative requirements
A) control drag'n'drop that can shallow copy an entire view into a new root node, or
B) a macro language that I can use to script copying parts of a structure between views/root nodes.

Any time on Monday morning will be fine!  ;D