Even today, business analysts in some companies are expected to record requirements solely in the form of a gruesome “system shall” list that covers acres of paper and consumes gallons of toner to print. 

Such a list is typically:

• Long (dozens of pages)
• Unwieldy (because of the lack of obvious ways to partition it)
• Disorganized (different varieties of requirement are jumbled together)
• Incomplete (it seems to have no natural end)
• Inconsistent (because of its length and organization, its contradictions are hard to spot)
• Incorrect (because it’s inhumane to force people to read it through and fix it)

Now, I’m not advocating dropping the “system shall” list entirely, because (apart from the above deficiencies) it’s fine.  However, many requirements that it tries to encompass can instead be captured much better by models. 

The most important model for business analysis and requirements capture is undoubtedly the domain model.  The business analyst who wields a domain model has analysis powers denied to the ordinary human.

Learning Objectives

• Understand the basics of the domain model
• Know how to use the domain model to record certain kinds of business rules and requirements
• See how the domain model can trace back to a standard requirements list, if necessary
• Appreciate the domain model’s benefits for the business analyst

Skill Level: Intermediate