Lenguaje normativo y ficha de requisito¶
Regla común a ASILO 0.1 y MILPA 0.1.
Para qué sirve¶
Una regla sólo se puede cumplir, auditar o discutir si se sabe qué obliga, a quién, cuándo y cómo se comprueba. Esta página propone el vocabulario y la ficha mínima que usarán los requisitos de ASILO y MILPA en este sitio.
Palabras clave¶
Este repositorio adapta el criterio de BCP 14 (RFC 2119 y RFC 8174) al español. No reclama conformidad con esos RFC, que definen palabras inglesas. La correspondencia propuesta es:
| Palabra en este sitio | Equivalente BCP 14 | Significado |
|---|---|---|
| DEBE | MUST / REQUIRED / SHALL | Obligación sin alternativa dentro del alcance del requisito. |
| NO DEBE | MUST NOT / SHALL NOT | Prohibición sin alternativa dentro del alcance. |
| DEBERÍA | SHOULD / RECOMMENDED | Se espera que se cumpla; apartarse exige razón registrada y aceptación del riesgo. |
| NO DEBERÍA | SHOULD NOT / NOT RECOMMENDED | Se espera evitarlo; hacerlo exige razón registrada y aceptación del riesgo. |
| PUEDE | MAY / OPTIONAL | Opción permitida; no crea obligación. |
Siguiendo la regla de RFC 8174, estas palabras tienen significado normativo sólo cuando aparecen en mayúsculas. En minúsculas conservan su sentido ordinario.
Mientras un requisito esté en proposed, su DEBE describe la obligación que tendría si se
aceptara; hoy no obliga a nadie. Ninguna auditoría puede declarar incumplimiento de un requisito
que no está aceptado.
Estados¶
| Estado | Significado | Quién lo asigna |
|---|---|---|
draft |
Texto en redacción; puede cambiar sin aviso. | Autor |
proposed |
Redacción completa, trazable y lista para decisión. No obliga. | Autor, con procedencia |
accepted |
Obliga dentro de su alcance desde una versión identificada. | Sólo el owner humano, con decisión registrada |
deprecated |
Sustituido o retirado; se conserva para trazabilidad. | Owner humano |
historical |
Explica procedencia; no gobierna. | Owner humano o curaduría |
Una etiqueta en un documento de origen (por ejemplo, «canon») no equivale a accepted: la
autoridad se resuelve por decisión registrada del owner, no por la etiqueta.
Ficha mínima de requisito¶
Cada requisito registra estos campos:
| Campo | Qué contiene |
|---|---|
| ID | Identificador estable (ASILO-R-NNN, MILPA-R-NNN). No se reutiliza aunque el requisito se retire. |
| Estado | Uno de los estados anteriores. |
| Clase | Principio agnóstico, requisito agnóstico, perfil tecnológico o ejemplo. |
| Problema | Qué falla o daño previene. |
| Alcance | Sistemas, artefactos o actividades a los que se refiere. |
| Actor responsable | Rol humano que responde por cumplirlo. |
| Condición de aplicación | Cuándo se activa; fuera de ella no aplica. |
| Formulación verificable | La regla, con palabras clave en mayúsculas. |
| Evidencia esperada | Artefactos que permitirían comprobar el cumplimiento. |
| Excepción | Cómo se autoriza un apartamiento y qué debe registrarse. |
| Riesgo residual | Lo que el requisito no evita aunque se cumpla. |
| Procedencia | Fuente de origen con su revisión, y fuentes externas con versión. Se conserva en el registro del método; la página pública puede omitirla. |
| Decisión pendiente | Qué debe decidir una persona antes de aceptarlo. Tras la aceptación se llama Decisiones futuras y recoge lo que quedó abierto para otra edición. |
Principio, perfil y ejemplo¶
- Principio agnóstico: vale sin importar lenguaje, plataforma o proveedor de modelos.
- Requisito agnóstico: obligación verificable derivada de un principio; no nombra tecnología.
- Perfil tecnológico: selección y concreción de requisitos para un contexto (por ejemplo, TypeScript o un tipo de proyecto). Un perfil no modifica el método base.
- Ejemplo: ilustra; nunca crea obligación.
Si una fuente sólo describe un perfil, la regla extraída se queda en el perfil. Para convertirla en requisito agnóstico hay que justificar por qué aplica más allá de ese contexto.
Excepciones¶
Una excepción a un requisito aceptado registra responsable humano, razón, alcance, duración, riesgos, rollback y fecha de revisión.