January 31, 2007 – 11:50 am
Contour’s cross project linking allows a project to reference a requirement in a separate project.
Several clients had requested the ability to link requirements (or any items for that matter) across different projects. During analysis we realized that there were several possible implementations.
One option was to completely link an item from one project into another, such [...]
January 29, 2007 – 8:42 pm
With the release of Contour 1.3 users are able to see immediately the project artifacts – and team members working on those items that may be affected. This is one of the primary benefits or implementing project traceability.
For example, if I am a business analyst and I’m about to make a change to a [...]
January 9, 2007 – 9:22 pm
The latest release of Contour, our requirements management tool, incorporates some new features that got me thinking about traceability.
At Jama we use relationship and traceability interchangeably. To us the term “relationship†is much easier to understand than “directional trace†even though it may not be technically correct. (Contour can be set to use whatever [...]
October 8, 2006 – 2:58 pm
Contour requirements management tool is now integrated with Open QA’s Selenium core!
We were having trouble testing our own application as it uses Ajax extensively and our test tools were causing us grief. We switched to Selenium and it’s worked great for us – after a bit of learning. In fact we liked it so much [...]
There is a bit of irony in building a tool without a tool. It’s like building a table for a workbench so you can then build a table. So far we have been very efficient in our process of building our Requirements Management tool. We have a small team, with white boards and a wiki. [...]
Project teams often struggle with how much time to spend on requirements. I was reading the book “Just Enough Requirements Management” by Alan Davis and liked what he had to say.
“Documenting requirements is a lot like purchasing insurance. If you do not buy enough, you can end up with disastrous consequences. If you buy too [...]
This article states that “developer misunderstandings of user requirements are the leading cause of defects in software.” I do believe the developer should be better connected to the actual requirement. However even when using different methodologies, like Agile, there can be a disconnect. Documentation, conversations, phone calls, meetings after meetings all take place before the [...]
What exactly does an analyst do? This role varies from project team to project team – but the essence is the same – understanding and documenting an approach to a problem then figuring out how to communicate it back to the stakeholders and the project team.
Karl Wiegers has a nice summary of the Analyst position [...]
I’ve been asked why we separated business rules from requirements in Contour. When we designed the application we decided to keep rules separated so they could be reused and linked to multiple requirements. I decided to do a little research to see if that makes sense.
Ellen Gottesdiener of ebg consulting has written a number of articles on [...]