1 / 21

Business Modeling - Domain Analysis

Business Modeling - Domain Analysis. Most materials taken from the RUP textbook Chapter 8 and OOSE, pp. 101-106. Purpose of Business Modeling. To understand the structure and dynamics of the organization in which a system is to be deployed

parry
Download Presentation

Business Modeling - Domain Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related