Software projects should NOT be Requirements-driven. Projects should be Usability-driven and Prototype-driven. Software design is akin to the chef building a great recipe, not the cook following the recipe.
Business Process Analysis & Software Design
The closest kin of the Software Design process is Business Process Analysis. Business Process Analysis is not a process whereby you start with a set of Business Rules and then figure out how to enforce those rules on your process. Any BP analyst worth their pay grade would throw you out of the room if your goal was to start with a set of rules and impose them on your process. Business Process Analysis is a process whereby you examine your process and end up with a set of Business Rules that will make your process run better, i.e. more smoothly, efficiently, cheaply, etc. The Business Rules are the outcome.
Prototypes & Software Design
The same is true with software development projects. The result of the software development process is a set of rules governing the process, encapsulated in the computer logic of the software. A Requirements Document is a summary of the rules uncovered during the Business Process analysis, documented so that the rules are implemented correctly in software language.
Analysis drives the Prototype. Developers build prototypes to clarify the business process. Requirement documents capture the discoveries of the prototypes. Developers build according to the resulting requirement documents. Quality control tests the software against the desired outcomes documented in the requirements.
Too many companies go straight from Analysis to Requirements to Software Code, skipping the prototypes. Or they go from Analysis to Requirements to Prototype to Software Code, which is also wrong. What's missing in these approaches is the best way to get from Analysis to the Requirements - Prototypes and Usability Studies. One of the core lessons of Usability is that no matter how well you think you might have thought a Business Process through, when you sit real users in front of your application, invariably they will try to use it in a different way than you designed it. I call it the Usability Corollary of Murphy's Law.
Usability Maxim #1: The earlier and more often you can put meaningful prototypes in front of real users, the more accurate your resulting Requirements will be.
Cascading from this maxim is the fact that anything that facilitates prototyping will benefit your project. The use of common libraries of code, config files, and WYSIWYG tools may seem like wasteful shortcuts to some, but their real benefit is in turnaround time. The faster the turnaround, the more prototypes you can introduce into your process. You can always go back, once you've flushed out (and fleshed out) your Requirements, and replace the shortcuts with more refined, more detailed, and more efficient code, but the role of development in the first half (or more) of any Software Design project is to drive understanding of the process and help solidify the Requirements.
Now, this may sound like I'm contradicting my thesis. It may sound like I'm just confirming that the Requirements are the most important part of any analysis process. The distinction that I'm trying to drive home, though, is that the Requirements are the result of development, not the other way around. They are indeed highly important because they are the ultimate goal, but just as you don't create a new recipe by starting with an exact ingredient list, you shouldn't start a new project by starting with a list of Requirements.
Cooking & Software Design
A new recipe is a good analogy for this. Many of us are so used to cooking from recipes, that sometimes we forget what goes into creating the recipe in the first place. (In software design, we are creating the recipe, not cooking from it.) Sometimes we start from scratch, "I want to create a new chicken wing recipe," so we go buy some chicken wings and a cupboard full of spices and start experimenting. (This is akin to a client saying, “I need a shopping cart.”) Sometimes we start with someone else's recipe, "I like Joe's chicken wing sauce, but it's too sweet and not spicy enough," so we buy the ingredients for Joe's recipe and then take away some ingredients and add others. (This is akin to starting with a set of Business Rules, “I needed a checkout process that matches my company’s Shipping Department procedures.”) But in both cases that's just the starting place.
During the design process, you create multiple bowls with different combinations. You add one ingredient and taste it. You add more and taste it again. You prepare three different combinations of ingredients and call your friends over and have them try all three and give you their opinions.
Software design is the creation of the recipe. The tastings are the Prototypes. Sometimes we test the prototypes ourselves. Sometimes we get our users to give us their opinions of the prototypes. When we're done, what we've produced is the Recipe. What we've produced is the Requirements Document. Then it's the users that cook from the recipe.
What chefs don't do is just write down the ingredients they plan the use and then put those ingredients into their cookbook, so why do we? Even if they're pretty sure they know what's going to work together, a chef will still make up a batch, and inevitably, there's something to be tweaked.
Don't start your next project by trying to build a final ingredient list to hand to your developers. Instead, your developers should be generating taste tests, and your requirement writers documenting the impacts of those tests on the process. Ultimately, it will lead to the best-tasting software product you can produce! (It will also get you there faster, but that’s a topic for another article.)
Development is your core process and Requirements Documentation is your result, not the other way around.