Formulación de un requisito sobre codificaciones de nombre de archivo

Estoy en el proceso de escribir una especificación de requisitos, y tengo el dilema de formular una parte de los requisitos.

Escenario: Descargamos archivos de un sitio web y los archivos descargados deben adjuntarse a un elemento en la herramienta CM que tenemos. Los archivos descargados contienen nombres que pueden ser ASCII, ISO-8859-1, japonés, etc.

En la frase a continuación, ¿cubre "no ASCII" todas las situaciones?

El nombre del archivo descargado puede contener caracteres no ASCII y el procesamiento de este no bloqueará la aplicación

El requisito, como se dijo, es confuso para mí.

La primera pregunta que tendría es: ¿cuántas codificaciones de caracteres deben ser compatibles? Las posibles interpretaciones incluyen:

1. Cada codificación que se haya diseñado, incluidos los de un solo byte (por ejemplo, ISO-8859-15 ), multibyte (por ejemplo , Big5 , Shift-JIS , HZ ) y los raros / extraños (por ejemplo, UTF-7 , Punycode , EBCDIC ).
2. Eso es obviamente extremo. ¿Qué tal solo el soporte mínimo, es decir ISO-8859-1?
3. Solo ISO-8859-1 parece comadreja. ¿Qué tal simplemente apoyar las mejores prácticas modernas, a saber , Unicode como UTF-8 ?

Si no especifica a qué codificaciones se refiere, entonces cuando ocurre un error específico de codificación, usted y el implementador podrían tener una pelea y ambos tendrían razón. Esa es, por definición, la consecuencia de una especificación difusa.

Yendo más allá, ¿qué necesita hacer el software con el nombre del archivo, además de no fallar? Deberia…

4. ¿Conservar el nombre de archivo en su codificación original, byte por byte?
5. ¿Normalizar todo a Unicode? Si es así, ¿necesita detectar automáticamente la codificación de origen? ¿Por qué mecanismo?
6. Almacene tanto el formulario Unicode como el original, en caso de que falle la normalización.

Una mejor versión de su requerimiento sería

El descargador debe admitir nombres de archivo en varias codificaciones, incluidas al menos ASCII, ISO-8859-1, ISO-8859-15, KOI8-R, UTF-8, Shift-JIS, EUC-JP, GB2312 y Big5. Si la respuesta del servidor web especifica una codificación, debe respetarse. (Si la codificación no está especificada, se puede suponer ISO-8859-1, o se puede hacer una mejor suposición.) Los nombres de archivo se normalizarán a una representación Unicode en el sistema de gestión de contenido.

Los ejemplos específicos de codificaciones requeridas son esenciales para idear criterios de aceptación. Las oraciones agregadas indican lo que el software necesita hacer, más allá de no fallar.

El requisito que ha escrito no tiene las características de un buen requisito . Específicamente, no es cohesivo, no es atómico y no es inequívoco. Debido a la falta de estas características, tampoco es fácilmente verificable.

Su requisito de estado inicial es:

El nombre del archivo descargado puede contener caracteres no ASCII y el procesamiento de este no bloqueará la aplicación

Recomendaría eliminar el "... y el procesamiento de esto no bloqueará la aplicación". Si tiene el requisito de que una pieza de software necesita hacer algo, creo que está bien suponer que debería hacerlo sin bloquear el software.

Esto transforma el requisito en:

El nombre del archivo descargado puede contener caracteres no ASCII

Ahora, tiene un requisito cohesivo y atómico. Sin embargo, no estoy seguro de que sea inequívoco. En su pregunta, menciona varios formatos diferentes. Hay algunas opciones

Algunos recomendarían un requisito separado y único para cada codificación de nombre de archivo que debe ser compatible. Esto respaldaría mejor los requisitos cohesivos, atómicos, trazables, inequívocos y verificables. También facilitaría la especificación de la importancia de cada requisito: quizás el soporte para algunas codificaciones sea más importante o se necesite antes.

Otros pueden recomendar una tabla de formatos compatibles y este requisito se vincularía a una tabla. Sería menos completo (tiene una oración textual y una tabla para mantener), pero estarían en el mismo documento o base de datos. Sin embargo, si fuera a realizar la vinculación en una herramienta de gestión de requisitos, podrían vincularse entre sí para que los cambios a uno resaltaran el requisito vinculado. También permitiría que el texto fluya a otros paquetes de software tal cual, pero con una tabla diferente para diferentes codificaciones.

Sin embargo, la forma en que documenta los requisitos depende de sus necesidades específicas.

Hay un par de problemas con su redacción que debilitan el requisito:

1) Debe expresar el requisito en términos positivos , en lugar de en términos de lo que no debe hacer . ¿Cómo se prueba para "no estrellarse"?

2) La frase "El nombre del archivo descargado puede contener ..." es vaga.

Una formulación alternativa sugerida (puramente subjetiva, por supuesto) podría ser:

La aplicación admitirá nombres de archivos descargados que contengan caracteres no ASCII.

(La palabra "soporte" sigue siendo un poco vaga y podría cambiarse para que sea más concreta si se toma junto con otros requisitos para su aplicación).

El problema con la especificación tal como está escrita es que no dice qué debe hacer la aplicación con los nombres de archivo "interesantes". Encontré un programa que reemplazaría cualquier carácter de nombre de archivo con el que no entendía _, con el efecto de que cuando se le pidió que copiara un directorio que contenía dos caracteres cuyos nombres eran idénticos, excepto en los caracteres que la utilidad no entendió, el segundo archivo escrito en el directorio sobrescribiría el primero. Tal comportamiento calificaría como "no estrellarse", pero eso no debería implicar que sea aceptable en ausencia de una especificación explícita que lo diga.

Sugeriría que una buena especificación debería especificar de manera afirmativa lo que debería suceder, o bien, observar qué cursos de acción son aceptables, por ejemplo, "Si un nombre de archivo contiene caracteres no reconocidos, el sistema debe generar un nuevo GUID para la operación general y generar un nombre de archivo que combina ese GUID, un número de índice y cualquier parte del nombre de archivo original que pueda acomodarse fácilmente; debe producir una tabla que asigne los nombres de archivo antiguos y nuevos "o" Si un nombre de archivo contiene caracteres no reconocidos, el sistema puede formar un nuevo nombre concatenando los caracteres que reconoce; si dos nombres de archivo terminan siendo idénticos a través de dicha transformación, cualquiera de los dos puede ser declarado arbitrariamente como el "ganador" ".