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 Develo= pment 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:
 

To be successful in DA, it is important to first identify if the proje= ct belongs to any of the following =93frequently encountered=94 categories:
 

Each of the enumerated types of projects has a different set of inputs and sources of =93requirements=94.  For example, a research type pro= ject will have no =93real customers=94 and will not be a well-defined applicat= ion either.  The requirements are sketchy at best.  A well-defined application with real end-users will typically provide a rich set of requ= irements in some shape or form, preferably in the form of Use-Cases or Scenarios.&= nbsp; A not-so-well-defined application type is a real problem, with not enough requirements, but with a paying customer or funder pushing the developmen= t team to deliver some =93nebulous=94 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 =93one-size-fits-all=94, and = do not addressed the =93real needs=94 of these various development environme= nts.

Therefore, any object guru or process person in charge of =93specifyin= g a process=94 for a software development team must necessarily customize s= tandard 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 resorte= d to in order to simulate the actual functionality to be incorporated. OO processes that can be applied to facilitate the domain analysis must inco= rporate 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 adequ= ate.

A well defined application type with =93real 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 activ= ities.  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 obj= ect model.  More specifically, the obvious objects identified in the fir= st 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 =93funders=94 but fe= w =93potential customers=94

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

The working prototypes are often used to generate "hypothetical" Use-C= ase models or end-user scenarios.  Such use-cases can be approved by the "customer" or funding agency.  The first few iterations of such prod= ucts are typically not meant for general deployment.  Only the nth iterat= ion 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&nbs= p; 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.