Sunday, January 10, 2010

Should Users Be Involved in Database Design?

Database design usually begins with user views of existing data, and in the relational model, is about providing each User their own unique view of the same data. As such, the Developer needs to verify the model meets User requirements, and an effective way to achieve this is by seeking User input early in the design process. An analogy would be the Architect who is designing a kitchen remodel, interviewing the homeowner about their current and future use of the space. The Architect needs to be able to design a plan to fit the homeowner requirements.

The benefit to Users in requirements definition is a database product that enables them more productive in their jobs. For the Developer, the benefit of User involvement is the production of a data model that contributes to the most cost effective solution for the organization.

For Users who are locally available, the benefit to the developer is the ability to conduct interviews and surveys, review documents and observe operations. However, in the case of Users who are not local, with the exception of surveys, these methods may add travel expenses and other costs which may deter an Organization from proceeding with the database project in a timely manner.

Through interviews and observation, the Database Developer may be able to obtain additional information about User requirements from side topics during the course of an interview, or actions or methods employed by Users in normal processing. In addition, through observation, the Developer may be able to garner important information about current processes that management did not know was actually being performed.

The costs are that interviews and observation methodologies are time and labor intensive activities for both the Developer and the Organization. In addition, interviews may generate a “garbage-in-garbage-out” result, if the Interviewer is not skilled or if interview questions are poorly crafted. In addition, when using an observation methodology, the Users may improve their behavior or processes because they realize they are being observed. As a result, no significant improvements in design may be readily available to the Database Developer.

With non-local Users, the Developer can utilize techniques such as surveys, questionnaires, and document review. Surveys and questionnaires offer the Developer an opportunity to cover a vast amount of information in a short amount of time. In addition, if crafted properly, surveys and questionnaires can present information in a standard format as opposed to unstructured, unfocused interview sessions. In other words, the Developer may be able to obtain more accurate results if each User is presented with the same questions.

However, the cost of using surveys and questionnaires for non-local Users is that historical response rates are typically low, unless closely followed by Department Managers or Supervisors. In addition, preparing “unbiased” surveys and questionnaires can be hard to develop and expensive to produce.

Document review is another viable option for the Developer in both local and non-local scenarios. Document review typically takes less time than other methodologies and can perhaps document processes more accurately than obtained by interviews or observation. However, the documentation in place may not reflect “reality” in an operational environment and can fall out of date thereby becoming irrelevant to the Developer.

Thus there no single solution to User involvement in the requirements definition phase of database development as there are varied costs and benefits associated with the various approaches.

No comments:

Post a Comment

Get your own Widget