This is the first time that I have been to this conference and honestly I didn’t know what to expect. I had several goals. I wanted to meet some of the well known names in the requirements field, I wanted to see what the cutting edge research in requirements looked like and I wanted to get a better understanding of current best practices.

What I have discovered so far is enlightening and also somewhat disappointing. If I had to summarize with one key theme, it is that academia is completely disconnected from the real world of requirements definition.

The first session this morning was the keynote by Mary Beth Rosson from Penn State. Her speech was titled “End Users Who Meet Their Own Requirements”. The talk discussed how users are programming directly today and that they do not do analysis and design. For example, Excel spreadsheets and Word macros are common, but very little analysis is done when they are developed. According to Rosson, the key is to provide users with the tools to help them get the solution correct. At first I thought that the topic was not relevant to my work on large scale enterprise systems. However as I thought about it more, I realized that many of the projects that we work on are conversions of systems built by the business side into applications that can be supported by the IT organization. These applications are typically extremely complex Excel spreadsheets or Microsoft Access databases.

The next set of presentations were research papers by doctoral candidates. The first paper was “A Case Study in Systematic Improvement of Language for Requirements.” This was probably the clearest of the presentations and possibly the most applicable to the real world. The essence of the presentation was a model for measuring the risk associated with your glossary (the termed them “concepts”). By counting the number of concepts and multiplying by the number of shared concepts the author claimed that you could get a measure of risk associated with your definitions.

The second paper was entitled “Generating Hierarchical State Machines From Use Case Charts“. The authors of this paper took use case charts and created additional UML 2.0 language constructs. Moreover they created a metholodgy to derive state models from the use case models. Frankly, this didn’t appear to have much practical value as the initial use case charts are a model that is simply too much work to do.

Stay tuned for a summary of the afternoon session!