Hey, I’ve had a busy week, playing with my XBox 360 that my wife got me for my birthday revising the BABOK. So here’s some material I’ve been working on. I posted a version of this before. Here’s a refinement:
Business Domain Model
A Business Domain Model describes all or part of an enterprise.
User Classes, Profiles, or Roles. This is how we understand we describe the people who directly interact with our solution. Each role groups together people with similar needs, expectations, and goals. Those goals, needs, etc. are the source of requirements, and they need to be met somehow by our solution.
Entities and Relationships. These are the things we need to know about. They usually correspond to something in the real world; a place, a person, a thing, an organization. We need to know what objects, entities or facts are relevant to our business domain and how they connect to other things. Data models expand on this to also capture what information we know about things.
Events. When somebody asks our system or organization to do something: process an order, generate a monthly report, or anything else, it’s an event. Events are things we need to respond to in some way.
Processes. Processes can be simple (involving one person and a system) or complex (involving many people, departments, organizations and systems), but they tell us who and what has to be involved in fully responding to an event, or how people in the enterprise collaborate to achieve a goal.
Rules. Rules are how we enforce our goals and how we make decisions. They can tell us when we can change information associated with an entity, what values of information are valid, how we make decisions in a process, and what our priorities are.
These aspects of a business domain model do not have any inherent hierarchy–effective analysis can potentially start with any aspect of the model and reach out to encompass the others. For example, use case analysis can start with goals or events and capture process and rules. BPM starts by identifying processes and then derives roles, events and rules.
Software Specification
When speaking strictly about software requirements, as opposed to the more general class of requirements that apply throughout the problem domain.
Software specifications typically include a subset of the business domain model, reflecting the aspects of the business domain that must be managed within the application or which will affect the design of the application. In addition, a software specification must capture the behavior of the system under design, usually by including a user interface specification, or other description of how users of the application will interact with it and nonfunctional requirements.
Kevin Brennan, CBAP
VP, Body of Knowledge
Related posts:
Recent Comments