While working with outsourcing clients, a common problem appears, is the functional specification. Clients generally don't want to spend much time creating specs, try to write ASAP, which results an unfinished spec. While developing developers suffers a lot. First, it often gets confusing, the developer can't understand exactly what the spec is saying. Second, during the development (and also after seeing some demo), client discovers new features, which results much re-engineering on the code, as this is too late for adding new requirements. 'Traceability Matrix' might really a good solution in this case. What is 'Traceability Matrix'? In short, this is the simple list of features, something like the product feature list in the web sites (well off course TM has some more features). This is easy for clients as it requires less time for them to mention. Since clients are too busy to have time on spec, we can start work on specs, as we get the list of features. A smart system analyst can forward and elaborate the requirements in useful way using 'Traceability Matrix'. • This is the simplest requirement document. So keep it as simple as possible. • Include features in bullets, if necessary group the bullets, according to modular requirements. • Common Functions: Consider special terms, to specify commonly used requirements among several cases. For instance, such special term can be “CRUD”, which says Create, Read, Update and Delete operation in any entity. While writing requirement documents, you can use this commonly used features in multiple cases. Like: User CRUD, Product CRUD, Books CRUD etc. • Common Scenarios: You can also consider special terms for commonly used application scenario. For instance, a special term can be “Create Secured Record”, which tells, 1. Click “Add item” button, 2. The user will be redirected to “Add item” page, 3. User inserts data, 4. User submits data, 5. User provides “security text/code”. 6. User gets back to the caller page.

Business Entity: For each custom business entity, there is a collection class. However, if our tech platform is .net 2.0, we can use the generic list class for collections. Business Layer: 1. Contains a “Save” instance method in business layer for insert and update operations. 2. For delete and get operations, it uses static methods in the business layer. Data Access Layer: Data access layer contains all CRUD operations in one class.

When we define a custom business entity as an architecture for a given project, one common issue arises that, how we will consider “Many to Many” relationships? As there is only one entity for each database table, “Many to Many” tables might not be a good choice to make a separate table for that, since this is basically a connector entity. Case: Database Simplest Samples – Northwind Employees Entities: Employees, Territories, EmployeeTerritories, Region One-to-One: Employees (EmployeeId, ReportsTo) Description: one employee reports to another employee. One-to-Many: Region, Territories (TerritoryId, RegionId) Description: One region has many territories. Many-to-Many: Employee, Territories, EmployeeTerritories (EmployeeId, TerritoryId) Description: One employee belongs to many territories and one territory has many employees. Solutions: 1. Create a single table for the m2m table. 2. Attach the CRUD methods of the m2m table, as static methods, to one of the o2m entity. A common convention can be chosen to attachment, to consider that entity, which is created first. In our case this is author. 3. Attach the m2m primary key, in the “save” instance method (for instance or update) parameter. 4. We can use a collection of objects, in the another tables entity. For example, the employee class may contain a collection of territories or the territory entity may contain a collection of employee object. The save method will be responsible to update the m2m list.

1. In a case, where we are considering m2m, and it’s required to add a new entity record in the m2m table, an obvious case comes, where we create and save the entity first and then we add that entity in the m2m table. For example, when we add a new book to an exiting author’s book list, we first create a “Book” object and save it, and then we add this book to the author book list thru a static method. However, in that case, we might have to consider database server side or application level (ex: COM+) transactions, where the whole operation will be rolled back for any unsuccessful process in the full operation path. 2. While attaching the m2m table to a o2m table, in this case we have to perform data operations in two separate tables. We can do this either in the stored procedure layer at one time, where all required data will be passed thru stored procedure parameters and the stored procedure will perform operations in the separate table. Or this can be done separately from the application layer, which is useful, when we contain a very common format for CRUD operations for each and every database table in the stored procedure layer (generally when we generate CRUD stored procedures).