This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
RmHome
>
RmMeetings
>
RmMeetings20110124
>
RmRequirementsOrganization
(24 Jan 2011,
IanGreen
)
(raw view)
---+ Requirement Organisation Feedback from SimonWills: As discussed last time, I believe that this is an important area for consideration in OSLC-RM 3. From my perspective, the key organisational principles are as follows: a. Requirements may be held in ‘containers’ (in DOORS, these are called ‘modules’) b. Containers may be held in a hierarchical folder structure, like a file system c. Containers and folders would be resources in their own right, and may have their own properties (e.g. name, at a minimum) d. Requirements within containers may be held in an ordered list e. Requirements within containers may also be held in a hierarchical tree Associated with such organisation is a critical capability: the ability to ‘walk the tree’. From any one resource (requirement, container, folder), it should be possible to navigate to parent, child, following sibling or preceding sibling resources. This very significantly enhances the ‘findability’ of information, enabling selection of resources based on structure rather than content (as currently provided by OSLC query). A few additional comments: a. This area is not specific to requirements – like the debate on linking, it’s arguably OSLC Core business. Replace the word ‘requirement’ in the list above with ‘resource’, and we have a pretty general organisational approach. b. We are used to containers and folder hierarchies being ‘physical’ (e.g. a requirement belongs to exactly one container). But, properly implemented, there’s nothing in these principles that would prevent virtual containers and hierarchies. c. Where a provider does not support one of these organisational principles, everything collapses in a controlled manner (e.g. if a provider did not support a folder hierarchy, this is equivalent to a single root folder with no siblings or children). I think that’s it for now.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r1 - 24 Jan 2011 - 15:28:26 -
IanGreen
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback