I have been working on some material for an upcoming conference where I wanted to introduce the Force.com platform to developers who may have never even seen the platform before. My first instinct was to espouse cloud computing, the benefits vs. on-premise, and so on. But I sat there, and thought "what is the best way to introduce a new concept or paradigm?" The answer I came up with was make it relevant, and familiar. 

This concept of the familiar started me thinking about, in my opinion, one of the most important aspects of software developer: the identification, use and practice of utilizing patterns; in particular those patterns which are technology independent. A good example is the material presented in the Gang of Four Design Patterns book—now over 20 years old and still just as relevant. How many other technology books can you say that about?

Now bringing the idea of software development back to basics, the first things we typically start with a problem statement. In my experience this problem statement can also help identity our domain or data model. In Force.com development, this is no different, and a great place to start. Take the following example of two related problem statements:

 "As a rep I want to put in my
request, know the status, and
follow up if need be so I can stay up to date with my request submission"

" As an IT member I want to
receive requests and assign them based on some defined business rules such as inventory availability,
office
location etc. And manage approval so I can efficiently turn the request
according to the company's policies."

The trick to working with problem statements is to identify keywords. The items in green are nouns and are good candidates for objects in your data model. The items in pink are adjectives and can be used as fields on an object.

This approach of identifying nouns and adjectives to derive your data model is a great generic pattern or best practice approach when designing any system. This approach works particularly well with agile requirements gathering (basically requirements gathered over the duration of a project vs. upfront as in a waterfall methodology) and the Force.com platform. The platform makes it very quick to point and click to update your data model, and identify dependencies. As you gather more requirements, more nouns and adjectives will be uncovered, and you need to easily 

Why not give this strategy a try next time you need to gather some requirements and build an app on the Force.com platform. I would love to hear how it works out for you.