Please login or join to subscribe to this thread
Linda, I don't focus too much on the deliverable part of it, but do try to make sure that traceability exists.
1. I want to be able to validate that all my Requirements have a way to be satisfied (through an activity, task, work package etc.). For example, a functional requirement for an IT application has corresponding Development/Configuration/Testing etc. tasks associated with it. This validation helps me to ensure that all my Requirements are being addressed and there won't be gaps
2. I want to be able to validate that all my activities/tasks/work packages are originating from a Requirement. This validation helps make sure that we are not doing any work that is not required.
I simplify as: Is it necessary? and Is it sufficient?
There are some templates available on the site - for example: http://www.projectmanagement.com/deliverab...eability-Matrix
As for tools: At the present time, I am working to implement Traceability using a tool called JIRA. I have created a hierarchy of task types to help me with this. Using JIRA helps me solve various things at one time and I feel it is much easier to manage than a spreadsheet/word document if you have requirements in the 100s
Thanks, Samuel. JIRA looks like an agile/scrum toolset for the development team. Our IT Team is currently using TFS (which is clunky and not user friendly how we have it deployed). I am hoping to find a COTS solution that focuses primarily on the requirements piece and isn't tied to a methodology like agile. We're attempting to use the RTM concept on all of projects (IT and non-IT) and I would like to create an enterprise database of requirements that can be reused.
The primary advantage I had with JIRA was that the Development team was using it i.e. we had already purchased it.
What I did was simply to recognize the power of the tool in simply managing work - so many tasks and issues, keeping the details straight, carrying over changes in one thing to everything else that gets impacted, etc... With categorizations, alerts, reporting etc. etc., JIRA offered so much power. So we started using it for cross-functional issue tracking replacing the hard-to-manage Excel approach.
From my experience, JIRA is not tied to a methodology... we can customize it for many things. (Understandably, there can be resistance in creating a separate structure, adding non-IT users etc., but in our case the Exec team pushed for it – since our mis-management of issues was directly causing project delays).
Our organization has also used Atlassian's Confluence as a complementary Requirements Management tool. (I don’t fully understand where Confluence ends and JIRA begins.)
Hopefully there are other ideas in this community that we can learn from.
IBM rational team concert is one good tool for your purpose but licensing will be costly.
Plus my vote for JIRA as well.
Linda, structure and format of RTM depend on many factors like project life cycle, culture, and environment.
I'm looking for a bi-directional requirements trace-ability matrix template. Appreciate if someone can help me here!
Linda yes I use it all the time and the key to a good traceability matrix is that is must allow you to.... yes trace the requirement back to its origins. So the number of elements that you would maintain in your matrix will vary depending on the type of project i.e. development, software upgrade etc. I typically make sure that I know who raised the requirement, department and function. Then for each step in between, I would have the reference and the status i.e. Jira number, User story number, Test Case number and so forth. So for any requirement, I can see from the matrix exactly where it is at but more importantly, where it was. But each situation might be different since you might use different processes and tools to manage requirements.
One place I worked attempted to create a requirements database. We had developed a complex enterprise-wide solution for the insurance industry. There were thousands of requirements. After much effort, we learned that the database would not deliver the value to offset the maintenance cost. We discovered requirements evolved over time; they were superseded, or sunset, and technology changes impacted some. It just wasn't worth the effort to maintain the database.
It is one of the deliverable I never forget. Project Manager is not accountable for RTM. Business Analyst/BRM is accountable for RTM. Project Manager uses RTM as a tool for performing Project Scope Verification. The format for RTM must be decided aligened to the Configuration Management process.
Hi Linda, having an RTM is a great tool for measuring the success of a projects as well as ensuring unnecessary work is not carried out. The need for an excel or a tool like Jira or Rational will be dependent on the number of requirements and type of project as per @Anton's response.
The RTM is also a good way to ensure that changes throughout the project are properly defined and tracked, build alignment through business-BA understanding-Design - Development-Testing and operational handover.
The precursor to building this is the signed off Requirements document which will have a MoSCoW rating (Must Have, Should have, Could have and Would/Wont have), based on budgets and timeframes will depend what gets through to the final approved requirements set. Changes throughout the project can be tracked back to the MoScOW analysis to ensure that the change doesn't relate to something that someone thinks is a "nice to have" rather than an agreed requirement prior to being added in.
The final part of the RTM is an RTM review at the end of the project as an part of the lessons learnt. If there are missing functionality this can be traced through the document and you can find out where something slipped through the cracks, without an RTM its based on assumptions as to who missed it.
Hope this helps
Please login or join to reply