Mantis Bugtracker          
testlink.org

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001748TestLinkRequirement Managementpublic2008-09-25 16:062010-05-01 20:28
Reportershron 
Assigned Toasimon 
PrioritynormalSeverityfeature requestReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.8 Beta 2 
Fixed in Version1.9 Beta 4 
Summary0001748: Requirement Management need to be improved with requirement relations between requirements
DescriptionIt would be nice to implement linkage between requirements as requirements could be with different types.
Between these requirements need to perform linkage as one requirement type is as source for other requirements with another type.
I did simple linkage by using text area custom fields with requirement names, but it is not easy to work with requirement updates.

Additionally would be nice to manage requirement ID field, if it will be shown into requirement's tree.
Additionally would be good to make deep level tree for requirements as current version (one level only) is not good for requirement specification creation.
TagsNo tags attached.
Database (MySQL,Postgres,etc)
Browser
PHP Version
TestCaseID
QA Team - Task Workflow Status
Attached Filespng file icon req_relations_openissues.png [^] (35,096 bytes) 2010-02-26 00:23


? file icon 1748-relations_between_reqs.odt [^] (67,124 bytes) 2010-03-01 23:22

- Relationships
related to 0002977closedasimon Internal Links for Requirements and Requirement Specifications 
related to 0003137closedasimon Change of Requirement Specification Types 

-  Notes
(0004149)
fman (administrator)
2008-09-25 17:25

1. do not report 3 issues on one issue

2. please improve your explanation regarding linking is not too clear
 
3. N depth tree -> will be released on 1.9
(0004152)
shron (reporter)
2008-09-25 17:40
edited on: 2010-03-01 01:05

Currently it is possible to make linking between requirements and test cases.
The same mechanizm is expecting between requirements.
Example:
I have a general requirement with SSS type.
According this requirement I should create requirements with more detailed information as SRS type.
According both requirement types I am creating test cases.
If you worked with Rational RequisitePro then you know that this tool is supporting many requirement types and different requirements could be linked between each other.
This feature is very conveniant.
Additionally would be good to implement bi-dirrectional update between linked requirements - it will help with requirements developing.

(0005993)
mhavlat (reporter)
2009-03-25 22:50

Please see 1202 regarding relation request.
Which type relation you need?
(0008860)
bchabot (reporter)
2010-01-29 02:43

I also need links between requirements.
Hierarchic links is v1.9 ( N depth tree) is very interesting but not enough for some needs ...

Basically, I need to make links between 3 trees of requirements :
   - A tree of Business Requirement
Requirement expressed in term of "What the User want to do"
   - A tree of IS Requiement (Information System)
Requirement expressed in term of "What the System should do"
   - A tree of IT Requiement (Information Technology)
Requirement expressed in term of "What the Component should do"

I needs to map some requirement of the firts tree with some requirement of the second tree
with a semantic "satisfied by" / "satifies" (=> link must be visible from both side)
I also need to map some requirement of the second tree with some requirement of the third tree
with a semantic "satisfied by" / "satifies" (=> link must be visible from both side)

From a more generic point of view I need to link a given requirement to another requirement
with a given semantic that I can pick in a administered list
(0009178)
Julian (reporter)
2010-02-25 21:25
edited on: 2010-02-25 21:27

A simple mechanism like relationship-feature here on mantis could be implemented.
This in my eyes is a key-feature for professional requirement managment.

@developers: let me know your opinions about this feature. I think we could handle it to be a part of 1.9 which i highly would appreciate.

Edit:
i would like to offer users the posibility to define "custom" relationships.
there could be a predefined set of relations:
- is parent of
- is child of
- blocks
- depends
- ... ?

but as already requested for each user special relations would make sense. So the definition of custom relationships on config level would be great

(0009181)
mhavlat (reporter)
2010-02-25 22:34
edited on: 2010-02-25 22:36

Julian could you propose effort?
DB changes are required ... there is similar requirement for test specification. Make sense to have one table for both cases?

I understand relation parent-child. What other kinds mean "for implementation"?

How these relation could be reported?
I think that precondition is fix of 0003137. It allows to set different levels of requirements (similar like bchabot asked). So user will be able to generate traceability for User requirements to System requirements.

(0009184)
Julian (reporter)
2010-02-25 22:41
edited on: 2010-03-01 01:07

i have no idea about effort. i guess 1-2 weeks could be enough.
i would like to have seperate tables for requirements and test cases as they in my eyes could have different types of relations

the relation types should be very customizable to allow users to link for each situation, e.g.:

There is a feature request from a customer that comes in via E-Mail.
Now this email is collected as a requirement of type "customer request". but an email is no requirement that can be used for development. so this request has to be transformed to a proper requirement.
-> requirement manager creates 5 requirements to fit the customer request. to not lose this link between "customer request" and those 5 requirements he adds a relationship of type "customer request"

i hope it is a little clear :) pretty confusing - sorry

relation types could be defined on const.inc.php

define('TL_REQ_RELTYPE_PARENT_CHILD', 1);
define('TL_REQ_RELTYPE_BLOCKS_DEPENDS', 2);
define('TL_REQ_RELTYPE_CUSTOMERREQUEST', 3);
define('TL_REQ_RELTYPE_RELATED', 4);
define('TL_REQ_RELTYPE_xyz', 5);

there are 2 sorts of relations. relations that describe some kind of hierarchy and relations that do not.
Examples for those 2 sorts:
1. with hierarchy: req1 is markes as parent of req2 -> req2 is automatically marked as child of req1 -> the relation type shown for req1 is "parent of" and for req2 it is "child of"
2. without hierarchy: req1 is marked as related to req2 -> req2 is also marked as related to req1. -> the relation type shown is "related to" for both requirements

Seems like a table req_relations with attributes id, req_id_master , req_id_slave, rel_type would do to implement this feature (there are surely better names than master and slave :) )
could you take a look how this feature is done on mantis ? is it possible to create relation types ?

and other point that comes to my mind:
i want relationships for each requirement to have a db controlled id that is unique and auto incremented to be able to reference those links in scope text

(0009188)
Julian (reporter)
2010-02-25 23:35
edited on: 2010-02-25 23:36

Please see req_relations_openissues.png - ignore open issues this will be some other feature request i will create a mantis issue for.

note that i used relations in scope text - for the ids of relationships it is important that they are auto incremented - meaning: i delete relationship with id 2 and create a new relationship it must get id 3

the way of how to present the <list of reqs and reqspecs> must be thought about.
a combobox like:

req_spec 1
.req1
.req2
..req_spec on 2nd level
...req3
...req4

could be possible... another option would be to just offer a textfield for the reqdocid - but on relationship table we must work with internal db id.

btw: should relationships between reqs and reqspecs be possible ? i suggest yes

(0009199)
mhavlat (reporter)
2010-02-26 19:54

Julian,
I think that you have not overall picture of the problem. I can approve only relation "parent-child" meantime.

Let's discuss the next familiar example:
--------------------------------------------------------------------------
I received from you the request:
"It would be nice to implement linkage between requirements as requirements could be with different types. Between these requirements need to perform linkage as one requirement type is as source for other requirements with another type. I did simple linkage by using text area custom fields with requirement names, but it is not easy to work with requirement updates."

We can create the next structure:
"User requests"
   |---"Customer Mobotix"
            |--- "linkage between requirements" (content of requests)

Now You can create another level (optional)
"User Requirements Specification"
    |-----"SRS design"
            |--- User REQ 1
            |--- 2
            |--- 3

Each this requirement will be linked with original message by "parent-child" relation.
So you can created three User requirements and assign work to Andreas.
Andreas takes the first requirement "User REQ 1" and create 5 System requirements for concrete implementation in TestLink.
"System Requirements Specification"
   |----GUI
         |----- REQ link assignment
   |----"SRS feature logic"
         |---- REQ add link
         |---- REQ delete link
         |---- REQ report linkage
   |----"Export/Import"
         | --- ...etc

Of course he links these system requirements to User requirements designed by you.

Is it clear now? I don't see using for other kind of relation now.

"Customer request" is something that is possible to solve by tree structure, text, docid abbreviation or custom field - this is not relation. There is one type of relation that I can imagine, but not have using for it: predecessor-successor.

I miss you (dis)agreement to precondition issue 0003137.

Implementation: "Text field" is simple and satisfying solution.
Only requirement to requirement will be possible. Technically is not problem link also sections. But it is potential source of problems and degrade quality of information.
(0009200)
Julian (reporter)
2010-02-26 20:16

how about another example that points out why custom relations can be necessary:

req1: if car drives faster than 320 km/h a accustic warning should be given

req2: to offer maximum safety for the driver all speakers in the car should be deactivated when driving faster than 300 km/h

here it is:
req2 blocks req1
req1 depends on req2

giving the opportunity to specify multiple relation-types will be pretty powerful for results later, for example:
i want to see all requirements that have side-effects to each other : block/depends relations
i want to see all requirements that have been a result of a customer request:
customer request relations
...

i think it is not a huge effort to implement custom relationships - so why not doing it ?

regarding 0003137 :
i do not think those issues are directly related. this issue is about requirement spec types - here we are talking about requirements arent we ?
(0009267)
mhavlat (reporter)
2010-03-02 17:18

Julian,
I fully understand your example. I clarify my statement:
1. You have REQ type: "constrain" to indicate "blocking" kind of requirement.
2. Based on user and your requests we going to support horizontal traceability through the requirements. I.e. links between user and system requirements.
3. Your example is the terminology related case. But we need to think about implementation. I do not see implementation difference between parent and blocks relation.

> customer request relations
4. Based on literature I agree to add a new type: "customer requirement". For example: http://en.wikipedia.org/wiki/Requirements_analysis [^]
5. In addition I believe there is already request for ability to assign custom
fields to requirement. It should allow to specify particular customers.

> i want to see all requirements that have side-effects to each other : block/depends relations
Please clarify why type=constrain do not serve for this.

>i think it is not a huge effort to implement custom relationships - so why not doing it ?
Because testers do only mandatory actions. A company standard should ask trace requirements ... so it could be required (and filled properly). But only a few people cares to set-up valid type. Any feature is usable if it is really simple to use.
I have an experience with different req management tool. Only basic functionality is used; not excellent, complex and but additional abilities.


I'm looking for your or anybody review after clarification. I believe that it answer your needs. Otherwise let me know 'implementation' differences for particular types of relation.
(0009269)
Julian (reporter)
2010-03-02 17:30
edited on: 2010-03-02 17:37

1. req type and relations are totally different thing:
req type = use case
why should i set req type to constrain as it is a use case
2. everybody is free to use it as he wishes or needs it
3. naming different relations offers an easy way to identify requirements.
think of a projekt having 5000 requiremts and all are just in a parent / child relation. now you are close to implementation and you want to know which requirements are in conflict -> search for requirements that are in a blocks/depends on relation works fine with my solution
4. req type and relations are totally different thing (see 1.)
5. it is already possible to assign custom fields.
5.1 "Please clarify why type=constrain do not serve for this":
type is only set for one requirement in this relation. Huge advantage of setting those relations is:
Set Req1 parent of Req2 -> Req2 is implicitly child of Req1!
When viewing each requirement this relation will be visible:
Req1 shows: is parent of Req2
Req2 shows: is child of Req1
but again: i do not think users should misuse type for relations -> different thing in my eyes.

(0009270)
Julian (reporter)
2010-03-02 17:53

and the most important thing why type will not work in my eyes:

if i set req1 to type constrain how do i know which requirement is in conflict with req1 ?
(0009281)
Julian (reporter)
2010-03-03 20:59
edited on: 2010-03-03 21:00

i found this Tutorial regarding Requirement Relations:
http://trese.cs.utwente.nl/tric/Relations_Tutorial.pdf [^]

As you see there are multiple relation types metioned.

There are a lot other interprations of relation types out there - but all confirm my plan to make relation types configurable.

I would be glad if you could confirm my design as described in 1748-relations_between_reqs.odt so we can start implementation.

(0009508)
asimon (developer)
2010-03-24 20:01

With last commit and update to requirement search feature, all parts of new req relation feature are ready to be used.

- Issue History
Date Modified Username Field Change
2008-09-25 16:06 shron New Issue
2008-09-25 17:25 fman Note Added: 0004149
2008-09-25 17:40 shron Note Added: 0004152
2009-03-25 22:48 mhavlat Relationship added child of 0001202
2009-03-25 22:50 mhavlat Note Added: 0005993
2009-03-25 22:50 mhavlat Status new => acknowledged
2010-01-29 02:43 bchabot Note Added: 0008860
2010-02-23 02:08 mhavlat Relationship added child of 0002977
2010-02-23 02:09 mhavlat Relationship deleted child of 0001202
2010-02-23 02:10 mhavlat Relationship replaced related to 0002977
2010-02-25 21:25 Julian Note Added: 0009178
2010-02-25 21:27 Julian Note Edited: 0009178
2010-02-25 22:34 mhavlat Note Added: 0009181
2010-02-25 22:34 mhavlat Relationship added related to 0003137
2010-02-25 22:36 mhavlat Note Edited: 0009181
2010-02-25 22:41 Julian Note Added: 0009184
2010-02-25 22:52 Julian Note Edited: 0009184
2010-02-25 22:55 Julian Note Edited: 0009184
2010-02-25 23:04 Julian Note Edited: 0009184
2010-02-25 23:04 Julian Note Edited: 0009184
2010-02-25 23:27 Julian File Added: req_relations_openissues.png
2010-02-25 23:35 Julian Note Added: 0009188
2010-02-25 23:36 Julian Note Edited: 0009188
2010-02-26 00:23 Julian File Deleted: req_relations_openissues.png
2010-02-26 00:23 Julian File Added: req_relations_openissues.png
2010-02-26 18:47 Julian Note Edited: 0009184
2010-02-26 18:51 Julian Note Edited: 0009184
2010-02-26 18:51 Julian Note Edited: 0009184
2010-02-26 18:52 Julian Note Edited: 0009184
2010-02-26 18:54 Julian Note Edited: 0009184
2010-02-26 18:55 Julian Note Edited: 0009184
2010-02-26 19:54 mhavlat Note Added: 0009199
2010-02-26 20:16 Julian Note Added: 0009200
2010-03-01 01:04 fman Description Updated
2010-03-01 01:05 fman Note Edited: 0004152
2010-03-01 01:07 fman Note Edited: 0009184
2010-03-01 23:22 Julian File Added: 1748-relations_between_reqs.odt
2010-03-02 05:00 fman Summary Requirement Management need to be improved with requirement linkage between requirements => Requirement Management need to be improved with requirement relations between requirements
2010-03-02 17:18 mhavlat Note Added: 0009267
2010-03-02 17:20 mhavlat Assigned To => Julian
2010-03-02 17:20 mhavlat Reproducibility always => N/A
2010-03-02 17:20 mhavlat ETA none => < 1 week
2010-03-02 17:30 Julian Note Added: 0009269
2010-03-02 17:36 Julian Note Edited: 0009269
2010-03-02 17:37 Julian Note Edited: 0009269
2010-03-02 17:53 Julian Note Added: 0009270
2010-03-03 20:59 Julian Note Added: 0009281
2010-03-03 21:00 Julian Note Edited: 0009281
2010-03-11 16:17 asimon Assigned To Julian => asimon
2010-03-11 16:17 asimon Status acknowledged => work in progress
2010-03-24 20:01 asimon Note Added: 0009508
2010-03-24 20:01 asimon Status work in progress => assigned
2010-03-24 20:02 asimon Status assigned => resolved
2010-03-24 20:02 asimon Fixed in Version => 1.9 Beta 4 (Next public build)
2010-03-24 20:02 asimon Resolution open => fixed
2010-05-01 20:28 fman Status resolved => closed



Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker