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.