Mantis Bugtracker 

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003137TestLinkRequirement Managementpublic2010-02-03 22:342010-06-05 07:11
Assigned Toasimon 
PrioritynormalSeverityfeature requestReproducibilityN/A
PlatformOSOS Version
Product Version1.9 Beta 2 
Fixed in Version1.9 Beta 4 
Summary0003137: Change of Requirement Specification Types
DescriptionCurrently requirement specification types are just copied from requirements. Those values do make much sense for requirement specifications.
There should be a good set of value.
TagsNo tags attached.
Database (MySQL,Postgres,etc)
PHP Version
QA Team - Task Workflow Status
Attached Files

- Relationships
related to 0001748closedasimon Requirement Management need to be improved with requirement relations between requirements 

-  Notes
Julian (reporter)
2010-02-03 22:39
edited on: 2010-02-03 22:40

My suggestion:

Default value: "Requirement Specification"
- "Container" or "Requirement Suite" or "Folder" or "Module" ...

hope you do not mind that i assign this issue to you Martin.

Community feedback would be great!

mhavlat (reporter)
2010-02-07 05:15

Valid values for requirement specification are:
- "User Requirement Specification"
- "System Requirement Specification"
- "Section" (default)

"System Requirement Specification" is related to the current functionality (Req. based report, Analyse)
"User Requirement Specification" have not meantime a special meaning. TODO: user can create traceability between User and System requirements (+ report).
"Section" is structural container like Suite.

Note that I avoid terms like Product Req, Market Req. We uses ISTQB terminology by default.

Technically there could be constrain, that only first level of tree could be URS or SRS and higher will be sections.
nikwik (reporter)
2010-02-08 16:23

The name "Requirement Specification" is accepted terminology to be used for a collection of requirements. I really don't see the need to change this. I like mhavlat's idea as a solution to meet other needs.
mhavlat (reporter)
2010-02-23 01:54

Julian, are you fine with my proposal?
Julian (reporter)
2010-02-23 01:59

just go ahead. i prefer predifining just a small set of common values and leaving the option to add custom values to all users.
Julian (reporter)
2010-03-01 19:49
edited on: 2010-03-01 19:56

As we really do have problems to find good values for req spec types i suggest:

- Disable reqspec type by default -> make it configurable on config
- do not predefine a set of values
-> if someone wants to use type for reqspecs he has to define and enable them.

I suggest this because i have the feeling that everyone would like a different set of reqspec types or not use it at all.

I really would like to use them but totally different values than proposed by martin.

@fman: please do not simply remove as stated in comment 8940 - we WILL find a good solution :)

@mhavlat: please think about relation to 1748 again - i think there is no relation! this issue here is about req specs and 1748 is about reqs. please remove relation if you agree

mhavlat (reporter)
2010-03-01 22:32

1. The most important is to have clean architecture. It will show if this relation is here or not. I started to make a draft ASAP for your review.

2. We need to be consistent in terminology. Standard ISTQB was set a few years ago for TL as base.
There is no technical problem for you to use custom_strings for your employer standards. That is strong page of TestLink.
Could you list your values and relations? Maybe we have not totally different types at all.

3. Definitely SRS type should be disabled by default.
mhavlat (reporter)
2010-03-18 23:02

Based on discussion with Julian:
- no SRS types will be used in 1.9 version
- we will consider this parameter in 2.0 or later (based on experience with changes in 1.9)

The current DB schema include the parameter with invalid type char -> INT (will be changed later).
Julian (reporter)
2010-03-22 14:44

According to Martins proposal in testLink_design_rms.odt types will be changed to

"Valid values for requirement specification are:
Section (default) is structural container like Suite
User Requirement Specification
System Requirement Specification"

i prefer this solution for now - better than disabling function. We can change in 2.0 including DB.
asimon (developer)
2010-03-22 15:56

Types have been changed, according to Julian's proposal in 9483.
Changes have been committed.

- Issue History
Date Modified Username Field Change
2010-02-03 22:34 Julian New Issue
2010-02-03 22:39 Julian Note Added: 0008938
2010-02-03 22:39 Julian Status new => assigned
2010-02-03 22:39 Julian Assigned To => mhavlat
2010-02-03 22:40 Julian Note Edited: 0008938
2010-02-07 05:15 mhavlat Note Added: 0008958
2010-02-07 05:15 mhavlat Assigned To mhavlat => Julian
2010-02-07 05:15 mhavlat Severity minor => feature request
2010-02-08 16:23 nikwik Note Added: 0008966
2010-02-23 01:54 mhavlat Note Added: 0009127
2010-02-23 01:59 Julian Note Added: 0009128
2010-02-25 22:34 mhavlat Relationship added related to 0001748
2010-03-01 19:49 Julian Note Added: 0009253
2010-03-01 19:49 Julian Note Edited: 0009253
2010-03-01 19:56 Julian Note Edited: 0009253
2010-03-01 22:32 mhavlat Note Added: 0009254
2010-03-10 23:28 Julian Note View State: 9253: public
2010-03-18 23:02 mhavlat Note Added: 0009461
2010-03-18 23:02 mhavlat Priority high => normal
2010-03-18 23:02 mhavlat Reproducibility always => N/A
2010-03-18 23:02 mhavlat Status assigned => acknowledged
2010-03-22 14:44 Julian Note Added: 0009483
2010-03-22 14:44 Julian Assigned To Julian => asimon
2010-03-22 14:44 Julian Status acknowledged => assigned
2010-03-22 15:56 asimon Note Added: 0009484
2010-03-22 15:57 asimon Assigned To asimon =>
2010-03-22 15:57 asimon Status assigned => feedback
2010-06-05 07:11 fman Status feedback => closed
2010-06-05 07:11 fman Assigned To => asimon
2010-06-05 07:11 fman Resolution open => fixed
2010-06-05 07:11 fman Fixed in Version => 1.9 Beta 4

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker