Frasear un requisito sobre codificaciones de nombres de archivos

El requisito, según lo establecido, es confuso para mí.

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

1. Cada codificación jamás diseñada, incluido un solo byte (por ejemplo, ISO-8859-15 ), multibyte (por ejemplo, Big5 , Shift-JIS , HZ ), y raros / raros (por ejemplo, UTF-7 , Punycode , EBCDIC ).
2. Eso es obviamente extremo. ¿Qué tal solo el soporte mínimo, a saber, ISO-8859-1?
3. Solo el ISO-8859-1 parece estar mal. ¿Qué hay de solo para apoyar las mejores prácticas modernas, a saber, Unicode como UTF-8 ?

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

Yendo más lejos, ¿qué debe hacer el software con el nombre de archivo, además de no fallar? En caso de que ...

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

Una mejor versión de tu requerimiento sería

  

El descargador debe admitir los nombres de archivo en varias codificaciones, incluyendo 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 se especifica, se puede suponer ISO-8859-1, o se puede hacer una mejor estimación). Los nombres de archivo se normalizarán a una representación de Unicode en el sistema de administración de contenido.

Los ejemplos específicos de codificaciones requeridas son esenciales para diseñar criterios de aceptación. Las oraciones agregadas establecen lo que debe hacer el software, además 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 ambiguo. Debido a la falta de estas características, tampoco es fácil de verificar.

Su requisito de estado inicial es:

  

El nombre del archivo descargado puede contener caracteres que no sean ASCII y su procesamiento no bloqueará la aplicación

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

Esto transforma el requisito en:

  

El nombre del archivo descargado puede contener caracteres no ASCII

Ahora, tienes un requisito cohesivo y atómico. Sin embargo, no estoy seguro de que sea inequívoco. En tu pregunta, mencionas 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 apoyaría mejor los requisitos cohesivos, atómicos, trazables, no ambiguos y verificables. También facilitaría especificar la importancia de cada requisito, tal vez el soporte para algunas codificaciones sea más importante o se necesite más pronto.

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 iba a realizar el enlace en una herramienta de administración de requisitos, se podrían vincular entre sí para que los cambios en uno resaltaran el requisito vinculado. También permitiría que el texto fluya a otros paquetes de software tal como están, pero con una tabla diferente para diferentes codificaciones.

Sin embargo, la forma en que documente 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 uno para "no estrellarse"?

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

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

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

(La palabra "soporte" es todavía 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 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 que no entendiera por _ , con el efecto de que cuando se le pedía que copiara un directorio que contenía dos caracteres cuyos nombres eran idénticos, excepto en caracteres que la utilidad no entendía, el segundo archivo escrito en el directorio sobrescribiría el primero. Tal comportamiento se calificaría como "no fallar", pero eso no debería implicar que es aceptable si no hay una especificación explícita que lo diga.

Yo sugeriría que una buena especificación debería especificar afirmativamente qué debería suceder, o si no, 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 combine 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 asigna los nombres de archivo antiguos y nuevos "o" Si un nombre de archivo contiene caracteres no reconocidos, el sistema puede formar un nuevo nombre al concatenar los caracteres que reconoce; si dos nombres de archivo terminan siendo idénticos a través de dicha transformación, cualquiera de ellos puede ser arbitrariamente declarado el 'ganador' ".