“Big modeling up front” (BMUF) is the desire to create comprehensive models of the requirements for a system, the analysis of those requirements, an architecture that fulfills those requirements, and eventually a detailed design.  Traditionally each model is reviewed, fixed, and eventually signed-off on, although the important aspect of BMUF is the serial nature and not the validation aspects.  Sometimes you will see these models created in parallel in an attempt to reduce the calendar time of your modeling efforts.

Synonyms

• Big design up front (BDUF). BDUF is commonly used to refer to this approach in the XP community.
• Big requirements up front (BRUF).  BRUF and BDUF typically go hand-in-hand.

Motivation

BMUF is a popular approach because people:

1. Mistakenly compare software development to civil engineering. A common analogy is to compare software models to architectural diagrams for a bridge or building.  Unfortunately the analogy isn’t an accurate one: software is more malleable than concrete making it easier and much less expensive to change your mind part way through the effort; The material (app servers, operating systems, …) used to build software isn’t as well understood as the material to build bridges (steel, concrete, …) making it much more difficult to accurately plan up front; Incremental delivery often doesn’t make much sense when you’re building a bridge, so what if the foundation has been set but the rest of the bridge isn’t in place, although incremental delivery of software is clearly possible and as I argue above the norm.  Much better analogies are comparing software developers with chefs or comparing software development with putting on a play (as described in the wonderful book Artful Making).
2. Think comprehensive requirements documentation means something.  There is a common misconception among project stakeholders that you can fully specify a system before constructing it.  Yes, you can in fact do so, but as you see in Examining the "Big Requirements Up Front (BRUF)" Approach this leads to incredible amounts of wastage even if you end up "successfully" delivering software.  In other instances, development teams often misunderstand, or outright ignore, parts or all of the requirements specification anyway.
3. Don't know any better.  Many organizations have spent the last thirty years putting a well-defined, non-agile, and very serial process in place that encourages BMUF.  The U.S. Federal Government is a classic example of such an organization, often requiring extensive requirements documents to be created before allowing any other form of development to occur.  Yet, as this site shows, you do in fact have other options.
4. Are overly specialized.  When you staff your project with specialists, they'll perform their specialist tasks very well whether it's appropriate or not.  When you have modeling specialists on the project they'll do a lot of modeling, and likely write a lot of documentation, because that's what they're good at.  The end result is that you'll get far more documentation than you actually need -- you pay for it, you get it.  What you really want are generalizing specialists who have the skills and abilities to do just enough modeling, coding, and so on.
5. Believe programmers don't have the skills to model themselves.  This is a self-fulfilling prophecy.  If you hire overly specialized people, then set up an environment where one group of specialists hands off work products (e.g models) to other groups of specialists, then you pretty much guarantee that they won't learn a wider range of skills.
6. They got sidetracked by traditional data professionals.  Unfortunately many within the data community believe that you require a serial approach to design, particularly when it comes to databases.  This belief is the result of either not understanding evolutionary development or some misguided need to identify the "one truth above all else".  Evolutionary database design techniques such as agile data modeling, database refactoring, and database regression testing work incredibly well in practice.   

Impact

The problem is that change happens. Yes, it is clearly possible to create comprehensive requirements documents before allowing construction to begin, and you can clearly build a system that fulfills those requirements, but is it what you really want?  As I discuss in Agile Requirements Modeling project stakeholders’ understanding of the system and their environment changes, their priorities change, the environment in which they do business changes, all motivating changes to requirements.  A BMUF approach may ensure that you get the system that you ask for but it virtually guarantees that you won’t get what you actually need. 

Furthermore, by doing too much modeling up front, then handing it off to the coders, you pretty much remove all of the joy out of development for them. Is it any wonder that developers often choose to ignore the models they're provided, or to "improve upon" the ideas contained in them?  If you treat programmers like this, you're effectively telling them that they are low-skilled an unimportant.  The end result is that your good developers will leave your organization, and that a significant percentage of your remaining developers will in fact be the low-skilled people that you're apparently striving to attract.  Doesn't sound like a great strategy to me.

The Solution

You still need to do some initial envisioning up front, including both requirements envisioning and architectural envisioning.  You're still doing some initial up front modeling, it's just that you are doing so in an effective and agile manner.  You should create very slim, high-level models early in the project which overview the scope of the effort and identify a likely architectural strategy.  Then model storm just in time to get the details when you need them.  With this approach you retain the advantages of modeling, to think something through, without suffering from inflexibility or over-documentation.

Acknowledgements

I'd like to thank Huet Landry for his feedback concerning this article.

Recommended Resources

• Agile Analysis
• Agile Architectural Modeling
• Agile/Evolutionary Data Modeling
• Agile Model Driven Development (AMDD)
• Agile Requirements Best Practices
• Agile Requirements Change Management
• Comparing the Various Approaches to Modeling in Software Development
• Development Phases Examined: Why Requirements, Analysis and Design No Longer Make Sense
• Database Regression Testing
• Examining the "Big Requirements Up Front (BRUF)" Approach
• Enterprise Modeling Anti-Patterns
• Initial High-Level Architectural Envisioning
• Initial High-Level Requirements Envisioning
• The "One Truth Above All Else" Anti-Pattern
• The Process of Database Refactoring
• The Risks With Traditional Approaches to Modeling

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Acknowledgements

I'd like to thank Dan Hoover for his feedback which I incorporated into this article.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.