Re: The semantics of requirements and principles

Hello Linda,

The word 'deliverable' in the glossary definitions means the WG deliverables
as listed in the charter (best practices, time ontology, sensor ontology
and coverage). In the UCR document requirements are related to these
deliverables.

In the definition of non-functional requirements it does not say that they
are not testable, it says they are not testable in a boolean way. For
instance, performance can be objectively measured (e.g. 10 Mb/s). But it is
not possible to say if a requirement like 'the system must be designed to
have high performance' is met or not. If a requirement would be phrased
like 'mean daily download speed must be higher than 10 Mb/s', then it would
be possible to tick off such a requirement, to determine whether the
requirement is met. In that case the requirement would be a functional
requirement.

Does this make sense?

Regards,
Frans

2015-05-15 9:52 GMT+02:00 Linda van den Brink <l.vandenbrink@geonovum.nl>:

>  Hi all,
>
>
>
> I agree with the general definition of ‘functional requirement’ in the
> glossary. However, I have a question about the functional requirements we
> are in the process of formulating now. What is the ‘deliverable’ we are
> defining functional requirements for? Is the deliverable the Best Practice
> + the Time ontology + SSN ontology + deliverable related to Coverage Linked
> data, OR is the deliverable “Spatial data on the web”? To me it seems to be
> the latter (from the way the requirements are formulated in the UCR), but
> from the glossary definitions, especially the definition of Requirement, I
> get the idea it is the former.
>
>
>
> Also, is it really true that non-functional requirements are always
> non-testable? E.g. performance is a non-functional, however it seems
> possible to me to test this.
>
>
>
> Linda
>
>
>
> *Van:* Frans Knibbe [mailto:frans.knibbe@geodan.nl]
> *Verzonden:* woensdag 13 mei 2015 14:38
> *Aan:* Kerry Taylor
> *CC:* SDW WG Public List; Jeremy Tandy
> *Onderwerp:* Re: The semantics of requirements and principles
>
>
>
>
>
>
>
> 2015-05-13 14:17 GMT+02:00 <Kerry.Taylor@csiro.au>:
>
> All,
>
> (1)    These definitions look ok to me.
>
> (2)    I’m not sure I would want to agree with (2), though, although I am
> struggling to construct a counter-example. Do we need agree on (2)?
>
>
>
> I think the acceptance of (2) has a bearing on how we handle Principles.
> Do we need to distinguish Principles with these two definitions in place
> (given the principle that simple = good)?  Is a Principle a kind of
> non-functional requirement? Or is it something completely outside of the
> realm of requirements?
>
>
>
> Another thought is that it is possible to come up with additional types of
> requirements (see this list
> <http://en.wikipedia.org/wiki/Requirements_analysis#Types_of_Requirements>
> for example). By saying we only consider two types we keep things simple.
>
>
>
> Regards,
>
> Frans
>
>
>
>  Kerry
>
>
>
>
>
> *From:* Frans Knibbe [mailto:frans.knibbe@geodan.nl]
> *Sent:* Saturday, 9 May 2015 12:51 AM
> *To:* SDW WG Public List; Jeremy Tandy
> *Subject:* The semantics of requirements and principles
>
>
>
> Hello everyone (particularly Jeremy, on account of action 25
> <http://www.w3.org/2015/spatial/track/actions/25>),
>
>
>
> In trying to fullfill action 24
> <http://www.w3.org/2015/spatial/track/actions/24> I have just made some
> entries in our glossary
> <https://www.w3.org/2015/spatial/wiki/Glossary_of_terms>. I have added
> definitions of the term requirement
> <https://www.w3.org/2015/spatial/wiki/Glossary_of_terms#requirement> and
> its subclasses functional requirement
> <https://www.w3.org/2015/spatial/wiki/Glossary_of_terms#functional_requirement>
> and non-functional requirement
> <https://www.w3.org/2015/spatial/wiki/Glossary_of_terms#non-functional_requirement>
> .
>
>
>
> At this point, I would like to ask the group members the following:
>
>    1. Do you agree with the definitions?
>    2. We could say that functional requirements and non-functional
>    requirements together form the complete set of possible requirements. Could
>    there be practical problems with such a viewpoint?
>
>  I have not added a definition for 'principles' yet, because I thought it
> would be smart to agree on the definitions of requirements first, and see
> if there is a need for additional terms later. If there is, I do see a
> resemblence between the term business requirements
> <http://en.wikipedia.org/wiki/Business_requirements> and the term
> 'principles' as it has been used in this group.
>
>
>
> Regards,
>
> Frans
>
>
>
>
>
> --
>
> Frans Knibbe
>
> Geodan
>
> President Kennedylaan 1
>
> 1079 MB Amsterdam (NL)
>
>
>
> T +31 (0)20 - 5711 347
>
> E frans.knibbe@geodan.nl
>
> www.geodan.nl
>
> disclaimer <http://www.geodan.nl/disclaimer>
>
>
>
>
>
>
>
> --
>
> Frans Knibbe
>
> Geodan
>
> President Kennedylaan 1
>
> 1079 MB Amsterdam (NL)
>
>
>
> T +31 (0)20 - 5711 347
>
> E frans.knibbe@geodan.nl
>
> www.geodan.nl
>
> disclaimer <http://www.geodan.nl/disclaimer>
>
>
>



-- 
Frans Knibbe
Geodan
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl
disclaimer <http://www.geodan.nl/disclaimer>