[Setools] Gjallar let's go

[Hans N Beck]

Hi Göran,

reading the "Gjallar Original Requirement and Desig" document, it  
seems you have really seen commercial tools :-) Which ones ? (I've  
worked 3 years with MKS Source Inegrity Server)

But I have also some questions :

>
>> About Design
>>
>> 3/"Case linking" :  This mechanism is a manual decision (like  
>> moving a ca=
>> se in a new stage)  or we can define some rules ?
>
> Typically manual. At least today. One could imagine "auto linking" for
> example based on keyword analysis like "this might be a similar case"
> etc. I have seen at least one system with that functionality on the
> market, can't recall which one it was right now.
>
> If you have ideas about rules - feel free to suggest. One thing we  
> want
> to add is of course to make it much easier to create "sub cases" -  
> when
> you are viewing an existing case it would be nice with a simple way of
> creating a new case linked to the one you are viewing etc.

In this context, I would ask if this was a requirement of customer  
that cases can not change type. Of course, that makes things easier.   
But it may happen, that  the result of walking through a process can  
be a case which has another nature. Example: it often happens, that  
someone has a idea how to improve a software. This is not more than a  
notice. Later, the ideas get more concrete, algorithms or GUI details  
are specified, and some day, you have even detailed requirements with  
acceptence criteria (=test descriptions). So whats started as a  
simple notice is a full fledged requirement at the end. At my work, I  
always have modeled that with "level of detail" property, which was  
changed by a special process (=workflow, from level 1 to 2 to 3  
etc.), but the problem always was, that the result is really somthing  
other.
In other words: Cases (also Bugs) can change, they have history, and  
they can result in other type of case.

Another thing is splitting/merging of cases. For us, it occurs often  
that Cases must be split, because a detailed analysis shows that a  
bug concerns to completly different parts of a software, or that a  
requirement is to trivial an must merged with others. Is there any  
support ?

>
>> In your document you write "a case can !!!normally!!! not move  
>> between pr=
>> ocesses"
>> Why "normally" ;-)?
>
> Because different Processes will have different Forms and different
> workflows and validation etc. So if Process A has a Form X, which has
> been added to case 12 - then if you move that case to Process B which
> does not have that Form - then... well. :)
>

Is there exact one process for one case (1:1) ? Thats not full clear  
to me. In the document, it is mentioned that different user groups  
has different processes, but that this means necessarily 1:1 mapping  
is not clear ;-)

Then a last question ? What about templates (for processes, for  
reports, or for export - so for example make a open office document  
from a set of Cases - very cool if available for the work with  
customers :-))

But anyway, can't wait to play with it :-)

Regards

Hans