As explained in the Rational Unified Process® and as it is confirmed as soon as you start using the use case technique, there exist several relationships between the business modelling and the requirements management disciplines.

The following figure depicts what are these various relationships between _on one side_ the UML concepts used when modelling a business and _on the other side_ those used when managing and analysing requirements.

• Business Worker is a classification of a certain type of collaborator part of a company having responsibilities which are subject for automation. For this reason, we may say that Business Workers are candidate Actors of an IT system.
• When a Business Workers represents an IT system, it is then recommended to qualify it as Automated Business Worker. Through the modelling of operations performed by a particular Business Worker, we can easily summarize visually what are the responsibilities of this Business Worker. In the context of an IT initiative having as purpose to increase the level of automation, the responsibilities of Human Business Workers are fully/partially assigned to Automated Business Workers to express their automation. As such, another rule can be state: the responsibilities of Automated Business Workers are candidate use cases for an IT system.
• Business Use Cases express what (business) services are (or will be) proposed by a company to its customers and to any other partnering company. When these services are partially or totally supported by IT system(s) then another rule can be stated: the Business Use Cases are candidate Use Cases for IT systems.
• Business Rules allows to model at operational level the governing decisions regarding a company and the legislative constraints the company has to comply with. Simply think of the rules related to the protection of private information, the management of risks, the acceptation of goods, tax calculations… Since rules that are applicable to a manual procedure are also valid when the procedure is automated, another rule is: the Use Cases are contexts for the application of Business Rules.
• When modelling a business, the (business) information is modelled using Business Entities. Some of these Business Entities are going through a certain lifecycle. For example, how much time a proposal is valid and when can such a proposal be deleted? Another rule is: the State Machines allows visualizing the lifecycle of Business Entities.
• And since the life cycle of a Business Entity is most often subject to several Business Rules, another rule to remember is: the when used either during Business Modelling either during System Modelling, State Machines have to be associated to Business Rules.
• One visible aspect of a good IT system is that the business jargon is used during development. As additional rule, we can state that the Business Entities are candidate Analysis Classes of IT Systems.
• Business Rules always impose constraints. Even a formula that should be used when performing particular calculation is a constraint. More precisely, in this example, the formula impose a constraint on the calculation results clarifying what is possible as result and what is not. Constraints can be expressed and documented as relationships between Classes and/or cardinalities. As last rule, we can state that Business Rules are candidates for Associations between Classes and for Cardinalities.

If you wish to acquire a deeper insight in the relationships that exist between business modelling and other software engineering disciplines, do not hesitate to consult our training offerings and especially the Business Modelling with the Unified Process training