Business Modeling Domain Analysis

1
Business Modeling - Domain Analysis

• Most materials taken from the RUP textbook
• Chapter 8 and OOSE, pp. 101-106

2
Purpose of Business Modeling

• To understand the structure and dynamics of the
  organization in which a system is to be deployed
• To understand current problems in the target
  organization and identify areas for potential
  improvement
• To ensure customers, end users, and developers
  have a common understanding of the target
  organization
• To derive the system requirements to support the
  target organization.
• ?Note all about the organization and not the
  application (directly).

3
Business Modeling (Domain Analysis)

• ?We look at WHY we look at business modeling
  before application development.
• We will create a model of the vision of the
  target organization with its
• Processes
• Roles
• Responsibilities
• Three primary components (Much more ahead)
• Business Use Case Model, and
• Business Object Model
• Domain Model ( some exploratory domain model)
• We will discuss each in turn several slides ahead

4
Why Undertake Business Modeling(Why do we care?
Slide 1)

• The new standard for software development is to
  try to understand the business domain before or
  in parallel with development of an application.
• Applications must fit within the organization!
• Business modeling is now a recognized, central
  part of development, and, in particular,
  facilitates the development of Requirements.
• Business modeling now involves higher level
  people those who can make decisions involving
  change (not just those who know the business
  well - SMEs).
• According to the RUP, it is the first discipline
  that should be addressed and is key to acquiring
  key artifacts that will underpin much future
  work.
• It is also a fundamental discipline in Inception
  phase.

5
Why Undertake Business Modeling (Why do we care?)

• Very important to learn background knowledge so
  developers can communicate with users and make
  more intelligent decisions.
• Essential for understanding customers problems
  and setting the scope for a development project
  that might follow.
• Business Modeling (Domain Analysis) is a process
  by which a software engineer learns background
  information sufficient to be able to understand a
  problem at hand and to make good decisions during
  requirements analysis and other stages of the
  software engineering process.
• The Domain a general field of business or
  technology.

6
Why Undertake Business Modeling (Why do we care?)

• To perform business modeling (domain analysis),
  we need to gather information from a number of
  sources of information.
• Seek experts in domain knowledge
• Sources of Domain (Class) Knowledge
• high-level problem statements
• requirements
• expert knowledge of the problem space
• anything that describes the problem space and the
  desires and needs of the stakeholders.
• Quarterly reports
• Interviews
• Questionnaires

7
Business Modeling - more

• We need to often create a domain analysis
  document that contains the domain
• Name
• Glossary terms used in the domain that are not
  a part of everyday language
• General knowledge about the domain
• Who are the customers, users, stakeholders
• Environment system, equipment used
• Tasks currently performed
• Competing software.
• Dont develop too much information.
• Brief summaries of what you have found plus
  references

8
Business Modeling - more

• No serious software project should be undertaken
  without a sound domain analysis a good
  knowledge of the domain of application
  considerably increases your chances of success.
  p. 103, OOSE textbook.
• Understand the domain? Easier to press on with
  requirements analysis to solve the problem
  vision of a new/enhanced application.
• Recognize that domain analysis never ends, as
  developers continue to supplement their domain
  knowledge as time continues.

9
Categories of Business Tools e-business

• E-business reflects the nature of the business
  represents what the business is all about.
• Customer to business (C2B) applications that
  allow you to order goods over the Internet, such
  as books
• Business to business (B2B) automation of a supply
  chain across two companies
• Business to customer (B2C) provision of
  information to (otherwise passive) customers,
  such as by distributing newsletters.
• Customer to customer (C2C) applications that
  allow customers to share and exchange information
  with little input from the service provider, such
  as for auctions.

10
Terms

• Business user customers, vendors, partners
  represented by business actors
• Business processes represented by business use
  cases business use case realizations
• Roles people play represented by business
  workers
• Things organizations manage/produce represented
  by business entities / events organized into
  business systems.

11
Business Modeling Scenarios

• Scenario 1 Organization Chart
• Build a simple org chart of business and its
  processes to get a good understanding of the
  application you are building.
• Where does the application fit? To which
  organizations might it impact?
• Emphasis is on the organization.
• Part of the software engineering process and part
  of the inception phase

12
Business Modeling Scenarios

• Scenario 2 Domain Modeling
• Build a model of that information (banking,
  order management) that will be present at the
  business level.
• Domain Modeling is typically part of the software
  engineering project and is performed during
  inception and elaboration phases but is
  definitely started in inception and refined in
  elaboration.
• We will develop a domain model among other
  things in the next slide lecture plus assigned
  readings.
• Recognize that the Domain Model is part of Domain
  Analysis (that is, Business Modeling)

13
Business Modeling Scenarios

• Scenario 3 One Business Many systems.
• ? One business-modeling effort that is input to
  several other development projects.
• The business models will as serve as inputs to
  building the architecture of the application
  family.
• Individual applications may then use this model
  for individual projects, and will use this system
  as a baseline or domain, which may be then
  tailored or used in a dependency role.
• This business modeling effort is a project by
  itself!

14
Business Modeling Scenarios

• Scenario 4 Generic Business Model (for
  different organizations)
• Important if you are building a single, general
  model to be used to align several organizations
  in the business
• used to reduce overall complexity - or at least
  understand how the different organizations might
  use the application.
• Scenario 5 New Business
• Necessary business modeling for a new line of
  businesses
• Scenario 6 Revamp Business Process
  Reengineering (BPR)
• A complete redo of the way of doing business.
  Done in several discrete stages envision new
  business, reverse engineer existing business,
  forward-engineer new business, and install new
  business
• A revolutionary approach to reorganization.

15
Primary Artifacts

• Business Vision Document
• Defines objectives and goals of the business
  modeling effort
• Business Use Case Model
• A model of the businesss intended functions.
• Used as an essential input to identify roles and
  deliverables in the organization. (Use Rational
  Rose)
• Will be very useful in your development use case
  modeling
• Business Object Model (Business Analysis Model)
• A model that realizes the business use cases.
  (Use Rational Rose) A lot of work

16
Primary Artifacts (2)

• Business Rules policies/conditions that must be
  satisfied heuristics during operations
• Business Glossary definitions of important
  terms that are important to the business
  (acronyms, as ELOC, commonly used terms.)
• Others selected(several omitted are important,
  but we are concentrating on these?)

17
Business Models

• ? 1. Business Use Case Model
• Contains business actors (roles external to the
  business such as customers) and business use
  cases (business processes)
• ? 2. Business Object Model
• Includes the business use case realizations
• Includes interacting roles and entities involved.
• ? 3. Domain Model - ahead
• These are at higher levels of abstraction than
  the system use cases will be.
• e.g. A class at business level represents a
  responsibility in an organization.

18
1. Business Use Case Model

• Simple in structure . See pp 151-152 in the RUP.
• Shows relationship between business use cases
  in general and business users (business actors).
• Business Use Case Model is very similar to
  (System) Use Case Model but with different icons
  (semantics)
• Each use case is identified and actors who
  interact with this and each business use case.

19
2. Business Object Model

• Much more detailed (pg 151-152)
• Each business use case is realized with business
  actors and business entities.
• Note icons used. (All documented in Visual
  Modeling with RR 2002 and UML)
• You will not need the dashed lines, as these
  figures (pp. 151 and 152) are showing the
  relationship between the business modeling and
  the system models. (underlining implies objects)
• Notice the syntactical difference between the
  icons in the System Use Case Model (bottom of pp
  151-152) and the Business Use Case Models (middle
  of pp. 151-152).

20
More details on Business Object Model

• Business Models and Entity Classes
• A business entity that is to be managed by an
  information system will correspond to an entity
  in the domain model.
• More ahead on domain modeling
• Example entities might include
• Menu
• Work Schedule
• Food Order

21
The Domain Model

• Part of Domain Analysis is developing models
  Visual Models!
• We develop a
• Business Use Case Model
• Business Object Model, and a
• Domain Model.
• All three of these will greatly assist in
  effective requirements analysis (gathering,
  capturing, and modeling user requirements).
• Lets look at the Domain Model.