For years I have discussed the idea that modeling doesn't occur in nice, neat phases.  Instead of spending time in the "Requirements Phase", then the "Analysis Phase", then the "Design Phase" it is far more common to iterate back and forth between these so-called modeling activities.  When you think about it, these different phases are more a reflection of the Tayloristic thinking of the early 1900s than it is of effective software development.

1. Rethinking the Concept of Modeling Phases

Many people, particularly generalizing specialists with a wide understanding of development will hear a requirement, ask a few questions to analyze what is actually needed, and then proceed to designing it in their heads.  This typically occurs within a matter of minutes if not seconds.  Clearly the concept of modeling phases is questionable, but I'm also beginning to wonder if the idea of focusing on requirements, analysis, and even design makes much sense these days.  Perhaps we should just talk about modeling in general, or perhaps we should focus on other types of modeling instead.

Assume that we decide to focus on modeling, or better yet agile modeling, in general.  I think that it is still valuable to consider requirements, which to me should identify what our stakeholders want; analysis, which investigates the details pertaining to the requirements; and design, which focuses on identifying how we intend to fulfill those requirements.  Very useful concepts, but not very useful phases.

Now let's take a different tack and try to identify what concepts should replace the activities of requirements, analysis, and design.  One way that we could do this is to take a bottom up approach by considering potential modeling artifacts and identifying categories which they belong to.  Or we could take a top-down approach and consider existing categories of modeling prevalent within software development.  Or we could combine the two approaches, which is what I've done, to identify the following categories of modeling activities:

1. Usage modeling.  The focus of usage modeling is to identify how people work with your system.  Potential artifacts include essential use cases, system use cases, UML 2 use case diagrams and user stories.  Usage modeling crosses the boundary of traditional requirements and analysis, and arguably even design, because when you model usage you explore what users will do with the system as well as how the system will support that usage (e.g. by considering user interface and deployment decisions). Personas and scenarios should also be considered.
2. Process modeling. The goal of process modeling is very similar to usage modeling in that it is to explore how people work with the system, taking into account the flow of the activities being performed. The main difference is that usage modeling techniques don't fully address the flow of artifacts, including but not limited to information, within a system whereas process models do.  Potential process models include data flow diagrams (DFDs), flow charts, and UML 2 activity diagrams.
3. User interface (UI) modeling.  UI modeling can include UI requirement identification via essential UI prototypes, traditional prototyping, and/or user interface flow modeling (storyboarding).  Usability issues are clearly an important concern when developing the UI.
4. Supplementary requirements modeling.  There is more to identifying what stakeholders need than usage or UI modeling, hence the need for supplementary artifacts which address these critical details.  For example many systems have complex business rules, constraints, glossaries, or technical requirements and sometimes a requirement is best identified via a simple feature definition.
5. Conceptual domain modeling.  The goal of conceptual domain modeling, sometimes simply called either conceptual modeling or domain modeling, is to identify the entities, their responsibilities, and their relationships within your problem domain.  Potential models which you may want to consider include class responsibility collaborator (CRC) models, logical data models (LDMs), object role model (ORM) diagrams, robustness diagrams, or UML 2 class models.
6. Architectural modeling.  Architectural modeling should focus on the high-level design of a system or that of an enterprise as the case may be. Although virtually any model can be used for architectural modeling, I prefer models which can be used to explore the general landscape of your efforts.  This includes free-form diagrams, UML 2 component diagrams, UML 2 package diagrams, UML 2 deployment diagrams, and network diagrams.  A supporting model are change cases, a form of architectural requirement which enables you to explore potential requirements.
7. Dynamic design modeling.  The goal of dynamic design modeling is to explore the behavioral aspects of an object system.  UML interaction diagrams -- including UML 2 communication/collaboration diagrams, UML 2 composite structure diagrams, UML 2 interaction overview diagrams, and UML 2 sequence diagrams -- can be used as can UML 2 state machine diagrams and UML 2 timing diagrams.
8. Structural design modeling. Structural design modeling, using UML 2 class diagrams, UML 2 object diagrams, and/or physical data models (PDMs).

My experience is that it is better to consider modeling categories instead of modeling phases/disciplines. Figure 1 depicts this idea, showing the eight different modeling categories described above and listing potential models within each category.  

Figure 1. Iterative modeling.

It's interesting to observe that this is very similar conceptually to Phillipe Kruchten's 4+1 View of Modeling, albeit one with eight views instead of five.  These categories are also similar to the six columns of the Zachman Framework (ZF), arguably a different take on the same basic idea.  Although I would like to say that you should simply pick one model per category it's not that simple.  Here's my advice:

1. You need one or more models from the usage and process modeling categories.  This choice will often be driven by your chosen software process, following either the Rational Unified Process (RUP) or Enterprise Unified Process (EUP) you will need use case artifacts, with Extreme Programming (XP) user stories, and with a structured analysis and design approach data flow diagrams (DFDs).  It is also quite common to use process models to analyze the information contained in usage models.
2. Create user interface models as needed.  Some systems are UI intense whereas others are not, some developers prefer to start with essential models whereas others prefer to go straight to prototyping or even development of the actual source code itself.  As always, Apply The Right Artifact(s).
3. Model supplementary requirements as appropriate.  I'm a firm believer in using each type of model for what it's good at and for recording information in one place only.  Supplemental requirements such as business rules and technical requirements can and should be referred to within other development artifacts such as use cases, class models, and source code.
4. Create one type of conceptual domain model.  You need to understand the business domain, and conceptual domain models are very good at that. Pick one model that best meets your needs.
5. Create architectural, dynamic design, and structural design models as needed.  You often need several views of your architecture, so create the model(s) that reflect your situation. Similarly you are likely to discover that you need one or more dynamic design models from time to time, sequence diagrams are a popular choice as are state machine diagrams.  Structural design diagrams are often the mainstay of modeling as they are very close to object code as well as data schemas.

2. Towards Inclusive Modeling

So how do these categories change the development landscape?  First, I believe that they make the complexity of modern software development more explicit.  These categories focus on the high-level issues that you should consider modeling, instead of modeling phases, and as a result provide better guidance to developers.  Second, they provide insight into the types of models that you should create. Figure 2 maps the modeling categories to individual modeling techniques, indicating which techniques are inclusive and which are complex.  Inclusive techniques use simple tools (paper, whiteboards,...) and are simple in and of themselves (and are therefore easy to learn).  I call these techniques inclusive because they are simple enough that stakeholders can use them, thus enabling the practice Active Stakeholder Participation.

Figure 2. Inclusive to complex techniques.

3. The Modeling Lifecycle

Figure 3 depicts the lifecycle of Agile Model Driven Development (AMDD), which is much different from the waterfall lifecycle of yesteryear.  High level modeling, also called envisioning, is first done during "Iteration 0" and the details are gathered on a just-in-time (JIT) basis during development iterations.  The goal of initial requirements envisioning and initial architecture envisioning is to understand at a high level what the scope and technical strategy of your project is.  The other activities – iteration modeling, model storming, reviews, and implementation via TDD – potentially occur during any iteration, including iteration 0.  It is during these activities that detailed modeling occurs, not during phases.  Requirements analysis, architecture, and design are so important to agilists that we do these things every day, not just during specific phases.

Figure 3. The Agile Model Driven Development (AMDD) lifecycle for software projects.

4. Adopting this Approach

It's fair to ask what impediments exist to implementing this vision.  The first impediment is the prevailing culture within the IT industry.  For years we've been told that the modeling phases reflect how development occurs but it never really seemed to ring true with many developers, people who often threw out the "modeling baby" with the "phases bath water" when they abandoned the idea of serial development.  The second impediment is existing IT specialists.  There are many people who identify themselves as requirements analysts, architects, object designers, or database designers, all jobs which reflect "phasist thinking".  It would be far more effective if people could identify themselves as the more general concept of modelers or better yet simply as developers who happen to have solid modeling skills. 

In short, I'm simply not convinced that the modeling phases of requirements, analysis, and design make sense any more.  Nor, in the case of the various flavors of the Unified Process, do they make sense as disciplines.  We need to rethink our approach to modeling within the IT industry, and my experience is that the categories which I have described above are far more realistic of an approach.  Think about it.

Source

Parts of this article have been excerpted from The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2.

Recommended Resources

		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.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.