Determine the Scope of your Analysis

• Has the project scope been clearly defined?
  Note: The Process Modeler and/or Data Flow Diagrammer can be used to illustrate what is included and what is external to the defined scope.
• Have users and sponsors signed off on the scope?
• Were interviewees identified by name or role?
• Were all stakeholders involved, via JAD sessions, interviews, or questionnaires?
  

Establish standards for your modeling work.

• Agree on the terminology of entities, attributes, functions, and business units.
• Use user terminology where possible.
• Agree on terminology across user groups.
• Agree on the labeling conventions, entity short name format, and standard abbreviations for names of entities, attributes, and domains.
  

Gather Information for Completeness of Requirements

Not only top down:

• Gather requirements from all stakeholders/users.
• Ask about future requirements, not just today's.
  

But also bottom up:

• Supporting information detail (attributes, business rules, usage patterns).
• Cross check current database schema, file layouts, screens, reports - and verify needed missing detail.
• Warning: remove any mechanisms when modeling from current systems and procedures.
  
  

Create One Integrated Data Model

• Allows a better view for quality assurance.
• Create subset diagrams for subject area feedback.
• Align the entities and relationships on the ERD to the customary crow flight paths (east and south). This helps patterns become visible, resulting in convergence, and a simpler model.
• Check for redundancy and overlap of data.
  
  

Quality for the Data Model

• 1N: Eliminate derived values, split multi-part attributes, and move out repeating groups of attributes within entities.
• 2N: Check the integrity of the unique identifiers. Does each attribute depend on all parts of the entity's UID?
• 3N: Are some attributes really relationships (FKs)? Do any attributes depend more directly on another attribute than on the entity's UID? If so, they should be drawn out as a related, separate entity to reach 3NF.
  
  

Document Entity Detail

• Define Entity format, optionality, and description. Add initial and maximum volume information for database sizing. Enter descriptive comments and allow users to give feedback on the resulting glossary report run from these descriptions.
• Add any Entity Notes to document static business rules that affect data independent of functions.
• Add Entity detail, including:
  - Entity definitions
  - Examples (important for testing later)
  - Any helpful miscellaneous information

Document Attribute and Relationship Detail

• Note any non-transferable relationships. (Default is transferable except for relationships in the UID.) Do all relationship names read well with the verbs may be and must be? (Helpful for user feedback session.)
• Specify Delete Cascade/Update Rules for M:1 relationships.
• Document domains for attributes in a domain.
• Document attribute detail: optionality, format, comment or description, and any attribute-level business rules.
  
  

Quality Assurance on Functions

• Do all elementary functions use entity names?
• Have all mechanisms been avoided?
• Does each parent function imply all children?
• Does each child function fit under its parent?
• Are siblings of equal weight?
• Are there about 5-7 children under each parent?

QA Matrices

• Define function/entity (CRUD) usage.
• Is there a function that allows each entity to be Created? Retrieved? Updated? Deleted? Archived?
• Define function/attribute usage.
• Can attribute values be Inserted? Retrieved? Updated? Nullified?
• Do not allow Update or Nullify for UID attributes!

Complete the Function or Process Description

• Explain why the function is important and for whom.
• Record dynamic business rules and complex function logic as sub-elementary functions, to become PL/SQL procedures, etc.
• Add Data Operation Rules (CRUD rules).
• Add Update Rules governing relationships, attribute changes, etc.
• Add Change Event Rules (DML actions).
• Document triggering events, and events triggered by functions.
• Define common functions (if > 20%, rework the functional model).
• Specify function frequency (needed for data processing priorities).
  
  

Define Function Access and Authorization

• Define the hierarchy of organizational units and sub-unit roles in the RON or Process Modeler.
• Which user roles will access which functions? Locate functions in the appropriate business unit swim lanes in the Process Modeler, or matrix usage via the Matrix Diagrammer.
• If a function is matrixed to more than one business unit, do NOT use the Process Modeler.
• Specify access to horizontal data. Are all entities included to ensure access restriction by row values (e.g., if Deptno = 20, allow access)? Specify access to vertical data. Matrix business units to attributes using the Matrix Diagrammer.
• These steps will enable the creation of default menus and module networks, and simplify security design.
  
  

A Good Subset of Reports for Essential QA:

• Entities without attributes: are UIDs enough (including relations)?
• Entities without relationships: lost in space?
• Entities without unique identifiers: don't generate yet!
• Entities without descriptions or comments: won't yield glossary or help text.
• Entities not used by functions: outside the scope or duplicate?
• Attributes not used by functions:
  - Quality Checking of Relationships.
  - Attributes in a Domain.
  - Other QA reports for BPR and DFD users.
  
  

Use the Matrix Diagrammer to Filter and Show Potential QA Problem Areas:

• Functions with frequency = null.
• Entities with initial or maximum volume = null.
• Atomic functions = yes where elementary = no.
• Entity short names where char size > 3 (or 4 if subtypes).
• Functions with description (or comment) = null.
• Entities with no CREATE or no DELETE CRUD usage, etc.
  
  

Next Steps

• Perform a semi-formal QA walkthrough within IS project team, without users.
• Conduct JAD user feedback session(s) by user group or across departments to reach consensus.
• Consider a few days of an external independent validation and verification by a QA consultant.
• Consolidate results from feedback and QA Then, ready for the Design Transformer!

For information on our QA services or our systems analysis, modeling and design courses, contact us.



Renée Taylor Consulting
Tel. 1 (530) 692 2000
Based in Sacramento
Serving California State government clients, other public sector and corporate clients internationally