|Anonymous | Login | Signup for a new account||2020-02-22 06:12 UTC|
|Main | My View | View Issues | Change Log | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003137||TestLink||Requirement Management||public||2010-02-03 22:34||2010-06-05 07:11|
|Product Version||1.9 Beta 2|
|Fixed in Version||1.9 Beta 4|
|Summary||0003137: Change of Requirement Specification Types|
|Description||Currently 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.
|Tags||No tags attached.|
|QA Team - Task Workflow Status|
edited on: 2010-02-03 22:40
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!
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.
|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.|
|Julian, are you fine with my proposal?|
|just go ahead. i prefer predifining just a small set of common values and leaving the option to add custom values to all users.|
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
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.
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).
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.
Types have been changed, according to Julian's proposal in 9483.
Changes have been committed.
|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|