Business analysis (or software requirements engineering) should go through two phases. First, business requirements are determined in an implementation agnostic way. Business process modeling, business semantic modeling, business use case identification, use case scenario writing we have discussed so far can all be done at the conceptual level without concerning how they will be technically implemented. These artifacts, however, need to be transformed and elaborated into detailed specifications for implementation--such as executable-level process models, specification-level class diagrams (a.k.a., domain model), logical database design, system use cases, system-level use case scenarios, UI wireframes, and system-level sequence diagrams, etc.--given a choice of technologies such as programming languages, application frameworks, runtime platforms, DBMSs, infrastructure, etc.
Class Responsibility Assignment: Recall that a business architecture led to process models, which led to use cases and scenarios. Allocating use case scenario steps, i.e., operations, to classes (called use case realization or class responsibility assignment) can be aided by several methods, such as the affinity matrix analysis discussed above, CRC (Class-Responsibility-Collaboration) cards, and UML interaction diagrams including sequence diagram and communication diagram.
Object Design: Once classes get allocated operations, it is said to be at the specification level, while it was at the conceptual level when it had only attributes specified as in Figure 6. The specification-level classes can now be implemented as object-oriented code. Specification-level class diagrams and interaction diagrams together describe a domain model as defined in the Domain-Driven Design (DDD).
Conceptual-level class diagrams contain mostly entity classes that are made persistent in a database. Object design patterns (E. Gamma, et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1994; Martin Fowler, Patterns of Enterprise Application Architecture, 2002; Eric Evans, Domain Driven Design, 2003) can be applied to improve comprehensibility and reusability of class design and resultant object-oriented code. Applying object design patterns will add various types of design-level classes such as factory class, command class, mediator class, observable class, strategy class, adaptor class, proxy class, just to name a few. Figure 11 shows the domain model after assigning operations to classes to realize the Make a Course Schedule use case.