Not summarizing the class contents, but just recording some thoughts. My disappointment is not with the instructor, who has great knowledge and interest and integrity -- a career focused on transforming software development art into repeatable craft; rather, I felt let down (as I so often am with methodologies) by the fundamental impracticality or impossibility of the methods being taught.

His premise was all about the primacy of requirements, that deeply comprehensive and accurate requirements make true engineering possible. I believe that. Yet human language-based requirements are wildly difficult to disambiguate, even with exhaustive effort; therefore, he proposes use case development and many other mapping activities to flesh out these details until validity/verifiability is fully realized.

Sounds fine, of course, but it wouldn't work in any of the shops I've been a part of. That intensive cycle of iteration through all of these requirements discovery activities is not ever allowed for in resource allocation -- and it's supposed to be done before any specification or development proceeds. And maybe it shouldn't be allowed, since the development process itself is such a critical discovery phase. Problem is that changes based on mid-development discovery rarely make their way back up to requirements and test docs, or in a way that is easy and efficient for everyone to follow. This is the critical problem that I hoped he could somehow speak to, which, I realize, is fundamentally a communication and knowledge management problem.

That said, it was a helpful review of use case structure and purpose, and a good reminder that we should test and document interactions, focusing on pre- and post-conditions on objectives rather than navel-gazing the system functionality.