public delegate void OnBlurDelegate(object sender, EventArgs e);

public event OnBlurDelegate Blur;

private void RaiseOnBlurEvent()
{
if(Blur != null)
{
Blur(this, EventArgs.Empty);
}
}

<class name="Student" table="Student">
  <id name="Id" column="Id" />
  <property name="FirstName" column="FirstName" />
  <property name="LastName" column="LastName" />

  <join table="Student_Course" optional="true" >
    <key column="Student_Id" />
    <property name="FinalGrade" column="FinalGrade" />
  </join>
</class>

1) The additional functionality was not implied in the requirements in any form or fashion.

2) It caused a minor delay in development efforts.

3) As far as the object model goes, it is flexible enough to be able to handle the change, the true issue is how additional functionality breaks the process that the customer wanted to lock users into. It is more of an issue of the customer’s request breaking their own business process that they wanted mirrored in the application.

This really comes down to a number of things:
1) was it “implied” in any of the requirements
2) how will it affect the timelines and development efforts
3) how do the project management and customers want to deal with change

1) If it was implied in any of the requirements, but not explicitly spelled out, you might be out of luck and have to do it for no additional cost.

2) when a feature request causes this much pain for the developers and causes potential problems in the existing functionality, it’s up to the developers to inform the project management of the issues so that the project management can report the issues to the customer. ultimately, it’s the customer’s software, but it doesn’t have to be on our dime. if there is a cost associated with the change, then the customer should be willing to pony up that dime. and the customer may decide that the cost is not worth the benefit, right now, and leave it out. on the flip side of that, the project management may decide that the cost is small enough for the development company to eat.

3) change is inevitable. feature requests are inevitable. this is where Agile development efforts really come into play and help you out. i won’t go into detail in a comment to a blog post, though… there are entire libraries of books written about this subject.

if the feature really does make other parts of the system fuzzy or not work entirely correctly, you may be in a situation where the object model needs to be fleshed out in a different manner. perhaps theres something in the language of the customer that has not been clearly defined in the code mode; perhaps this new feature will cause you re-clarify some existing portion of the model; the point is, you may need to look at what’s going on and why, and see if there is a way that the new feature can fit into the model by changing the model in some way. Chapters 8 through 10 of Domain Driven Design discuss this in detail… i highly recommend reading the entire book, too.