De onde deve vir o conteúdo do IDS?

IDS escrito do zero é opinião com XML em volta.

O IDS exige trinta propriedades por elemento, distribuídas em oito Psets, com cardinalidade required. Quem lê pergunta: de onde veio essa lista? Qual requisito do contratante pede cada propriedade? Qual uso do modelo justifica cada dado? A resposta, na maioria dos casos, é: veio da cabeça do redator. Ou de outro IDS copiado. Ou de uma planilha que alguém preencheu um dia.

O IDS é o mecanismo — não é a origem do requisito. A origem é a cadeia de requisitos de informação: OIR (requisito organizacional), AIR (requisito de ativo), PIR (requisito de projeto), EIR (requisito de troca) — e o LOIN (nível de informação necessária) que operacionaliza cada um deles. A ABNT NBR ISO 7817-1:2024 define como declarar quanta informação e para qual propósito. O IDS traduz esse LOIN em regra verificável — Pset, nome, tipo de dado, cardinalidade — que o rule engine confere sobre o IFC. Se o IDS nasce sem LOIN, a regra não tem rastreabilidade ao propósito.

IDS sem LOIN de origem tem dois defeitos estruturais. Primeiro, não é defendível: quando o projetista pergunta por que precisa preencher aquela propriedade, não há resposta que suba à cadeia de requisitos. Segundo, não é calibrado: sem saber para que o dado serve, o redator não sabe se a propriedade é necessária naquela fase, se o nível de detalhe é suficiente, ou se a cardinalidade deve ser required ou optional.

O método RASE (Nisbet) traduz requisito normativo em regra verificável: Requirement → Applicability → Selection → Exception. É o passo intermediário que transforma prosa do EIR em lógica da faceta. Sem RASE ou equivalente, o redator salta do requisito vago para o XML sem método.

A §11.2 da ABNT NBR ISO 19650-1 define o nível de informação necessária. A §5.2.1 c) da 19650-2 exige critério de aceitação por requisito. IDS sem LOIN é critério sem requisito — regra que existe por ela mesma.

1. 1

   Ninguém sabe por que a propriedade é exigida · o IDS pede a propriedade, mas nenhum documento do projeto explica para qual uso ou propósito.

2. 2

   IDS escrito antes do EIR · o IDS foi criado antes de os requisitos de troca existirem. A regra nasceu sem origem.

3. 3

   Propriedades demais, sem prioridade · o IDS exige tudo que o redator imaginou. Sem LOIN, não há filtro de necessidade — tudo vira obrigatório.

4. 4

   IDS copiado sem rastreabilidade · o IDS veio de outro projeto. As propriedades eram relevantes lá, mas ninguém conferiu se são relevantes aqui.

5. 5

   Projetista contesta e não há resposta · o projetista pergunta por que precisa daquele dado e o gestor não consegue responder com referência à cadeia de requisitos.

1. 1

   Cadeia OIR-AIR-PIR-EIR ausente · o projeto não tem cadeia de requisitos de informação formalizada. O IDS nasceu sem base.

2. 2

   LOIN não declarado · ninguém definiu quanta informação cada entregável precisa, para qual propósito e em qual fase (§11.2 da 19650-1; ISO 7817-1).

3. 3

   Salto do requisito para o XML · o redator leu o EIR em prosa e escreveu o IDS sem método intermediário (RASE ou equivalente). A tradução é intuitiva, não sistemática.

4. 4

   IDS tratado como produto, não como tradução · a organização trata o IDS como entregável autônomo, não como tradução verificável de requisitos que vêm de outra camada.

5. 5

   Cópia entre projetos sem calibrar · o IDS foi copiado de biblioteca genérica ou de outro projeto sem conferir se as propriedades são relevantes para os usos do modelo atual.

1. 1

   Exigência sem propósito · o projetista preenche propriedades que ninguém vai usar. Trabalho real sobre requisito fantasma.

2. 2

   IDS indefensável em disputa · se o projetista contesta a exigência, o contratante não tem cadeia de requisitos para justificar. A regra cai.

3. 3

   Informação de menos onde importa · sem LOIN, o redator não sabe o que é crítico. O IDS pode exigir informação cosmética e omitir a essencial.

4. 4

   Cardinalidade arbitrária · sem saber para que o dado serve, o redator não sabe se a propriedade deve ser required ou optional. A cardinalidade é chute.

5. 5

   Custo de preenchimento sem retorno · cada propriedade exigida é custo para o projetista. Propriedade sem uso é custo sem retorno — e gera resistência ao BIM.

Curto prazo (30 dias):

1. Rastrear cada propriedade ao propósito. Para cada propriedade do IDS, documentar: qual LOIN justifica, para qual uso do modelo, em qual fase.

2. Remover propriedades sem propósito. Se não há LOIN que justifique, a propriedade sai do IDS. Menos regras, mais propósito.

3. Recalibrar a cardinalidade. Ajustar required/optional conforme o propósito, não conforme o default.

Médio prazo (60-90 dias):

4. Formalizar a cadeia de requisitos. Elaborar ou completar a cadeia OIR-AIR-PIR-EIR com LOIN declarado por entregável.

5. Adotar método de tradução. Instituir RASE ou método equivalente para transformar requisito em regra de forma sistemática.

6. Versionar IDS com rastreabilidade. Cada versão do IDS registra quais requisitos foram adicionados, removidos ou alterados, e por quê.

1. 1

   IDS é tradução, não origem · o IDS traduz o LOIN em regra verificável. Se não há LOIN, não há IDS — há opinião com XML em volta.

2. 2

   LOIN nasce da cadeia de requisitos · a cadeia OIR-AIR-PIR-EIR antecede o IDS. Cada propriedade exigida é rastreável até o uso do modelo que a justifica.

3. 3

   Método de tradução, não intuição · RASE ou método equivalente transforma prosa em regra. Sem método, a tradução depende de quem faz.

4. 4

   Propriedade sem uso não entra · informação além do necessário é desperdício (§11.2 da 19650-1). O IDS exige o mínimo suficiente para o propósito.

• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). Define como declarar quanta informação para qual propósito. O LOIN é a origem do conteúdo do IDS: cada faceta Property, cada cardinalidade, cada dataType nasce do LOIN — não do redator.
• buildingSMART IDS 1.0Information Delivery Specification. O IDS é o mecanismo de verificação, não a origem do requisito. A faceta Entity é a única sem cardinalidade; todas as outras dependem de calibração pelo LOIN.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §11.2 define o nível de informação necessária como o mínimo suficiente para o propósito — informação além é desperdício, aquém é entrega incompleta.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.2.1 c) exige critério de aceitação por requisito de informação. IDS sem LOIN é critério sem requisito — regra que existe por ela mesma.
• ISO 29481-3Information delivery manual, Part 3. Formaliza o IDS como tradução de requisitos em regra verificável. A tradução pressupõe que o requisito exista — sem requisito formal, o IDS é artefato órfão.