| 5 | | Every once in a while there is a question about doing requirements management with Trac. For quite some time there is a Request-a-Hack for a plugin implementing it, see #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. |
| 6 | | |
| 7 | | On this page I (Cinc-th) want to show one possible approach 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. |
| 8 | | |
| 9 | | 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. |
| 10 | | |
| 11 | | == Before you start |
| 12 | | 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. |
| 13 | | |
| 14 | | Make sure you know your process and environment, e.g. |
| 15 | | * Which types of requirements do you have? System requirements, functional requirements, test cases, ... ? |
| 16 | | * 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. |
| 17 | | * Is there a predefined workflow for requirements, e.g. ''draft->in review->approved->closed''? |
| 18 | | * Is the workflow dependent on the type of requirement? |
| 19 | | * How do you manage changes to requirements? |
| 20 | | * What about roles and permissions in the process? |
| 21 | | * Do you need some kind of sign off? |
| 22 | | * 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. |
| 23 | | * ... |
| 24 | | |
| 25 | | 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. |
| 26 | | |
| 27 | | == Requirements management using Trac |
| 28 | | The following sections describe a bare bones implementation for requirements tracking using some available plugins. |
| 29 | | === Environment type |
| 30 | | 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. |
| 31 | | |
| 32 | | After the project is done one may revoke all write permissions and archive the complete environment so the current state of requirements is frozen. |
| 33 | | |
| 34 | | |
| 35 | | === Requirement types |
| 36 | | To distinguish requirements and test cases at least two new ticket types must be created: |
| 37 | | * {{{requirement}}} |
| 38 | | * {{{testcase}}} |
| 39 | | |
| 40 | | 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. |
| 41 | | |
| 42 | | For administrating ticket types go to the ''admin'' area of your Trac installation or use the command line interface. |
| 43 | | |
| 44 | | {{{ |
| 45 | | trac-admin /path/to/projenv ticket_type add requirement |
| 46 | | |
| 47 | | trac-admin /path/to/projenv ticket_type add testcase |
| 48 | | }}} |
| 49 | | |
| 50 | | TracAdmin describes the command line interface in full length. |
| 51 | | |
| 52 | | === Defining roles |
| 53 | | 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. For adding such custom permissions see: |
| 54 | | |
| 55 | | http://trac.edgewall.org/wiki/ExtraPermissionsProvider |
| 56 | | |
| 57 | | To define the additional permissions |
| 58 | | * {{{REQUIREMENT_APPROVE}}} |
| 59 | | * {{{REQUIREMENT_CLOSE}}} |
| 60 | | |
| 61 | | add the following to your trac.ini: |
| 62 | | {{{#!ini |
| 63 | | [components] |
| 64 | | tracopt.perm.config_perm_provider.ExtraPermissionsProvider = enabled |
| 65 | | |
| 66 | | [extra-permissions] |
| 67 | | REQUIREMENT_ADMIN = REQUIREMENT_APPROVE, REQUIREMENT_CLOSE |
| 68 | | }}} |
| 69 | | Note that this also defines the permission {{{REQUIREMENT_ADMIN}}} which grants {{{REQUIREMENT_APPROVE}}} and {{{REQUIREMENT_CLOSE}}}. |
| 70 | | |
| 71 | | === Creating specialized workflows |
| 72 | | A workflow for a requirement is very different from a standard issue workflow. Using MultipleWorkflowPlugin (disclaimer: I'm the maintainer) specific workflows for each new type may be created. |
| 73 | | |
| 74 | | Add this to your trac.ini: |
| 75 | | {{{#!ini |
| 76 | | [components] |
| 77 | | # Enable MultipleWorkflowPlugin |
| 78 | | multipleworkflow.* = enabled |
| 79 | | |
| 80 | | [ticket-workflow-requirement] |
| 81 | | # Create special workflow for tickets with type 'requirement' |
| 82 | | # Note that special permissions are used here |
| 83 | | leave = * -> * |
| 84 | | leave.default = 1 |
| 85 | | leave.operations = leave_status |
| 86 | | |
| 87 | | approve = new, reopened -> approved |
| 88 | | approve.operations = del_resolution |
| 89 | | approve.permissions = REQUIREMENT_APPROVE |
| 90 | | |
| 91 | | reopen_verified = closed -> reopened |
| 92 | | reopen_verified.name = Reopen |
| 93 | | reopen_verified.operations = set_resolution |
| 94 | | reopen_verified.set_resolution = from verified |
| 95 | | reopen_verified.permissions = TICKET_MODIFY |
| 96 | | |
| 97 | | reopen_approved = approved -> reopened |
| 98 | | reopen_approved.name = Reopen |
| 99 | | reopen_approved.operations = set_resolution |
| 100 | | reopen_approved.set_resolution = from approved |
| 101 | | reopen_approved.permissions = TICKET_CREATE |
| 102 | | |
| 103 | | remove = new, reopened, approved, closed -> removed |
| 104 | | remove.name = Remove this Requirement permanently |
| 105 | | remove.operations = set_resolution |
| 106 | | remove.set_resolution = removed |
| 107 | | remove.permissions = TICKET_MODIFY |
| 108 | | |
| 109 | | verify = approved -> closed |
| 110 | | verify.name = Verifiy the Requirement and mark |
| 111 | | verify.operations = set_resolution |
| 112 | | verify.set_resolution = verified |
| 113 | | verify.permissions = REQUIREMENT_CLOSE |
| 114 | | |
| 115 | | [ticket-workflow-testcase] |
| 116 | | leave = * -> * |
| 117 | | leave.default = 1 |
| 118 | | leave.operations = leave_status |
| 119 | | ... |
| 120 | | }}} |
| 121 | | {{{ |
| 122 | | #!Workflow width=800 height=400 |
| 123 | | leave = * -> * |
| 124 | | leave.default = 1 |
| 125 | | leave.operations = leave_status |
| 126 | | |
| 127 | | approve = new, reopened -> approved |
| 128 | | approve.operations = del_resolution |
| 129 | | approve.permissions = REQUIREMENT_APPROVE |
| 130 | | |
| 131 | | reopen_verified = closed -> reopened |
| 132 | | reopen_verified.name = Reopen |
| 133 | | reopen_verified.operations = set_resolution |
| 134 | | reopen_verified.set_resolution = from verified |
| 135 | | reopen_verified.permissions = TICKET_MODIFY |
| 136 | | |
| 137 | | reopen_approved = approved -> reopened |
| 138 | | reopen_approved.name = Reopen |
| 139 | | reopen_approved.operations = set_resolution |
| 140 | | reopen_approved.set_resolution = from approved |
| 141 | | reopen_approved.permissions = TICKET_CREATE |
| 142 | | |
| 143 | | remove = new, reopened, approved, closed -> removed |
| 144 | | remove.name = Remove this Requirement permanently |
| 145 | | remove.operations = set_resolution |
| 146 | | remove.set_resolution = removed |
| 147 | | remove.permissions = TICKET_MODIFY |
| 148 | | |
| 149 | | verify = approved -> closed |
| 150 | | verify.name = Verifiy the Requirement and mark |
| 151 | | verify.operations = set_resolution |
| 152 | | verify.set_resolution = verified |
| 153 | | verify.permissions = REQUIREMENT_CLOSE |
| 154 | | }}} |
| 155 | | 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. |
| 156 | | |
| 157 | | Using some validation plugin correct values in required ticket fields can be enforced. Have a look at |
| 158 | | * TicketValidatorPlugin |
| 159 | | * TracTicketValidatorPlugin |
| 160 | | * TracTicketConditionalValidatePlugin |
| 161 | | |
| 162 | | You have to adapt the given workflow to your own process but you get the idea. |
| 163 | | |
| 164 | | === Parent - child relationship |
| 165 | | 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: |
| 166 | | |
| 167 | | * SubticketsPlugin |
| 168 | | * MasterTicketsPlugin |
| 169 | | * ChildTicketsPlugin (my preferred solution and described here) |
| 170 | | |
| 171 | | |
| 172 | | For requirements tickets ChildTicketsPlugin adds buttons to the ticket page to create a child ticket of type {{{requirement}}} or {{{testcase}}}. If there are already some children these are shown on the ticket page. |
| 173 | | |
| 174 | | See https://trac-hacks.org/wiki/ChildTicketsPlugin/Examples for some screenshots of the plugin in action. |
| 175 | | |
| 176 | | Add the following to your trac.ini to use ChildTicketsPlugin: |
| 177 | | {{{#!ini |
| 178 | | [childtickets] |
| 179 | | # Allow child tickets for tickets of type 'requirement' |
| 180 | | parent.requirement.allow_child_tickets = true |
| 181 | | # Restrict child ticket types |
| 182 | | parent.requirement.restrict_child_type = requirement, testcase |
| 183 | | # Define the table headers to be shown for child tickets |
| 184 | | parent.requirement.table_headers = summary, type, status, component, description |
| 185 | | # No child tickets for ticket type 'testcase' |
| 186 | | parent.testcase.allow_child_tickets = false |
| 187 | | |
| 188 | | [components] |
| 189 | | # Enable ChildTicketsPlugin |
| 190 | | childtickets.* = enabled |
| 191 | | childtickets.childtickets.tracchildticketsmodule = enabled |
| 192 | | |
| 193 | | [ticket-custom] |
| 194 | | # Define ticket custom field for use with ChildTicketsPlugin |
| 195 | | parent = text |
| 196 | | parent.format = wiki |
| 197 | | parent.label = Parent ID |
| 198 | | }}} |
| 199 | | |
| 200 | | 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. |
| 201 | | |
| 202 | | |
| 203 | | See the ChildTicketsPlugin page for more configuration options. |
| 204 | | |
| 205 | | There is a macro ChildTicketTreeMacro to show a ticket hierarchy everywhere wiki content is allowed. This may be useful for reporting purposes. |
| 206 | | |
| 207 | | === Requirements grouping |
| 208 | | 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. |
| 209 | | |
| 210 | | 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. |
| 211 | | |
| 212 | | For this add the following to your trac.ini: |
| 213 | | {{{#!ini |
| 214 | | [ticket-custom] |
| 215 | | # Define field for grouping of requirements |
| 216 | | docid = text |
| 217 | | docid.format = text |
| 218 | | docid.label = Document ID |
| 219 | | }}} |
| 220 | | |
| 221 | | 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. |
| 222 | | |
| 223 | | === Cleaning up the ticket page |
| 224 | | 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. |
| 225 | | |
| 226 | | CondFieldsGenshiPlugin is one of them and is used here to disallow changing of the ticket type field. It's unlikely a requirement morphs into a testcase so preventing any accidental damage is a good idea. |
| 227 | | |
| 228 | | {{{#!ini |
| 229 | | [components] |
| 230 | | condfieldsgenshi.* = enabled |
| 231 | | |
| 232 | | [condfieldsgenshi] |
| 233 | | # We only tweak the 'type' filed atm |
| 234 | | tweaks = type |
| 235 | | default = enable |
| 236 | | |
| 237 | | # Disable ticket type field |
| 238 | | type.type_cond = requirement, testcase |
| 239 | | }}} |
| 240 | | Hide any other ticket fields you don't want your users to see or change. |
| 241 | | |
| 242 | | === Possible improvements |
| 243 | | As written before this presents a basic solution which may already work for you. You possibly want in addition: |
| 244 | | |
| 245 | | * Some reporting. You may use TicketQuery for that or create TracReports. |
| 246 | | * Sign of for requirements. You may use this: trac:CookBook/Configuration/SignedTickets |
| 247 | | * ... |
| 248 | | |
| 249 | | == Summary |
| 250 | | Install the following plugins: |
| 251 | | * MultipleWorkflowPlugin |
| 252 | | * ChildTicketsPlugin |
| 253 | | * CondFieldsGenshiPlugin |
| 254 | | |
| 255 | | Add the following settings to your trac.ini: |
| 256 | | {{{#!ini |
| 257 | | [childtickets] |
| 258 | | # Allow child tickets for tickets of type 'requirement' |
| 259 | | parent.requirement.allow_child_tickets = true |
| 260 | | # Restrict child ticket types |
| 261 | | parent.requirement.restrict_child_type = requirement, testcase |
| 262 | | # Define the table headers to be shown for child tickets |
| 263 | | parent.requirement.table_headers = summary, type, status, component, description |
| 264 | | # No child tickets for ticket type 'testcase' |
| 265 | | parent.testcase.allow_child_tickets = false |
| 266 | | |
| 267 | | [components] |
| 268 | | # Enable ChildTicketsPlugin |
| 269 | | childtickets.* = enabled |
| 270 | | childtickets.childtickets.tracchildticketsmodule = enabled |
| 271 | | # Enable CondFieldsGenshiPlugin |
| 272 | | condfieldsgenshi.* = enabled |
| 273 | | # Enable MultipleWorkflowPlugin |
| 274 | | multipleworkflow.* = enabled |
| 275 | | # Remove this if you need no special permissions |
| 276 | | tracopt.perm.config_perm_provider.ExtraPermissionsProvider = enabled |
| 277 | | |
| 278 | | [condfieldsgenshi] |
| 279 | | # We only tweak the 'type' filed atm |
| 280 | | tweaks = type |
| 281 | | default = enable |
| 282 | | # Disable ticket type field |
| 283 | | type.type_cond = requirement, testcase |
| 284 | | |
| 285 | | # Remove this section if you need no special permissions |
| 286 | | [extra-permissions] |
| 287 | | REQUIREMENT_ADMIN = REQUIREMENT_APPROVE, REQUIREMENT_CLOSE |
| 288 | | |
| 289 | | [ticket] |
| 290 | | # Use MultipleWorkflowPlugin for ticket workflows |
| 291 | | workflow = MultipleWorkflowPlugin |
| 292 | | |
| 293 | | [ticket-custom] |
| 294 | | # Define ticket custom field for use with ChildTicketsPlugin |
| 295 | | parent = text |
| 296 | | parent.format = wiki |
| 297 | | parent.label = Parent ID |
| 298 | | # Define field for grouping of requirements |
| 299 | | docid = text |
| 300 | | docid.format = text |
| 301 | | docid.label = Document ID |
| 302 | | |
| 303 | | [ticket-workflow-requirement] |
| 304 | | # Create special workflow for tickets with type 'requirement' |
| 305 | | # Note that special permissions are used here |
| 306 | | leave = * -> * |
| 307 | | leave.default = 1 |
| 308 | | leave.operations = leave_status |
| 309 | | |
| 310 | | approve = new, reopened -> approved |
| 311 | | approve.operations = del_resolution |
| 312 | | approve.permissions = REQUIREMENT_APPROVE |
| 313 | | |
| 314 | | reopen_verified = closed -> reopened |
| 315 | | reopen_verified.name = Reopen |
| 316 | | reopen_verified.operations = set_resolution |
| 317 | | reopen_verified.set_resolution = from verified |
| 318 | | reopen_verified.permissions = TICKET_MODIFY |
| 319 | | |
| 320 | | reopen_approved = approved -> reopened |
| 321 | | reopen_approved.name = Reopen |
| 322 | | reopen_approved.operations = set_resolution |
| 323 | | reopen_approved.set_resolution = from approved |
| 324 | | reopen_approved.permissions = TICKET_CREATE |
| 325 | | |
| 326 | | remove = new, reopened, approved, closed -> removed |
| 327 | | remove.name = Remove this Requirement permanently |
| 328 | | remove.operations = set_resolution |
| 329 | | remove.set_resolution = removed |
| 330 | | remove.permissions = TICKET_MODIFY |
| 331 | | |
| 332 | | verify = approved -> closed |
| 333 | | verify.name = Verifiy the Requirement and mark |
| 334 | | verify.operations = set_resolution |
| 335 | | verify.set_resolution = verified |
| 336 | | verify.permissions = REQUIREMENT_CLOSE |
| 337 | | |
| 338 | | # Create your testcase workflow here |
| 339 | | [ticket-workflow-testcase] |
| 340 | | leave = * -> * |
| 341 | | leave.default = 1 |
| 342 | | leave.operations = leave_status |
| 343 | | ... |
| 344 | | }}} |
| 345 | | |
| 346 | | On the command line enter the following commands to add ticket types: |
| 347 | | |
| 348 | | {{{ |
| 349 | | trac-admin /path/to/projenv ticket_type add requirement |
| 350 | | |
| 351 | | trac-admin /path/to/projenv ticket_type add testcase |
| 352 | | }}} |
| | 3 | trac:CookBook/Configuration/RequirementsManagement |
