As much as programmers hate to document their code/system and draw UML (especially, Sequencing, Activity and State machine diagrams) or other diagramming notation, would you agree to do it if it kept managers from requesting a "minor change" every couple of weeks?

IOW, would you put together visual models to document the system if it helped you demonstrate to managers what the effect of changes are and why it takes so long to implement them?

(Edited to help programmers understand what type of answer I'm looking for.)

2nd edit: Restating my question again, "Would you be willing to use some diagramming notation, against your better nature as a programmer, if it helped you manage change requests?"

This question isn't asking if there might be something wrong with the process. It's a given that there's something wrong with the process. Would you be willing to do more work to improve it?

  • 1
    The question does not make any sense since UML is not about requirements management. Oct 15, 2010 at 12:23
  • @luis.espinal, source code isn't about requirements management either. Does the question make sense now? Oct 15, 2010 at 16:08
  • @Huperniketes - Sorry, it still does not. Maybe we are a communicatio mismatch here. In the same way I wouldn't show code to users to understand the cost of requirements change, neither would I show UML. My point is that I've never seen UML being effective in keeping stakeholders from requesting changes frequently. It is not what it was intended to be. You need other artifacts outside of UML (and a process that enforces some type of requirement/cost trade-off analysis) to keep stakeholders from requesting changes frequently. Oct 15, 2010 at 18:31
  • @Huperniketes - Ok, now I see your 2nd edit. Thanks. To that answer I'd say yes. If a diagramming notation capable of conveying requirement cost were to help me control requirement changes, the answer is yes. Now, this is not about programmers not understanding your first question. It is that the 1st one is different from the 2nd one given that UML is not just a diagramming notation, but an actual modeling language with 1) semantics, and 2) no precise notion of requirement, requirement change, or req. change cost. Does my previous answer makes sense now, considering the 1st question? Oct 15, 2010 at 18:33
  • @luis.espinal, no because both questions are still the same. The question asks if you would use some diagramming notation - to model the system - if that model helps to make the effect of change requests on that model visible to stakeholders, contrary to your tendency not to otherwise document the system. It's asking if you'd change your behavior to improve the process, in other words. Oct 15, 2010 at 18:45

7 Answers 7


Your problem is a lack of communication between you and your managers/stakeholders.

They don't understand the problems that making frequent changes can cause - even if you have an agile process in place.

But equally the developers don't understand the need that the program is designed to solve or the business process as well as you should.

Why do I say this?

If the managers were familiar with the development process then they'd know when was the appropriate time to request changes - before the start of the next sprint, or when the design document for the next phase was being written etc.

If the developers understood the problem better then the product would be closer to the needs of the stakeholders.

You need to address the communication issue and put in place procedures to manage the change - because change will happen.

Hiding behind UML diagrams (or specifications, or even story cards) isn't going to solve the problem.

  • 2
    Very good point. I think that as developers, we often forget who we are working for. There are terrible users who give awful specs at the last minute, but by and large, users actually do want the programs to turn out well, or else they would not be paying for it. Communication is something we could all work on to make the process better on both sides.
    – user3792
    Oct 14, 2010 at 23:25
  • The problem is the managers often do not comprehend the size of systems without adequate diagramming, nor the extent to which changes affect the system without diagramming. It's easier for clients to comprehend the consequences of changes to plans for remodeling a house, or other building plans because those plans are represented visually, and changes to those plans and the results can be demonstrated visually. That is what is being communicated: what consequences those changes will have to the system. Oct 14, 2010 at 23:35
  • 1
    Great answer - although I'd go even further. UML, story cards and specifications are all great aids to communication. But, if you're going to go in with those tools as a way of blocking communication (in this case change requests) then it'll not only not solve the problem, but also make it worse.
    – FinnNk
    Oct 15, 2010 at 9:00
  • @Huperniketes - Office politics and resistance to change can cause some users to want a program to fail.
    – JeffO
    Oct 15, 2010 at 12:48
  • @FinnNK, story cards and specs don't provide as detailed documentation as sequence and activity diagrams on changes required to an existing system or plans. The intent should not be to block or obfuscate communication about change requests, but to make affect of CR more apparent to stakeholders. Oct 15, 2010 at 16:03

Gernerally speaking if minor changes required updates to UML diagrams then I would consider the diagrams to be too detailed. I have found the best use of UML diagrams is to succinctly convey the design of a system. It's incredibly beenficial to be able to look at a class diagram or a deployment diagram and get a feel for the software compared to trawling through code or trying to suck the information out of other distracted devs.

I think the mistake a lot of people make - including me when I first started modelling - is to think that the model has to be of 100% complete. For example class diagrams can very quickly get unwieldy if they include every single class in a big project but often there are a lot of utility classes for logging, loading configuration settings etc. that don't really add a lot to the picture and can be ommitted.

However there are also cases where more detailed UML diagrams may be useful. In particular activity or state diagrams can help clarify how a particularly tricky piece of business logic is working. In those cases it is a very good idea to change the diagram for every small change as a way of keeping track of the business process.

UML and modelling are a balancing act. If the incorporating the changes your manager is making into the diagrams make them more useful then add them. If on the other hand it takes you longer to make the changes to the models than it does to write the code then perhaps your UML is too low level.


I think the OP is confusing UML (a language for modeling) with requirements management (a process). Modeling your system in UML is not going to stop users from asking requirements. You use UML to capture your architecture and to map requirements to artifacts. A requirement change would invariable represent a change in your model.

These are systemic problems that you just don't "UML it out". There are things to consider here:

Change Scope: Too large of a change, then either the request is disruptive, or your UML does not relate to the actual system, or your system has an inflexible architecture.

Rate of Requirement Change Too frequent changes will cause you to 1) update your model and 2) deliver. So without a requirements management process, you are going to UML yourself to death, thus decreasing the rate of at which you produce results.

You could say that your productivity is inversely proportional to the rate of requirement change multiplied by a factor representing the UML "crust" artificially added to a process.

I would suggest you get a book on requirements management, and learn a bit about the way Scrum handles requirements. Say you previously had a requirement R, and the user now wants a change on R, say R'. Then you treat R' as new requirement with its new timeline. You have to communicate users that requirements changes have associated costs.

Also, it would do you well to study a bit of systems engineering and the concept of requirements as being:

  1. Atomic.
  2. Precise.
  3. Unambiguous.
  4. Testable/Verifiable.
  5. Feasible.
  6. A change request on a requirement is a defect on the requirement. Thus, it creates a new requirement, and puts the onus on the originator (typically the customer.)

There is such a thing as an invalid requirement. A requirement request that does not fill any of the above is an invalid requirement. And in a good process, the development team has the right to reject a requirement.

I mean, you ask an architect to design you a house without windows, he'll walk away. Or you ask repairman to fix your roof with clear tape, he'll give you the finger and walk away. Ask a dentist to remove a tooth from you using a pair of bolt cutters, he'll hit you with them and kick you out.

Only in software you see this notion that all requirements are valid and that they must implemented whatever the cost.

I recently put an answer to a related question, on requirements management and engineering. Maybe you might want to take a look at it. I hope you you find it helpful

How do you deal with changing requirements?

  • -1 to help you put 2 and 2 together. You got that UML is for modeling the (actual | proposed) system. You got that "Only in software you see this notion that all requirements are valid and that they must implemented whatever the cost." My point is that in processes with poor or non-existent requirements management, stakeholders have no sense of the cost of change requests because they have no sense of the implemented system. They don't see source code so they need some other artifact before they're motivated to manage requirements better. Oct 15, 2010 at 16:31
  • Thank you for the down vote. I'm not arguing that your point about poor or non-existing processes. I'm arguing against your post title. I've been using UML since 1998, on commercial, research and defense sectors with a variety of processes (agile, RUP, iterative and even waterfall.) Your question was Would you use UML if it kept stakeholders from requesting changes frequently?. And my answer is no because UML is not about processes and certainly not about requirements engineering. Every attempt I've seen of using UML to communicate requirement cost or for req. mgmt fails because of that. Oct 15, 2010 at 18:21
  • In fact, UML proper has no concept of requirements or requirements management (even though people tend to confuse use cases with requirements). There is a key distinction between a use case (which is a requirements analysis artifact) and the actual requirement (and its management.) Maybe we are talking about different things, but by following the title of your post, I put the 2+2 in my previous post. You argue that customers need to see something other than code. I argue that they need to see a requirement/cost mapping; UML does not give that since it is not a tool for cost estimation. Oct 15, 2010 at 18:25

Reasons users will accept denying a change request:

  1. It will cost more money, but they have to feel the impact (It's actually their money or comes from their budget or has to be approved).
  2. It will delay the project.
  3. They will have to give up another feature.
  4. They are required to get involved more/spend more of their time with approval, testing, writing up request etc.
  5. Someone convinced them it will do harm or make the application worse.

If they are involved in the creation, editing, review/approval of the UML, they may think twice about a request since they will have to "go through all that again." This is no different than if they have to write a formal request, update documentation/training materials, commit their time to test/review/approve, etc. These types of things are more tangible to them than code.


I think that model driven development is the real problem and certainly not UML graphical notation which is known and accepted by millions of users. UML is not requirement but could be extended using profiles and therefore if you model and have a kind of model merge for each iteration between code and model, then it would be possible to model if requirements evolve !!

I use Omondo because my project is developped in Java and must admit this tool is the only I found capable of merging code and model at any time. My requirements are sometimes changing every week, my project documentation is always up to date and my UML model accurate :-) I can also trace requirements inside the UML metamodel and query the xmi which is also my model. Just amazing technology !!


Changing requirements is something that you need to deal with in the process, and the techniques from the agile methods help with that. As far as UML, or any other diagram or document produced, is concerned, the purpose is to document the system. There's very little relationship between managing change and the system documentation, aside from the fact that having accurate and useful documentation makes it easier to understand the system, analyze the change request, and come up with estimates on the work needed to be done.

Depending on your organizational structure, the business managers probably don't care about the design or implementation details of the system (and therefore don't care about having UML or any type of design documentation). They see feature requests and defect reports and assess the value added to the system by fixing these defects or adding those features, and prioritize based on the business objectives. The technical managers might be more interested in the system architecture, design, and some implementation details in as much as it affects utilization and assignments of engineers.

Typically, there should be some kind of change control process that involves team members responsible for business/project management, technical management, and quality assurance. It doesn't matter what they use for making decisions, but the business/project manager should be prioritizing requests based on value added/marketing needs, the technical manager should be pushing back on requests that are not feasible due to engineering constraints (current design, implementation, people are already assigned to higher priority tasks, lack of resources).

In such a scenario, having a formal, consistent design notation (such as UML) would assist the technical manager (and perhaps software quality engineers) understand the system and be able to present their argument and rationale for pushing back on the changes, but they wouldn't show the UML models to non-technical stakeholders. I would recommend using UML and other standardized modeling techniques to simplify and streamline communication between technical stakeholders and within the team, but showing UML to business and non-technical stakeholders is most likely futile.

  • There are different modes of using UML (like any language). What you say is true for "Programming in UML" where the UML -> code is substantially just a mechanical process. However the other extreme of "UML as a Sketch" (UML can be used to communicate ideas and concepts but does not attempt 100% precision of the details -- and will skip most details, eg. not listing property and parameter types) does not have such a close relationship to the code.
    – Richard
    Oct 15, 2010 at 8:28

I use Topcased. It is able to generate code from UML diagrams and preserves changes you made in generated code when you generate a second time.

Not the answer you're looking for? Browse other questions tagged or ask your own question.