Advice on modelling a 'bitty project'

[Guy Manning]

Hi again.. more sage advice needed...
The piece of work I have been given to model is 'bitty' in terms of its requirements..
i.e. a few small enhancements, an infrastructure change or two, some general MIS reports etc.
When you have a 'project' which needs to deal with all sorts of smallish but diverse parts to it, is there a good way of organising this within a single EA model?
Ta

[mikewhit]

I've never had to model such a project, but I have had to undertake changes in such a way according to a v-model discipline, and that suggests a method to try ...
which is to keep as much as possible 'legacy' unchanged software as black boxes/subsystems, and only to model the interfaces and elements that are changing.

Be strict - you really aren't interested in showing details that aren't going to change: unless you are doing a whole reverse engineering project :-(

Hope this illuminates a path slightly ...

[thomaskilian]

Stay tough, Guy. If someone comes up with "just a few changes in the requirements" it might result in a complete new system. Catch all the requirements and state who's the owner for each (use an Actor to identify them). Once you have them, just try to uncover what the impact of each change is. You might need to sketch the Use Cases behind. Get a confirmation for each change. Try to involve someone how knows the system to verify the impact. If there's any chance for more than "just a few changes" you are up to some re-engineering. Anyway a good piece of work as (I guess) the system documentation does not cover an initial requirements analysis.

And of course: It's a good idea to keep all these in a single EA repository.

[mikewhit]

What does stay tough mean exactly ?

"Don't be put off by apparent difficulty" ?
"Remain steadfast" ?
"Don't turn into a wimp" ;) ?

[Bruno.Cossi]

When it comes to requirements management, all of the above is a must :-)

What does stay tough mean exactly ?

"Don't be put off by apparent difficulty" ?
"Remain steadfast" ?
"Don't turn into a wimp" ;) ?

[thomaskilian]

Bruno is right, of course

[sargasso]

I tend to disagree.
Any user requirement is legal.
Any user requirement can be resolved (it's a SMP*)
All requirements must be processed properly.
User's and system owners make decisions on what will be included in a development schedule once they are aware of the cost of meeting a requirement.
"Knowing better" than the user/owner is NOT the requirement analysts job.
"Knowing better" than the system designers and not processing user requirements will often result in deferred (and hidden) requirements costing many times more than they would have if full and frank disclosure was made.
Unresolved requirements are a significant piece of business information when it comes to measuring the value of a system.
etc etc

bruce

(SMP=simple matter of programming!)

[thomaskilian]

I tend to disagree.
...

disagree -whom

[sargasso]

hmmmm.  Actually, with you, but on re-reading I SHould have said:

In fact I agree.



bruce