Would you use UML if it kept stakeholders from requesting changes frequently? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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 !!

Answer 6

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.

Answer 7

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.