Analyse this User Story:

“As a Data Analyst, I want an anonymised copy of our 2025 sales data, so that I can use it for customer research without risking exposure of individual identities.”

While this may look like a well-written User Story that follows the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) criteria, there is some ambiguity that carries potential legal, ethical and reputational implications.

Whether we use AI simply to assist with some of the tasks or we have a sophisticated AI tool that can process and output the anonymised data, any ambiguity that is not clarified may lead to unintended results.

Analysis

Anonymise – Wouldn’t simply obscuring or removing the customer names from the data make it anonymous? Well, technically, and by the definition that AI understands, yes. But what if the data includes addresses or phone numbers? Wouldn’t that potentially still reveal someone’s identity?

So to be safe, why don’t we just remove all personal information? Yes, that’s possible, but what if our research needs to identify statistics based on customers’ postcodes / cities / countries?

These are all questions that good a Business Analyst needs to ask when eliciting requirements from the stakeholders. The good news is, such elicitation techniques can be learned, and as with many things, the more you practice the better you become.

Ambiguity in Requirements Documentations

And don’t forget, in the requirements lifecycle, requirements elicitation is only one link in the chain. After eliciting the requirements, you still need to document them so that the requirements can be implemented, tested, deployed, used and supported.

As we know, and as we can see from the example User Story above, the English language is prone to ambiguity. That’s why good requirements documents often include visual artefacts, such as BPMN diagrams, data models, Use Cases, Decision Trees, etc. The structured nature of these artefacts allows you to efficiently describe processes, data flows and rules with minimised risks of misinterpretation, by both humans and AI tools.

Become an AI-Ready Requirements Expert

• Business Requirements Elicitation
• Business Analysis Accelerated
• Business Process Modelling
• Writing Better Requirements

– Browse all Business Analyst Courses. –

The post The Risks of Ambiguous Requirements in AI appeared first on IRM Training.

To produce a data model (a logical view of the data) the technique of choice has been, and still remains, the entity relationship diagram (ERD). However in Object Oriented Development (OOD), classes are used to group together things (including data) that have similar properties. Class diagrams in themselves do not provide a straightforward path to database design because they do not represent a logical view of the data. To get this logical view we need to modify how class diagrams are used so that we can have a single view of the data in our application.

Read the full paper here: Data Modelling and Object Oriented Development

If you liked this paper, you may also enjoy:

Event-Based Analysis & Modelling

How to of Essential Modelling

The post Data Modelling & Object Oriented Development appeared first on IRM Training.