Managing Software Requirements by Dean Leffingwell, Don Widrig

Presented by: Ali Farzan Tahaa Samra Mubeen Waiza Munir

BSEF09M016 BSEF09M050 BSEF09M021

Introduction
we can think of the terms business

and business modeling in the broadest possible context. For example, your business may be the business of developing software or manufacturing welding robots, or you may wish to model a not-for-profit business or service organization or an intradepartmental process or internal workflow.

Contd
A business model can be seen as a general description of how

an organization handles its major activities.

The two most basic components of a business model are:
o The identification of potential customers o The identification of products or services the organization

offers

Purpose of Business Modeling

To understand the structure and dynamics of the

existing organization
To ensure that customers, end users, and developers

have a common understanding of the organization

To understand how to deploy new systems to facilitate

productivity and which existing systems may be affected by that new system
4

Business Modeling
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 o Processes o Roles o Responsibilities Three primary components: o Business Use Case Model o Business Object Model o Domain Model

Why Undertake Business Modeling (Why do we care?)

Understand the business domain Facilitates the development of Requirements. Involves higher level people Help to make good decision Proved help to Software engineer

Sources of Knowledge to perform Business Modeling

To

perform business modeling, we need to gather information from a number of sources of information.

Seek experts in domain knowledge Sources of Domain Knowledge:

o o o o

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. o Quarterly reports o Interviews o Questionnaires etc
7

Business Modeling - more

We need to often create a domain analysis document that

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

Contd
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.
Understand

the domain? Easier to press on with requirements analysis to solve the problem vision of a new/enhanced application. continue to supplement their domain knowledge as time continues.

Recognize that domain analysis never ends, as developers

Using Software Engineering Techniques for Business Modeling

Of course, a variety of techniques can be applied to business

modeling. However, it's convenient that, as software developers, we have at our disposal a rich set of tools and techniques we already use to model our software.
With the right choice of business modeling technique, some of

the work products, such as use cases and object models, will be useful in the solution activity.

10

Choosing the Right Technique

Historically, we have seen that modeling techniques

that were developed and matured in the software domain inspire new ways of visualizing an organization. Since object-oriented visual modeling techniques have become common for new software projects. This methodology has been well developed by Jacobson, Ericsson and Jacobson [1995] and others.

11

Contd
The 1980s and 1990s saw a rapid proliferation of both
business modeling techniques and software development methodologies. However, they were all different! At the center of this activity were the various object-oriented (OO) methods and notations developed by various software engineering experts and methodologists.

12

Contd
Fortunately, these methodology "wars" are over, and the
industry has settled on an industry standard the Unified Modeling Language (UML), for modeling software-intensive systems.

13

14

The Unified Modeling Language

In late 1997 UML was adopted as an industry standard by

Booch, Jacobson, and Rumbaugh.

The UML provides a set of Modeling elements Notations Relationships

Rules

This set could be applied to a software development activity.

15

The Unified Modeling Language(Cont)

Graphical language Visualize Specifying construction Documenting artifacts UML can also be used to model other domains System Modeling Business Modeling

16

Business Modeling Using UML Concepts

Goal of the business model is to develop a model of the business that can be used to derive application development. Two key modeling constructs of business modeling are 1. Business use-case model 2. Business object model

17

Business use-case model

Business use-case model is a model of the functions of the business.

It is used to identify
1. Roles 2. Deliverables in the organization

Components 1. Actor 2. Use-case

18

1. Actor
An actor specifies a role played by a person or thing when interacting with the system. 1. Examples: Customer Employee Software Developer

19

2. Use-case
A use case represents the sequences of events through which the actors interact with the business elements to get their jobs done. A use case represents the process.
Representation:

The oval icon is used to represent the business use case. It has a slash indicating the business uses-case rather than a system level use-case.
20

Use-case(Cont)

Examples:
Deliver electronic pay stub to employee. Meet with customer to negotiate contract terms.
21

22

Business Object model

The business object model describes

1. The entities 2. How they interact to deliver the functionality necessary to realize the business use-case? Components 1. The Worker 2. The Entity

23

1. The Workers
Circle icon represents a worker who appear within the business process, such as
1. Payroll clerk 2. System administrator

24

2. The Entities
The slashed circle without an actor represents the business entity or something that a business workers produce. i.e. 1. Paycheck 2. Ball bearing 3. Source file

25

Registrar
(from Use Case View)

Student

Bill

SemesterCourseOfferings

StudentSchedule

Section

Professor
(from University Artifacts)

BillSystem Roster

26

Business use-case realizations

The business object model also include business usecase realizations

These realizations show how the business use cases are performed in terms of interacting business workers and business entities.

27

Advantages of Business Modeling

It gives comprehensive overview of how the business works. Allow the development team to focus on the areas in which systems can provided that will improve the overall efficiency of the business. It also help the team to understand what changes will have to take place within the business processes themselves in order for the new system to be effectively implemented.
28

System modeling is the interdisciplinary study of the use of models to conceptualize and construct systems in business.

29

System Modeling(Cont)
A system model is the conceptual model that describes and represents a system. A system comprises multiple views such as
o o o o o o o o o

Planning requirement (analysis) design Implementation deployment structure behavior input data output data

System model describes and represents all these multiple views.

30

System Modeling(Cont)
Approaches o

Non-architectural approach o Architectural approach

31

System Modeling(Cont)
Goals
o System modeling helps the analyst to

understand the functionality of the system, and models are used to communicate with customers. Blueprint to a kitchen or 3D model to see where every element of the kitchen exists and how it relates to others
32

 Different perspectives
o External perspective showing the systems context or

environment o Behavioral perspective showing the behavior of the system o Structural perspective showing the system or data architecture

33

From Business model to System model

34

Where do the system actors come from?

System actors are created based on the business

actors and business workers in the business analysis model.

o Business actors that interact with business worker

automation candidates always become system actors. o Business workers that interact with business worker automation candidates that are not automation candidates become system actors.
35

Where do the system use cases come from?

o System use cases are created based on the

business responsibilities of business worker automation candidates in the business analysis model.

36

Translation Between Business and System Modeling

o Business workers will become actors on the system we

are developing .
o Behaviors described for business workers are things that

can be automated so they help us find system use cases and define needed functionality.
o Business entities are things we may want the system to

help us maintain. So ,they help us find entity classes in the analysis model of the system.
37

How is the business use-case model different from the system use-case model?
There are three important differences.
1. Design scope o Business use cases focus on business operations. They

represent specific workflows in the business that achieve business goals.

o System use cases focus on the software system to be

designed. How do actors interact with the software system?

38

(Cont)
o

White-box versus black-box

o Business use cases are often written in a white-box

form. They describe the interactions between people and departments in the organization being modeled.
o System use cases are almost always written in a

black-box form. They describe how actors external to the software system interact with the system being designed.
39

(Cont)
3. Business workers
o In a system model, we have actors interacting with

use cases. o In business model, we have both business actors and business workers interacting with business use cases.

40

Similarities between system model and business model

o Both have actors. o Both have use cases. o Both have a communicates-association between actors and use

cases. o Business use cases, as well as system use cases, can have include, extend, and generalization associations.

41

When to use Business Modeling?

Business models adds the most value when application

environment is complex and multidimensional ,and when many people are directly involved in using the system. e.g. if you were adding an additional feature to an existing telecommunication switch ,you might not consider business modeling.

42

REFERENCES
http://en.wikipedia.org/wiki/Business_model http://www.acteam.com/index.php?option=com_content&view= article&id=98:what-is-the-purpose-of-a-business-model-&c atid=34:business-model&Itemid=29 http://www.ibm.com/developerworks/rational/library/360.h

http://www.ibm.com/developerworks/rational/library/apr07
http://www.sparxsystems.com/business_process_model.html http://www.slideshare.net/koolkampus/system-models-in-so http://en.wikipedia.org/wiki/Software_engineering

BOOK: Managing Software Requirements by Dean Leffingwell, Don Widrig Ch#6

43

Any Question???

44