Feature Driven Development

I teach this in the workshop and there's quite a bit of lead up to it. But the greatly simplified version is yes. You simply learn the intent of the FDD processes and once you understand that then you can adapt by applying different techniques, etc.

So, for a procedural (non OO) project. You first need to substitute something else for the Develop an Overall Model process. So, what's the intent of this process? It's an informational/analytical activity to gain enough knowledge to be able to build a features list with good coverage and good accuracy and then set a coarse-grained plain. So, if it's not OO then we need to substitute some other informational/analytical activity to gain enough knowledge to be able to build a features list with good coverage and good accuracy and then set a coarse-grained plain. I've seen several projects do this and consulted to a few as well.

Features List and Planning are unaffected. Next is Design by Feature. Here you don't do a sequence diagram so you want to substitute some other such design artifact. What did I do before I did OO? I used a functional spec like most other people; I used a modified and simplified version of the IBM Rochester I0 (inspection level 0) document but it's basically a functional spec.

Build by feature is unaffected.

Finally, you wouldn't have class owners as there are no classes but you will have module or component owners as that's where the class owner idea came from in the first place.

GK,

sorry but there's no stock answer for that. I've no idea what granularity you have in your features list. Generally, we don't try to align the code with the structure of the features list whether it's OO or procedural. That said, they often do look very similar and do line up in parts. That shouldn't be surprising as they're all just perspectives of the same problem domain. i.e. the model, the features list structure and the implementation.