Hi Thomas,

when I create a use case, I link it to a requirement but this is not shown  
in the use case representation. An example: I have linked use case 5 to  
requirement 68 but this is neither displayed in the requirement nor in the  
use case description. I think that you can change that in the use case  
content type settings (but I do not see exactly where). Or was that done  
on purpose?

Thanks for helping :)

Best,
Evelyn

Am 10.07.2014, 09:47 Uhr, schrieb Kai Eckert  
<[log in to unmask]>:

> Am 09.07.2014 23:06, schrieb Karen Coyle:
>> I don't always understand the requirement from its name in the
>> rdf-validation database. In the long display of the requirement there is
>> often a brief description, but I must admit to be baffled still by many
>> of them, for example:
>
> All the more it is important to keep duplicate requirements once
> identified or at least their descriptions. I am not saying that what we
> try is an easy task, but if we accomplish it, it will not only give us
> all a much clearer view on the requirements of our community, we also
> create a controlled vocabulary of requirements that will be immensely
> useful in any subsequent discussions and developments.
>
>
>> - Machine Understandable Concrete Syntaxes Formulation Constraints
>> - Leverage on Existing Technologies (which is described as: "Whenever
>> possible") (I think I understand this one, but can't be sure.)
>>
>> Perhaps this is a good reason to develop our own requirements unless the
>> existing ones are totally obvious to everyone, so that we can then
>> discuss in the group what the requirements mean to us.
>
> I hope that Thomas will be able and have enough time to provide us with
> a set of tools supporting exactly this discussion. I am, however, very
> optimistic :-)
>
>> I am also hoping that we can develop our requirements around the
>> relevant (as we wish to define it) Singapore Framework areas. Data
>> validation requirements will most likely be fulfilled in the ShEx and
>> SPIN arenas, and we can lean on those for validation details. But the
>> areas of "record" (read:graph) modeling, vocabulary mix-n-match, and
>> documentation may not be well covered by those whose emphasis is on data
>> validation.
>>
>
> A good point, we should keep in mind to extend the approach and the
> database to all kinds of requirements, not only validation. But let's
> focus for now on validation.
>
>> kc
>>
>>
>> On 7/9/14, 7:57 AM, Kai Eckert wrote:
>>> Am 08.07.2014 21:43, schrieb Antoine Isaac:
>>>>> Related to your comment during the discussion.
>>>>> If you have a requirement in mind and you are not sure if it is
>>>>> already contained in the requirements db, just create an new
>>>>> requirement.
>>>>> I can look if there is already a requirement in the db with the same
>>>>> semantics in order to delete duplicates.
>>>>
>>>>
>>>> Great!
>>>> I'd expect that you mail us before deleting duplicates. This would
>>>> probably be very useful for the person who created the requirements,  
>>>> and
>>>> for the others, who could also see what's happening during requirement
>>>> elicitation.
>>>>
>>>
>>> I would not delete them, I would join them by linking them as  
>>> duplicates.
>>>
>>> Moreover, when a new requirement is created, existing requirements
>>> should be autosuggested based on the description, either during  
>>> entering
>>> or after submission, where the creator could be asked to review similar
>>> requirements, if they match. I assume that this can be done quite  
>>> simply
>>> without too much effort. For the first shot, I would simply search for
>>> all requirements that have matching terms somewhere in the description,
>>> let's see how far we get with that.
>>>
>>> Cheers,
>>>
>>> Kai
>>>
>>
>


-- 
Evelyn Dröge

Humboldt-Universität zu Berlin
Berlin School of Library and Information Science
- Digitised Manuscripts to Europeana (DM2E) -
Dorotheenstraße 26, D-10117 Berlin
Tel.: +49 30 2093-4265

[log in to unmask]
www.ibi.hu-berlin.de | dm2e.eu