Ok, so I am finally getting around to post about day 2 of the requirements conference. Business has been great lately and so we have all had our noses to the grindstone but I finally found a spare moment to get these out.

RE06 was definitely an eye opening experience to me as I mentioned in my last post. The gap between academia and industry is like the gulf between the middle east and the west. On day 1 I went to a number of talks that were extremely technical in nature and it was hard to see how the research could be applied to real world problems. In discussing the conference with practitioners, they were in strong agreement. Therefore on day 2 I decided to attend the industry talks.

At the keynote on Day 2, Dorothy Graham talked about “Testing to Improve Requirements – Mission Impossible?” .

According to Graham, the fundamental questions about the relationship between requirements and testing are how do you develop tests from the requirements and when do you develop tests from the requirements. She discussed the V-model which describes development activities down the left side of the V and test/verification up the right side. For every activity on the design side, there is a corresponding test activity on the verification side. Her experience is that the very act of test design improves the requirements by forcing people to think about the requirements in a different way.

She gave two projects in contrast as examples. In the first project the team developed for 2 months then tested for 2 months with the test cases defined at the end of the process. This resulted in 150 faults discovered during test and 50 faults discovered in the first month of deployment. This was an extremely poor result. In phase 2 the team took a different approach, They took 2 months for development and 6 weeks for testing, with the tests designed upfront. The result was that there were only 50 faults found during the test cycle and no faults found in the first month. Now fans of Test Driven Development this may be a no brainer, but this is actually something slightly different in that the developers are working to tests created by the test team vs. unit/system tests created by the developers.

The essence of why this works is that the developers and product managers can effectively test the system during the whole project rather than at the end.

I then attended the invited experience talks. Ivy Hooks discussed “Requirements Engineering, an Oxymoron”. The question that she asked was whether it was even possible to Engineer requirements or whether the nature of requirements was such that it was more art the engineering. Ivy emphasized that when gathering requirements, don’t get the requirements from stakeholders because they are often emotionally attached to features that have no use to the actual users. Ivy’s opinion seemed to be that while some process can be applied to requirements, the very nature of the activity is not engineering.

The last session I attended was the most interesting. It was a “birds of a feather session” to discuss requirements nomenclature. We had been working on nomenclature for the few months before RE 06, internally we had decided that non-functional requirements wasn’t a very useful term, we had defined what we really mean by requirements vs. design, business rules etc. Many of the attendees were some of the most famous people in the academic and industrial requirements world so I was very excited to learn what the standard terminology was from the leaders. What I actually learned was that apparently none of them could agree on what the standard terminology is. If you find that you are confused about requirements terminology, don’t feel bad because even the experts can’t agree on the meaning of the most common requirements words!

At the end of day 2 I left feeling great about where we are at. At ArgonDigital we are constantly trying to push our understanding of requirements but we did not have a good feel for what state of the art really was. We now understand that our methods really are novel for the industry and we will keep pushing the limits to create more complete and easier to use requirements.

Stay tuned for day 3 (hopefully before Jan 1)