You know I study methodologies. I like to think of a methodology as an entity that is created, used and perfected over time. Following this approach, engineering practices can be applied to the creation and maintenance of methodologies, very much like you create and maintain a house, a bridge or a piece of software. You study the context, make sure you understand it, design a solution, implement the solution and put it to work. Usually, changes and adjustments are necessary once the thing (house, bridge, piece of software or methodology) is working; that’s fine.
One of the crucial tasks in this approach is determining the requirements of the thing to build, i.e. what its future users expect from it. Usually, this is achieved by talking to the future users of the thing (plus perhaps other stakeholders), analysing what they say, documenting everything and validating against them that what has been documented really expresses what they really want. This general approach, usually called “requirements engineering”, is often used for software development and, as far as I understand, in other areas of engineering as well.
