| 4 | | Every once in a while there is a question about doing requirements management with Trac. For quite some time there is a th:Request-a-Hack for a plugin implementing it, see th:#1226. While having an out of the box solution would be nice there are quite a few plugins which can be leveraged for building a requirements management solution. |
| 5 | | |
| 6 | | On this page one possible approach is shown for doing so. I'm working in development of [https://en.wikipedia.org/wiki/IEC_61508 IEC 61508] compliant control devices. We use Trac for doing all the requirements tracking mandated by the aforementioned standard. For a mid-sized project we currently track something like 4000-6000 requirements and testcases. |
| 7 | | |
| 8 | | Be aware that the solution presented here may or may not work for you. We use quite some custom made plugins to support our internal processes wrt requirements tracking. These plugins are private and you may have to create your own to scratch your own itch. |
| | 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 |
| 11 | | Don't select a tool because it's fancy and then model your requirements management process so it can be supported by the tool. This will fail in the end. |
| 12 | | |
| 13 | | Make sure you know your process and environment, e.g. |
| 14 | | * Which types of requirements do you have? System requirements, functional requirements, test cases, ... ? |
| 15 | | * Who is writing them? The tech people or maybe management people? You will learn that it may be impossible to drag your mangement people away from MS Word and friends. So you may need a Word document importer. |
| 16 | | * Is there a predefined workflow for requirements, e.g. ''draft->in review->approved->closed''? |
| 17 | | * Is the workflow dependent on the type of requirement? |
| 18 | | * How do you manage changes to requirements? |
| 19 | | * What about roles and permissions in the process? |
| 20 | | * Do you need some kind of sign off? |
| 21 | | * It may be necessary to import data from other tools or departments. For example the test department may be using their own tool chain and even their own bug tracker. |
| 22 | | * ... |
| 23 | | |
| 24 | | 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. |
| | 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. |
| | 16 | |
| | 17 | Make sure you know your process and environment: |
| | 18 | * 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. |
| | 21 | * Is there a predefined workflow for requirements, eg {{{ draft -> in review -> approved -> closed }}}? |
| | 22 | * Is the workflow dependent on the type of requirement? |
| | 23 | * 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? |
| | 26 | * 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. |
| | 27 | |
| | 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. |
| 36 | | * {{{requirement}}} |
| 37 | | * {{{testcase}}} |
| 38 | | |
| 39 | | 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 [https://en.wikipedia.org/wiki/V-Model_(software_development) ''V model''] but nobody stops you from doing so. |
| 40 | | |
| 41 | | For administrating ticket types go to the ''admin'' area of your Trac installation or use the command line interface. |
| 42 | | |
| 43 | | {{{ |
| 44 | | trac-admin /path/to/projenv ticket_type add requirement |
| 45 | | |
| 46 | | trac-admin /path/to/projenv ticket_type add testcase |
| | 43 | * {{{requirement}}} |
| | 44 | * {{{testcase}}} |
| | 45 | |
| | 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. |
| | 47 | |
| | 48 | For administrating ticket types go to the '''Admin''' area of your Trac installation or use the command line: |
| | 49 | {{{#!sh |
| | 50 | $ trac-admin /path/to/projenv ticket_type add requirement |
| | 51 | $ trac-admin /path/to/projenv ticket_type add testcase |
| 154 | | In this workflow special permissions as defined in section [#Definingroles Defining roles] are used to control access. You may leverage the full power of [TracWorkflow TracWorkflow]s here, for example assigning new owners on state change. |
| 155 | | |
| 156 | | Using some validation plugin correct values in required ticket fields can be enforced. Have a look at |
| 157 | | * th:TicketValidatorPlugin |
| 158 | | * th:TracTicketValidatorPlugin |
| 159 | | * th:TracTicketConditionalValidatePlugin |
| | 164 | |
| | 165 | In this workflow special permissions as defined in section [#Definingroles Defining roles] are used to control access. You may use the full power of [TracWorkflow TracWorkflow]s here, for example assigning new owners on state change. |
| | 166 | |
| | 167 | Using one of the following validation plugins, correct values in required ticket fields can be enforced: |
| | 168 | * th:TicketValidatorPlugin |
| | 169 | * th:TracTicketValidatorPlugin |
| | 170 | * th:TracTicketConditionalValidatePlugin |
| 163 | | === Parent - child relationship |
| 164 | | There **must** be some kind of parent - child relationship between tickets so one may follow the chain of requirements in forward and backwards direction. The following plugins are suitable: |
| 165 | | |
| 166 | | * th:SubticketsPlugin |
| 167 | | * th:MasterTicketsPlugin |
| 168 | | * th:ChildTicketsPlugin (my preferred solution and described here) |
| 169 | | |
| 170 | | |
| 171 | | For requirements tickets th |
| | 174 | === Parent - child relationships |
| | 175 | |
| | 176 | There **must** be some kind of parent - child relationship between tickets, so one may follow the chain of requirements in forward and backwards direction. The following plugins can be used for this: |
| | 177 | |
| | 178 | * th:SubticketsPlugin |
| | 179 | * th:MasterTicketsPlugin |
| | 180 | * th:ChildTicketsPlugin (my preferred solution and described here) |
| | 181 | |
| | 182 | For 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. |
| 207 | | 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 because you may have several thousand requirements for a single level. |
| 208 | | |
| 209 | | 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. |
| 210 | | |
| 211 | | For this add the following to your trac.ini: |
| | 217 | |
| | 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: |
