Tuesday, June 2, 2009

Model Driven Reqmnt vs Document Driven Reqmnts

The purpose of this blog is to discuss the idea of model driven requirements vs document driven requirements. One may say "this doesn't seem to have much to do with HCI" but it does because obtaining and maintaining requirements requires a lot of customer interaction, internal and external. You have you internal customers, for example subsystem and component level groups. These are the groups that will use your requirements to develop their systems. Stakeholders, end-users, etc can represent external customers. These are the groups that will/should deliver requirements to you. When it comes to usability studies or analyzing your customer's needs, which method is more effective? Sometimes in document-driven requirements (i.e. microsoft word) it is difficult for the requirement writer to express what they really mean. Would it be more helpful to supply the customer with a model that they can "play with" and provide feedback to the design group? In essence the design team could use a model or "service design" as a requirements development tool. Is this possible? A better way? Your thoughts....

1 comment:

  1. This is an interesting comparison. I have actually been on projects that have had the requirements process start off with a requirements document followed by a requirements model. I due agree that a Model Driven approach provides a way for stakeholders to communicate their requirements more clearly. The requirements models we have used a work usually consist of artifacts such as UML, sequence, and use case diagrams. These artifacts early in the planning stages of a project assist in defining and flushing out requirements. We usually go through several iterations with the stakeholders to redefine and update the requirements model.


Note: Only a member of this blog may post a comment.