Edgewall Software

Changes between Version 2 and Version 3 of CookBook/Configuration/RequirementsManagement


Ignore:
Timestamp:
May 31, 2022, 11:33:44 AM (6 months ago)
Author:
figaro
Comment:

Reduce verbosity

Legend:

Unmodified
Added
Removed
Modified
  • CookBook/Configuration/RequirementsManagement

    v2 v3  
    33= Requirements Management
    44
    5 Every once in a while there is a question about whether Trac supports [wikipedia:Requirements_management requirements management]. There is even a plugin request for this, see th:#1226. While having an out of the box solution would be nice, there are a few plugins already available which can be used for building a requirements management solution.
    6 
    7 On this page one possible approach is shown for doing so. I'm working in development of [wikipedia:IEC_61508 IEC 61508] compliant control devices. We use Trac for tracking all the requirements mandated by this standard, currently something like 4000-6000 requirements and test cases.
    8 
    9 The solution presented here may or may not work for you. We use quite some custom made plugins to support our internal processes. These plugins are private and you may have to create your own.
    10 
    11 See also: th:ProjectManagementIdeas
     5Trac can be configured to support [wikipedia:Requirements_management requirements management]. There are [th:ProjectManagementIdeas#TracPlugins some plugins available] as well as a [th:#1226 plugin request] for building a requirements management solution in Trac. On this page one possible approach is presented for doing so.
    126
    137== Before you start
    14 
    15 Don't select a tool because it's fancy and then organise your requirements management process so it can be supported by the tool. This will fail in the end.
    168
    179Make sure you know your process and environment:
    1810 * Which types of requirements do you have? System requirements, functional requirements, test cases, performance requirements?
    19  * Who owns them? There may be more than one stakeholder in the project and each stakeholder has the responsibility to understand and prioritise their own requirements.
    20  * Who is writing them? The tech people or maybe management people? It may be impossible to drag your management people away from MS-Word c.s., so you may need a Word document importer.
     11 * Who owns the requirements? There may be more than one stakeholder in the project and each stakeholder has the responsibility to understand and prioritise their own requirements.
     12 * Who writes the requirements? The tech people or maybe management people? It may be impossible to drag your management people away from MS-Word c.s., so you may need a Word document importer.
    2113 * Is there a predefined workflow for requirements, eg {{{ draft -> in review -> approved -> closed }}}?
    2214 * Is the workflow dependent on the type of requirement?
    2315 * How do you manage changes to requirements?
    24  * What about roles and permissions in the process?
    25  * Do you need some kind of sign off?
     16 * Are roles and permissions defined in the process and are they understood by all stakeholders?
     17 * Is an approval process defined on the requirements?
    2618 * It may be necessary to import data from other tools or departments. For example the test department may be using their own tooling and even their own bug tracker.
    2719
    28 After reviewing your process requirements you should evaluate if Trac with the appropriate plugins is a viable solution. Don't do that by counting bullet points, but by actually using it for a project. The beauty of Trac is that by adding the right plugin or writing a new one more or less every need may be fulfilled and in the end your solution **exactly** matches your process requirements.
     20This process review should help to understand whether Trac with the appropriate plugins is a viable solution. Don't do that by counting bullet points, but by actually using it for a (sub)project. Instead, with the right collection of plugins or writing new plugins, the specific needs can be fulfilled and your solution will **exactly** match your process.
    2921
    3022== Requirements management using Trac
     
    3426=== Environment type
    3527
    36 Each project lives in a separate environment with its own SQLite database. This way you may not accidentally alter data not belonging to your current project because of a misconfiguration (e.g. broken permissions) or bug in one of your plugins. It makes access control easier which may be important.
     28Each project lives in a separate environment with its own database. This way you may not accidentally alter data not belonging to your current project because of a misconfiguration (e.g. broken permissions) or bug in one of your plugins. It makes access control easier which may be important.
    3729
    3830After the project is done one may revoke all write permissions and archive the complete environment so the current state of requirements is frozen.
     
    4436 * {{{testcase}}}
    4537
    46 In our department we only track requirements in the environment so all other ticket types are removed. If you want to use your requirements Trac also for issue tracking keep the standard ticket types. There is no need to create special types for each level of a [wikipedia:V-Model_(software_development) '''V model'''], but nobody stops you from doing so.
     38If you want to use your Trac also for issue tracking, then keep the standard ticket types. There is no need to create special types for each level of a [wikipedia:V-Model_(software_development) '''V model'''], but this is certainly possible.
    4739
    4840For administrating ticket types go to the '''Admin''' area of your Trac installation or use the command line:
     
    5244}}}
    5345
    54 TracAdmin describes the command line interface in full length.
     46TracAdmin describes the command line interface in more detail.
    5547
    5648=== Defining roles
    5749
    58 It may be necessary to define additional permissions to have more control of the requirements workflow. For example there may be a distinct group for requirements review and approval while the QA department is responsible for closing requirements.
    59 
    60 To define the additional permissions:
    61  * {{{REQUIREMENT_APPROVE}}}
    62  * {{{REQUIREMENT_CLOSE}}}
    63 
    64 add the following to your `trac.ini` file:
     50It may be necessary to define additional permissions to have more control of the requirements workflow. For example there may be a distinct group for requirements review and approval while the [wikipedia:Software_testing QA department] is responsible for closing requirements.
     51
     52To define the additional permissions {{{REQUIREMENT_APPROVE}}} and {{{REQUIREMENT_CLOSE}}} add the following to your `trac.ini` file:
    6553{{{#!ini
    6654[components]
     
    7765=== Creating specialized workflows
    7866
    79 A workflow for a requirement is very different from a standard issue workflow. Using th:MultipleWorkflowPlugin (disclosure: I'm the maintainer) specific workflows for each new type may be created.
     67A workflow for a requirement is very different from a standard issue workflow. With th:MultipleWorkflowPlugin you can create specific workflows for each new type.
    8068
    8169Add this to your `trac.ini` file:
     
    170158 * th:TracTicketConditionalValidatePlugin
    171159
    172 You have to adapt the given workflow to your own process but you get the idea.
     160You have to adapt the given workflow to your own process.
    173161
    174162=== Parent - child relationships
     
    178166 * th:SubticketsPlugin
    179167 * th:MasterTicketsPlugin
    180  * th:ChildTicketsPlugin (my preferred solution and described here)
     168 * th:ChildTicketsPlugin (described here)
    181169
    182170For requirements tickets the th:ChildTicketsPlugin adds buttons to the ticket page to create a child ticket of type {{{requirement}}} or {{{testcase}}}. Any child tickets are directly shown on the ticket page.
     
    184172See th:ChildTicketsPlugin/Examples for some screenshots of the plugin in action.
    185173
    186 Add the following to your `trac.ini` file to use th:ChildTicketsPlugin:
     174Add the following to your `trac.ini` file:
    187175{{{#!ini
    188176[childtickets]
     
    208196}}}
    209197
    210 With the given settings only tickets with type {{{requirement}}} or {{{testcase}}} are allowed as children of requirements tickets. Testcase tickets can't have any children. If you use your environment also for issue tracking it may be necessary to change the configuration to allow other ticket types like {{{defect}}} or {{{task}}} tickets.
     198With the given settings only tickets with type {{{requirement}}} or {{{testcase}}} are allowed as children of requirements tickets. Testcase tickets can't have any children. If you use your environment also for issue tracking, then it may be necessary to change the configuration to allow other ticket types like {{{defect}}} or {{{task}}} tickets.
    211199
    212200See the th:ChildTicketsPlugin page for more configuration options.
    213201
    214 There is a macro th:ChildTicketTreeMacro to show a ticket hierarchy everywhere where wiki content is allowed. This may be useful for reporting purposes.
     202You can use th:ChildTicketTreeMacro to show a ticket hierarchy everywhere where wiki content is allowed, which may be useful for reporting purposes.
    215203
    216204=== Requirements grouping
    217205
    218 Grouping may be achieved by specifying different requirement types. Each level of the '''V model''' is mapped to a different ticket type. This is probably not practical enough when you have several thousand requirements for a single level.
    219 
    220 Additional grouping may be done using the {{{component}}} field of a ticket or a custom ticket field. In our environment this is done using the custom field {{{docid}}}, because every requirement starts life in an external document with a unique document id which is imported into Trac after approval.
    221 
    222 For this add the following to your `trac.ini` file:
     206Grouping of requirements may be achieved by specifying different requirement types. Each level of the '''V model''' is mapped to a different ticket type. This is probably not practical enough when you have several thousand requirements for a single level.
     207
     208Additional grouping may be done using the {{{component}}} field of a ticket or a custom ticket field. This can be done using the custom field {{{docid}}}, because a requirement typically starts life in an external document with a unique document id which is imported into Trac after approval. To prepare for import and subsequent grouping add the following to your `trac.ini` file:
    223209{{{#!ini
    224210[ticket-custom]
     
    229215}}}
    230216
    231 By grouping it's possible to find requirements belonging to some part of your product/project. For example in hardware development you may group all requirements pertaining to the power supply by one id, thus making it easy for the power supply people to check for fullfillment.
     217By grouping it's possible to find requirements belonging to some part of your product/project. For example in hardware development you may group all requirements pertaining to the power supply by one id, thus making it easy for the power supply people to check for fulfillment.
    232218
    233219=== Cleaning up the ticket page
    234220
    235 Depending on your audience the ticket page may be overwhelming, because of all the fields. But there are quite a few plugins to hide unneeded ticket fields or prevent changes.
    236 
    237 th:CondFieldsGenshiPlugin is one of them and is used here to disallow changing the ticket type field. It's unlikely that a requirement morphs into a test case, so preventing any accidental damage is a good idea.
    238 
     221To some users the fields on the ticket page may be overwhelming. With the th:CondFieldsGenshiPlugin or th:DynamicFieldsPlugin it is possible to hide unneeded ticket fields or prevent undue changes. It's unlikely that a requirement morphs into a test case, so preventing any accidental damage is a good idea.
     222
     223With the th:CondFieldsGenshiPlugin add the following to your `trac.ini` file:
    239224{{{#!ini
    240225[components]
     
    250235}}}
    251236
    252 Hide any other ticket fields you don't want your users to see or change.
    253 
    254237=== Possible improvements
    255238
    256 What is described here is a basic solution which may already work for you. You possibly want in addition:
     239What has been described so far is a basic solution that may already work for you. You possibly want in addition:
    257240
    258241* Some reporting: use TicketQuery for that or create TracReports.