I was talking to my good friend Andrew Delin about how the original MSF 1.0 had several concepts which today are associated with Agile methodologies. One such concept was the polemic "Why No Requirements Document?" one. The main point in this doc is:
· Users/customers generally don't know what they want or need until they gain some familiarity with what they can have;
The solution presented at the time resonates with what has become common today:
The SDD process model does not ignore customer requirements. They are accommodated through:
· early identification of driving requirements and constraints as a part of defining the project scope [i.e, Vision Scope document];
· establishing traceability through analysis techniques like activity-based analysis, in which all features specified in the Functional Specification are traceable to specific user activities or tasks identified in the analysis activities [i.e. Personas and a list of Scenarios];
· controlled revision of project scope and Functional Specification documents to reflect changing or better-understood requirements [i.e. Functional Spec as a collection of Scenarios which can be modified or postponed to a later iteration ("versioned releases" at the time)].
These and other gold nuggets are in MSF 1.0 RC1.