Change requests often states what is to be accomplished, but leaves out the details on how the change should be carried out.

When you receive a change request, there is probably a need to analyze the change request in detail:

• Are the change requests using the accepted terms and concepts of your application model? If not, adjust the change request’s wording to avoid introducing new terms or concepts. Do not change the terms or concepts of your application model without thorough considerations.
• Is there a smart way of introducing the requested functionality, without adding complexity to your application model?
• Is the change request really the change that should be done to the application, or just a symptom of problems that may be solved by rearranging or changing something else within the application? Consult the Impact Map!
• Will the change affect performance or quality?
• Will the change affect integrations with other systems?

The investigation should lead to an improved and quality checked change request, with a clear hypothesis or description on how to solve the change request.

We urge you to be self-confident in dealing with change requests and trust your education and experience in application modeling. Henry Ford once said, “If I had asked people what they wanted, they would have said faster horses”. This doesn't mean that your customer is wrong, but that the customer's problem may be solved in a better way.

Note that approving and managing change requests are not a part of the Genus Modeling Process. We assume that the change requests are approved or are being approved by a process outside the Genus Modeling Process.