CASoft BlogWhen describing requirements using UML, any attempt to order use cases or provide sequence information amongst use cases is bad practice, and can only lead to misuse of the UML use case diagrams.
One need to describe the Business Processes for the system under study, as this will provide the order in which things shall happen in much details.
Business Process can be documented in the Overview/Context section of a Product Requirements document.
OMG defines a BPMN notation to describe Business Processes (see http://www.bpmn.org/), which is basically based on a UML 2.0 activity diagram with a number of additional icons / features. This notation however doesn’t add much other than confusion for the non-expert. I am indeed very much in favour of self-explanatory / unambiguous diagrams, as in my experience UML diagrams must be reviewed and approved by subject-matter-experts who usually are not UML experts. So, unless you have a very good reason for using BPMN, just use activity diagrams to describe Business Processes.
BPMN, while based on UML 2.0, is still in need for a consolidation with UML notations.
Otherwise, it is important not to undertake UML without a methodology. In order to be highly successful in documenting a system of any complexity, it is important to follow a formal methodology.
I personally like to use a methodology based on RUP, especially for the documentation of the requirements and the architecture, while agile approach principals can be used for the design and the development…
