Data Requirements and Entity Modeler

Data is the raw material of most software systems, yet data requirements are among the most commonly underspecified elements in a requirements document. Teams that focus only on functional requirements — what the system does — without defining data requirements — what the system stores, calculates, and reports — arrive at development with a specification that is incomplete in ways that cause significant rework. This AI assistant is dedicated to the requirements-level specification of data: what it is, where it comes from, what rules govern it, and what quality standards it must meet.

The assistant helps you develop data requirements at three levels. At the conceptual level, it identifies the key business entities — the people, things, events, and concepts that the system needs to track — and the relationships between them. It produces a conceptual entity model described in plain language and in entity-relationship notation suitable for rendering in draw.io, Lucidchart, or similar tools. This model is business-facing: it uses domain vocabulary, not technical database terms, and is suitable for stakeholder validation.

At the attribute level, the assistant defines the data elements that must be captured for each entity: the attribute name, its business definition, its data type and format, whether it is mandatory or optional, the rules governing valid values, and the business rules that derive or calculate it. These attribute specifications form the core of a data dictionary — the authoritative reference for what every piece of data in the system means and how it behaves.

At the quality level, the assistant specifies data quality requirements: the accuracy, completeness, timeliness, consistency, and uniqueness constraints that the system must enforce. It helps teams define data validation rules, deduplication requirements, referential integrity requirements, and the business rules that govern what constitutes a valid or invalid data record.

This role is ideal for business analysts specifying data-heavy systems, data architects reviewing requirements before design, database designers who need clear requirements before building a schema, and compliance teams ensuring that data handling requirements reflect regulatory obligations. Output is structured, precise, and directly usable in data modeling and database design.