Patterns Mining - Domain Analysis Workshop

(Where Art and Science Meet?)

Submission: Need to Fine Tune a Domain Analysis Phase to the Project / Environment

Bindu Rama Rao
Stanford & Bennett, L.L.P.
brr@ccsi.com
(512)-708-0110
 

While the need to incorporate Domain Analysis into the Software Development Life Cycle is well appreciated by the software development community, the ability to effectively execute the Domain Analysis activities during a Domain Analysis Phase is often found lacking.  The author maintains that this is due to one of the following three factors:

1. Inability to articulate and properly specify the deliverables from the Domain Analysis (DA) activities.
2. Inability to adopt any standard (as expressed by a "methodologists") approach to DA.
3. Inability to incorporate all the available (various) "inputs" into the DA activities.

To be successful in DA, it is important to first identify if the project belongs to any of the following "frequently encountered" categories:  

1. A research type
   
2. A well defined application type with "real end-users"
   
3. A not-so-well-defined application type with "funders" but few "potential customers"

Each of the enumerated types of projects has a different set of inputs and sources of "requirements".  For example, a research type project will have no "real customers" and will not be a well-defined application either.  The requirements are sketchy at best.  A well-defined application with real end-users will typically provide a rich set of requirements in some shape or form, preferably in the form of Use-Cases or Scenarios. A not-so-well-defined application type is a real problem, with not enough requirements, but with a paying customer or funder pushing the development team to deliver some "nebulous" application or product.

Needless to say, the requirements gathering activities and the domain analysis activities for these three categories of applications should be different.  Standard methodologies are "one-size-fits-all", and do not addressed the "real needs" of these various development environments.

Therefore, any object guru or process person in charge of "specifying a process" for a software development team must necessarily customize standard approaches to suit the needs of the team and the project.

Research Type Projects:

In research type projects, the goal is firstly to identify the scope of the problem and secondly, develop a possible solution for it.  Since the problem domain is often not properly understood, it is often not properly articulated either.  The requirements for research type projects are sketchy and ill defined, and are likely to change several times during the first few iterations of the project.  Requirements are often made up from the point of view of a "hypothetical" end-user who might be able to use the product.

Domain Analysis in such environments proceeds in fits and starts due to the constant discovery process and the lack of a properly articulated scope for  the project.  Moreover, prototypes are often resorted to in order to simulate the actual functionality to be incorporated. OO processes that can be applied to facilitate the domain analysis must incorporate the extraction of a domain object model from one or more prototypes.

Analysts/architects/designers often have to "cook up" requirements on an ad hoc basis to be able to identify the scope of the domain analysis activities.  Due to the lack of availability of customer or end-user representatives, it is often not possible to verify if the scope is adequate.

A well defined application type with "real end-users"

This is perhaps the easier of the three categories of projects, given the availability of requirements from real-end-users.  A requirement analysis phase with deliverables that include Use-case Models or Scenario descriptions can provide the required inputs to the domain analysis activities.  The Use-Case models may be accompanied by the specification of various constraints and assumptions.

The Domain Analysis process may involve a 3-step approach, where the Use-case Model is analyzed for "obvious" objects in the first step, the domain object model is created in the second step, and the use-cases are visited again in the third step to ensure consumability of the domain object model.  More specifically, the obvious objects identified in the first step are analyzed further in the second step along with incorporation of domain specific "extrapolations" to yield a robust object model.  The object model thus identified is subjected to a test of usability or consumability with reference to the use-case model.

A not-so-well-defined application type with "funders" but few "potential customers"

Inadequate requirements are typically the problem in such environments.  Prototypes may be constructed to compensate for the lack of proper specifications and end-user input.  The customer's input will have to be relied upon to provide information on the scope of the domain analysis activities.

The working prototypes are often used to generate "hypothetical" Use-Case models or end-user scenarios.  Such use-cases can be approved by the "customer" or funding agency.  The first few iterations of such products are typically not meant for general deployment.  Only the nth iteration may be widely distributed. Analysts/architects/designers are often forced to "cook up" requirements on an ad hoc basis for features that are not properly specified by a customer.

Conclusions:

While all OO methods highlight the need for Domain Analysis activities in the software development life-cycle, not enough attention is focussed on the availability of the various sources of requirements.  Lack of access to end-users can be a serious handicap to individuals incharge of identifying requirements, and forces analysts/architects/designers to "cook up" requirements on an ad hoc basis.  One major problem with most projects is the inadequate specification of the scope of the domain analysis activities before embarking upon the phase.  This problem is compounded in research type projects where the "goals" are not known or articulated in the early iterations.

Any domain analysis process must identify which one of these three categories a project corresponds to, and appropriately compensate for the shortcomings. Identifying the category makes it possible to tailor the domain analysis activities to the project and the environment.