Vi+ schrieb: > I asked the same question almost half a year ago (http:// > groups.google.com/group/trac-users/browse_frm/thread/ > 4c4bbe671d17ef70/10c0b97d63e93784)... Trac is very good, powerful, > and customizable for issue tracking (we are using it in full volume), > but it seems, like there is still no applicable plugins for > requirement processing and automated testing support, and another > mature software development engineering activities... unfortunately... > > +1
I'm also looking for an easy document management system with states like draft, reviewed, approved and expired which fits perfect into trac. I think also that the requirements module has a lot in common with a document management module. I know, technically it is currently already possible to tag a page with the state, but this is to limited for my needs, since it is not versioned. Also we have the important need to integrate a QATest module, e.g. similiar to QaTraq but a little easier. One of my favorites wishes is to be able to tag the current state of tracs WIKI pages (or subpages) and tie them to a specific version of the software. I think this will come up in the two above modules again. What happens whem a requirement change from one version to the next. How do you know, which version of the requirement was valid for a specific release of the software. I know, that only talking about whishes is too less to get ahead, so I really would like to start collection the requirements for such an extension/extensions. We are willing to hire a student, who could do the implementation for us. So what are your Use Cases and your requirements? Mine are: [Requirement Management] * Capture Requirements of a project and assign unique numbers to each requirement * Each requirement consists at least of the title, a description, a priority, a state (draft, approved, ...). * Group requirements into packages and subpackages (hierachically) * Every change to the requirement must be traceable to the person who did the change * Changes are only possible with specific rights in specific states of the requirement. * Possiblitiy to incrementally update requirements after the requirements have been approved. * Possibility to break a requirement into multiple requirements and to trace the branches back to the root. ===Link to version=== In a specific version a specific set of requirements is fully or partially implemented * Specify a specific set of requirements to be implemented in a specific version * Get a list of implemented requirements for a specific version * Check the implementation status for each implemented requirement for each specific version * Update the requirement if the implementation status of the current version [Document management] * Manage documents through out there different states: draft, review, approved, expired * trace every change to the document * Changes to specific states are only possible with specific rights. * Easy handling of updates to the documents, best would be integration into the windows shell like TortoiseSVN * Manage all kind of documents, text, word, images, ... * Restrict access to validated users for each document specifically * Provide an automatic change history for each document * Possibility to assign a customer document type and number to each document * List of all managed documents * Easy access to all approved and published documents == Link to version=== * If a document is only valid for a specific version, it must be possible to list the document version that was valid for the specific software version. [Quality Test managament] * write small testscripts that must be acknowledged for each tested version * collect testscripts into large testplans * link testscripts to requirements * When a test is performed for a specific version, the results (failed/passed) must be collected together with the exact version of the testscript, the user, the time and a possible description * Testscripts should be lightwight, so that they can be printed in a list, if they are collected within a testplan. * Status of testsresults are: passed, passed with comment, failed === Link to version === * It must be possible to see, which tests have been performed for wich version * It must be possible to see, which tests are sheduled to be done for a specific version * A release test can be finished prematurally, so all outstanding tests must marked as discarded. * Possibility to officially publish a release only, when all sheduled test have been passed. So this is a quick late night brain storm out of my head. I'm willing to start any further discussion and to collect further requirements. Best regards Dirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
