We're having trouble deciding just who does what and when they do it in the development life cycle.

Q:

I believe this is primarily a process or methodology question. It has to do with responsibilities of the data administrator on a software development project. In our rather small shop, programmers have traditionally acted as business analysts as well, gathering business/functional requirements from users. Our data administrator (DA) creates a logical data model based on requirements, but then wishes to review the model and requirements with the business users. Shouldn't the data administrator be able to glean data requirements from documented functional requirements rather than having to essentially re-interview the business folks? Also, does the logical model really need to be reviewed by the business area? Isn't this more of a dialog between the DA and developer to make sure that the developer can implement desired functionality based on the data modeled?

A:

Les Barbusinski's Answer: Developers are process oriented, and all of the questions they ask a user are process oriented. This perspective frequently masks the real needs of the application and/or enterprise. In most applications the data is the object of the process ... not a by-product of the process (as most developers would see it). Data always has a life cycle. If you approach it from a process-oriented perspective, you'll often miss key business rules as well as whole stages in the life cycle and short change the design of the application ... causing costly rework at some future point of time (if not an actual loss of business for the enterprise).

My advice would be to include the DA in all your requirements-gathering sessions with the end users. This will minimize the impact on the users, and ultimately lead to a better design and a better product. Hope this helps.