ANSWER

Solutions are processes operating on data. It follows that any change to existing solutions will probably involve changes to processes and data requirements. Process requirements can be expressed in BPMN and many other process modeling notations. Data requirements (as opposed to database design requirements - these are logical requirements that the solution has which are relevant to data and have NOTHING at all to do with database design) model the logical data requirements. Logical data requirements should be expressed in notation that focuses only on the logical data requirement and not the solution that might or might not be used. E.g. classes in UML assume object orientated solutions. Logical data model requirements can be implemented on relational databases, object orientated databases, paper or in someone's head. They are not technology dependant: they just state the logical data requirements that must exit in order for processes to deliver the project objectives.

E.g. A requirement exists to be able to offer add-on sales during the order taking process. The order taking process will change to reflect this. The data requirements mean that items offered for sale also have to have relationships established that represent other items that could be offered as add-on sales for the original item. New data requirements will typically require new processes to maintain the required data logical structure. Modeling the data requirements in 3NF means

1. the minimum amount of data is stored the minimum amount of times.

2. logical inconsistencies are prevented by the data structure itself - e.g. it is impossible to offer a customer postage and packing as an add-on sale item as postage and packing are not related to sale items as add-on candidates.

3. business rules associated with the data will be propagated automatically to any process that attempts to create, read, update, delete (CRUD) that data and do not have to be endlessly repeated by all processes that use the data in the processing logic.

4. data requirements (unlike processing requirements) are relatively stable: while the process for order taking changes every year or so, the fact the company sells items and takes payment does not.