In a requirements document, I tend to concentrate on higher level business objects rather than thinking in terms of databases or classes. Taking a simple example of an address book, the requirements document would detail what information the user wanted to store about a person. i.e Name, Work Address, Work Phone, HomeAddress, Home Phone, Date of Birth. This would be my Person 'business object' Then when I came to my design document, I'd think about the Person object in terms of classes. In the case of a Person, there would probably be a Person class, an Address class. The Person class would have Name, Work Phone, Home Phone, Date of Birth properties and would also have two instances of the Address class, one for Home and one for work. The Address class would have the usual address details, Street, Town, Postcode I'd then think about the best way to store this information in the target database. In an SQL database, I would probably have a Person table and an Address table. The person table would have the Name, WorkPhone, Home Phone and DOB columns with a key record identifier. The Address table would havee the Street, Town, Postcode columns. A flag column indicating whether it was a home or work address, and a foreign key linking back to the Person table to state which person the address belonged to. I'd then design a class to handle the loading and saving of a person's details, probably using a Provider pattern. Michael CP Blog [^] Development Blog [^]
