Technique Summary: BABOK 10.11, 10.12, and Agile 7.6

Technique Summary: BABOK 10.11, 10.12, and Agile 7.6
By Alissa Johnson
Below is a summary of Technique 10.11 Concept Modelling and 10.12 Data Dictionary from BABOK® version 3 and Technique 7.6 Minimum Viable Product from the Agile extension to the BABOK guide version 2.
 
Technique 10.11 – Concept Modelling
Purpose – Concept modelling is used to organize business vocabulary to consistently and thoroughly communicate domain knowledge. It is especially important where situations call for high precision and subtle distinctions.
 
Description – Concept models differ from data models; although often rendered graphically, they are not intended to unify, codify, and simplify data. Rich, natural language vocabulary is emphasized, to identify the correct choice of terms for use in all communications. Concept modelling starts with a glossary, which focuses on the domain’s core noun concepts and provides high-quality, design-independent definitions free of data or implementation biases.
 
Concept models help:

  • organize, retain, build-on, manage, and communicate core knowledge;
  • ease stakeholder resistance to the perceived technical nature of data models, class diagrams, or data element nomenclature and definition;
  • drive innovative solutions when re-engineering business processes or other aspects of business capability; and
  • the enterprise face regulatory or compliance challenges.

 
Elements
Noun Concepts - The most basic concepts in a concept model, the ‘givens’ of the domain.
 
Verb Concepts - Provide basic structural connections between noun concepts. They are given standard wordings, so they can be referenced unambiguously. Sometimes verb concepts are derived, inferred, or computed by definitional rules. New knowledge or information is built up from more basic facts.
 
Other Connections - Since concept models must support rich meaning (semantics), other types of standard connections are used besides verb concepts. These include but are not limited to categorizations, classifications, roles, and partitive (whole-part) connections.
 
Usage Considerations

Strengths Limitations
Independent of data design biases and the limited business vocabulary coverage of data models. May set expectations too high about how much integration can be achieved on short notice.
Provide a business-friendly way to communicate with stakeholders about precise meanings and subtle distinctions. Requires a specialized skill set based on the ability to think abstractly and nonprocedurally
about know-how and knowledge.
Useful for white-collar, knowledge-rich, decision-laden business processes. The knowledge-and-rule focus may be foreign to stakeholders.
Helps ensure that large numbers of business rules and complex decision tables are free of ambiguity and fit together cohesively. Requires tooling to actively support real-time use of standard business terminology in writing business rules, requirements, and other forms of
business communication.

 
Technique 10.12 – Data Dictionary
Sometimes referred to as metadata repositories, data dictionaries standardize definitions of data elements, which enables a common interpretation of their usage, allowable values and meanings between stakeholders within the context of a solution. As organizations adopt data mining and more advanced analytics, a data dictionary may provide the metadata required by these more complex scenarios. A data dictionary contains definitions of each data element and indicates how those elements combine into composite data elements.  They are often used in conjunction with an entity relationship diagram (see Data Modelling) and may be extracted from a data model. Data dictionaries can be maintained manually (as a spreadsheet) or via automated tools.
 
Data ElementsDefines each primitive data element and indicates how those elements combine into composite data elements, which will be used by all stakeholders.
 
Primitive Data Elements Each data element in the data dictionary must be recorded with:

  •  Name: a unique name, which will be referenced by the composite data elements.
  •  Aliases: alternate names for the data element used by various stakeholders.
  •  Values/Meanings: a list of acceptable values for the data element. This may be expressed as an enumerated list or as a description of allowed formats for the data (including information such as the number of characters). If the values are abbreviated this will include an explanation of the meaning.
  •  Description: the definition of the data element in the context of the solution.
  •  Composite Elements Built using data elements, which may include:
  •  Sequences: required ordering of primitive data elements within the composite structure. For example, a plus sign indicates that one element is followed by or concatenated with another element: Customer Name = First Name+Middle Name+Family Name.

 Repetitions: whether one or more data elements may be repeated multiple times.
 
Optional Elements: may or may not occur in a particular instance of the composite element.
 
Usage Considerations

Strengths Limitations
A shared understanding among all stakeholders of the format and content of relevant information Requires regular maintenance, otherwise the metadata could become obsolete or incorrect.
A single repository of corporate metadata promotes the use of data throughout
the organization in a consistent manner.
All maintenance must be consistent to ensure stakeholders can quickly and easily retrieve the information they need, requiring time and effort from the stewards responsible for the accuracy and completeness of the data.
  Unless care is taken to consider the metadata required by multiple scenarios, it may have limited value across the enterprise.

 
Examples of Data Dictionaries
https://denver.iiba.org/sites/denver/files/data_dictionary1.png

 
 
Agile Technique 7.6 – Minimal Viable Product
Business analysis professionals use Minimal Viable Product (MVP) to identify a hypothesis that will test the smallest set of requirements or core features sufficient to deliver value to stakeholders and satisfy early adopters in the shortest time possible. While avoiding cost and risk associated with developing the wrong product, it also enables iterative development cycles by collecting and analyzing feedback before delivering additional features. MVP applies to:

product development services (to test willingness to pay)
feature development (to gauge demand) differentiation (market test strategy)

Step 1: Determine the problem to be solved and identify a hypothesis for the solution.  
Step 2: Identify the minimum features to test the hypothesis with the target market.
Step 3: Analyze validated feedback from customers on feasibility of the solution, and any necessary additional features to increase its adoption.
Target audience - Clearly identify the target market and likely early adopters of the solution. Analysis of these groups identifies what problems they may have related to the proposed solution.
Goal to Achieve or Hypothesis to Test - Clearly define the goal or the hypothesis to test with MVP.
Mechanism to Measure Learning - Identify objective measurements to correlate and interpret the feedback received to validate the hypothesis or determine if the desired goal was achieved. These measurements influence further solution development by identifying the success of the current MVP.
Defined Requirements – Create the minimal set of requirements necessary to deliver the MVP based on the target audience, the goal to achieve, and the mechanism to measure feedback. They must contain just enough information to release the solution quickly, but also thoroughly validate the hypothesis.
Usage Considerations

Strengths Limitations
Less expensive than developing a product with more robust features Requires advanced market analysis to identify the necessary feature set for early adopters
Reduces cost and risk by gaining customer feedback before engaging in a full solution There is no formula, and desired features are a best guess
Avoids building products customers don’t want, thereby reducing risk Not about creating a minimal product, but testing an initial hypothesis for a product
Tests actual usage scenario instead of relying on market research Not useful with clear or simple solutions, where the defined MVP is the complete product