[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Re: Requirements
From:       Thomas Förster <t.foerster () itb ! biologie ! hu-berlin ! de>
Date:       2000-10-26 7:27:06
[Download RAW message or body]

Am Wed, 25 Oct 2000 schriebst Du:
>"Thomas Förster" wrote:
>
>> ...[snip]...
>
>Hi Thomas,
>
> I'm not sure I quite follow your schema above.  As I've been using the terms
>"internal" and "external", they refer to whether a requirement is visible to users
>(external) or just to kUML developers (internal).  This definition is given in
>comments in the DTD.  Now it seems to me that diagram editing and print
>functionality are definitely user visible, but you put them under internal
>requirements.

OK, it seems we have used different meanings of the terms. For me "external"
are all requirements which a virtual user of the respective system (Lib or
GUI) is going to have. "Internal" are all other requirements. The one we
derive from the external requirements to fulfill these and on the other side
requirements we as developers have on the systems (e.g. well documented code).
In principle the external requirements are the users wish list.

Maybe someone finds better terms for that. And Gerard sorry, I didn't look in
the DTD too much (except yesterday ;-) but had other focus).

>
> ....
>
>    This notion of sub-requirement would be in addition to having an "inheritance"
>relationship from the project reqs to individual product reqs.  The two ideas are
>fundamentally different because in one case we're talking about requirements for
>different entities whereas in the other its different levels of reqs for the same
>entity.

That seems to be a solution of my problem, I told you. You then could seperate
requirements which follow(are inspired by) an other ("inheritance") and
requirements which are obligatory to fulfill the "parent" (subrequirement). 

Thomas

[prev in list] [next in list] [prev in thread] [next in thread]