Did you know that you’re smarter than a rocket scientist? Seriously! In a presentation at the Requirements Engineering Education and Training (REET08) workshop today, one of the presenters talked about his experiences with teaching Requirements Engineering (RE) techniques to European space agency employees, most of whom had PhD’s in math and/or physics — actual rocket scientists! As part of the presentation, he said that those scientists said that they weren’t able to do RE, and that it should be left to people who had those skills. So kudos, RE community — you’re smarter than rocket scientists!
In other (and only slightly less exciting) news from today’s workshop, we heard a lot of great ideas from academics and industry professionals who teach the next wave of Requirements Engineers. Tony Gorschek presented his current conundrum in teaching RE, namely that he has only 5 weeks of instruction time to deliver the only RE course in his school’s program. Which topics are most important? Do you teach students to write clear, concise, testable requirements, or do you teach them to be great product managers who understand business realities and can plan product releases accordingly? Yes, we did suggest that he teach both, but time constraints won’t allow it. And appropriately enough, time constraints in the workshop kept us from discovering the answer!
Several presenters explained that they teach their programs’ RE courses at or near the end of students’ educational programs. The rationale for the placement of the classes is that students must understand how to be good software engineers before they can understand, apply and appreciate RE skills and practices. At first I thought this was the right order, but as the day went on and we heard about more and more challenges of this approach, I began to wonder if placing RE education at the end of software engineering education sends the right message. If something is as fundamental as we believe RE to be, then shouldn’t we make it a fundamental (rather than a capstone) element of RE education? Would the answer be different if the RE courses were part of a different degree program, like Industrial Engineering or Information Systems?
Finally, we talked quite a bit about the disconnect between industry’s needs and education’s focus, including training both in academia and in industry. Education in RE seems to provide controlled, well-formed, somewhat artificial problems for students to solve. Unfortunately, most of the projects we deal with in industry are subject to political forces, impacted by fickle market conditions, and just plain messy. How can academia best provide Requirements Engineers with both the problem-solving skills and the ability to deal with messes needed to do their jobs well.
Clearly, we identified more issues than definitive answers, but also we came up with a number of great ideas and new tools to help teach Requirements Engineers (and improve our own work on projects). All in all, it was a very educational day.
It’s been a great first two days at RE08 — stay tuned for more exciting adventures of the ArgonDigital team!
