Business Modeling - Domain Analysis

1. Business Modeling - Domain Analysis Most materials taken from the RUP textbook Chapter 8 and OOSE, pp. 101-106 23

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 customer’s 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…. • Don’t 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, generalmodel 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 business’s 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. PrimaryArtifacts (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). • Let’s look at the Domain Model.