Note

This page is work in progress

Requirements Management

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.

On this page I (Cinc-th) want to show one possible approach for doing so. I'm working in development of ​IEC 61508 compliant control devices. We use Trac for doing all the requirements tracking mandated by the aforementioned standard.

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 to requirements tracking. These plugins are private and you may have to create your own to scratch your own itch.

Before you start

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.

Make sure you know your process and environment, e.g.

• Which types of requirements do you have? System requirements, functional requirements, test cases, ... ?
• 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.
• Is there a predefined workflow for requirements, e.g. draft->in review->approved->closed?
• Is the workflow dependent on the type of requirement?
• How do you manage changes to requirements?
• What about roles and permissions in the process?
• Do you need some kind of sign off?
• 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.
• ...

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.

Requirements management using Trac

Each project lives in a separate environment. 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.

After the project is done one may archive the complete environment so the current state of requirements is frozen.

Requirement Types

To distinguish requirements and test cases at least two new ticket types are created:

• requirement
• testcase

Since we only track our requirements in the Trac environment all other ticket types are removed. There is no need to create special types for each level of a V model but nobody stops you from doing so.

Parent - Child relationship

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:

• SubticketsPlugin
• MasterTicketsPlugin
• ChildTicketsPlugin (my preferred solution and described here)

Requirements Grouping

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 sufficient because you may have several thousand requirements for a single level.