Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I'm learning the Rational Unified Process (RUP) in a software engineering class. I cannot figure out the difference between business modeling and requirement.
In the business modeling step, we need to define the business unit, find business actors, and draw business use cases. In the requirement step, we need to define the system, find actors and draw use cases. What's the difference between those two steps?
The RUP puts "Business Modeling" as a step before "Requirements Modeling". This means, during business modeling, one describes business processes in their current state, often mostly technology agnostic.
For example, when I run a company for selling new houses, there might be a business process of showing prospective buyers images of comparable houses or images of their living rooms. A business process model will capture this process, but usually not tell you if the images are in some paper catalogue, or created in a computer interactively.
When it comes to requirements, however, one moves a step towards developing of business software or IT systems - here we collect the use cases which shall be supported, improved or changed by such a software or system, together with textual descriptions of what the - yet to be developed - system shall provide or do. This is usually a step less abstract than the business modeling step, but still not as low-level as the next RUP step "Analysis & Design".
In the former example, the (high-level) requirements may describe a computer system where 3D models of a house and its rooms are created interactively by the sales person together with some customer, which can be shown, for example, on a standard PC monitor, or maybe with a VR headset. This is the same process as before, but on a more detailed level of abstraction and focussing on the system to be developed.
Hence, it is not surprising that in both stages you find the same terms like "use case" or "actor", or that you can utilize tools like process diagrams or use case diagrams for both. It is not the form which makes a difference, but the content.
RUP defines Business Modeling and Requirements as two disciplines / activities that occur throughout the projet in a concurrent manner, and not as sequential steps (the popular wikipedia drawing is part of this misunderstanding).
Business modeling focuses on the organisation of the company, and requirements is about the needs that the software must address to support that organisation. Both activities are influencing each-other.
Business modeling is about understanding how the business SHOULD operate. So it is about the future way a company will be organised and work. Maybe the company should stay exactly as today and this modeling would just takes stock of the existing situation. But often it's also about business process reengineering. In this case, the new software and its requirements will be critical enablers.
Requirements is about understanding what a software system shall do and user expectations. So it's about the software to be delivered in the context of the target business model.
The two activities are intertwinded: The core of business modeling is business process modeling (I leave aside the economic and financial modelling that will predict the feasibility of the new processes). Each process step in a business process model may lead to a use case in the requirement elaboration (but not necessarily). Conversely, looking closer at some requirements may challenge the business model or enrich it with new insights.
Want to know more ? Have a look at Ivar Jacobson's book "The object advantage: business process reengineering with object technology" (He's the lead co-inventor of RUP and co-inventor of UML) or at Kroll & Krutchen's book "The rational unified process made easy" (p.289-310 they show how business modeling and requirements are intertwined, with some practical examples).
