¿Mejor palabra para requisitos opcionales? [cerrado]

¿Cuál es una mejor palabra para un requisito opcional en ingeniería de software? La frase es contradictoria. He usado "Requisitos no básicos" en proyectos anteriores.

El término "requisito fuera de alcance" posiblemente se puede utilizar. Esto significa que el requisito se ha capturado dentro de su proceso y se puede rastrear, pero se ha determinado que el requisito está más allá del alcance actual del sistema, debido a una serie de razones, como el presupuesto, el horario, el tiempo o viabilidad.

Sin embargo, la frase "requisito opcional" se usa comúnmente para denotar algo que está dentro del alcance, pero no necesariamente requerido por el sistema. Es una medida de la prioridad del requisito. En mi experiencia, los requisitos a menudo se priorizan como obligatorios, deseables u opcionales (aunque también hay otros esquemas). Para que un proyecto se considere completo y completamente funcional, se deben cumplir todos los requisitos obligatorios. Dados los recursos suficientes, los requisitos deseables serían implementados a continuación. Finalmente, se incluiría todo lo que se considere opcional.

Creo que la confusión proviene del término "requisito". En el idioma inglés, un requisito es "una cosa que se necesita" o "una condición obligatoria, obligatoria o necesaria". Sin embargo, en ingeniería de software, el término requisito es simplemente una característica documentada de un sistema de software. El concepto de opcional y obligatorio describe la prioridad de la característica documentada del sistema de software.

Nos referimos a ellos como características "agradables de tener" en lugar de requisitos.

Para la documentación de requisitos de software, la redacción de Requisitos opcionales está perfectamente bien, siempre que utilice este término de conformidad con las palabras clave RFC 2119 para indicar los niveles de requisitos , es decir, para indicar elementos que son realmente opcionales.

Cuando el texto de su especificación implique verbo en lugar de adjetivo, use "MAYO" en lugar de "OPCIONAL".

Como es pequeño y fácil de leer, el texto RFC se cita a continuación:

    Grupo de trabajo de red S. Bradner
    Solicitud de comentarios: 2119 Harvard University
    BCP: 14 de marzo de 1997
    Categoría: Mejor práctica actual


            Palabras clave para usar en RFC para indicar niveles de requisitos

    Estado de esta nota

       Este documento especifica las mejores prácticas actuales de Internet para
       Comunidad de Internet, y solicita discusión y sugerencias para
       mejoras La distribución de este memo es ilimitada.

    Resumen

       En muchos documentos de seguimiento de estándares se usan varias palabras para significar
       Los requisitos en la especificación. Estas palabras son a menudo
       capitalizado Este documento define estas palabras como deberían ser
       interpretado en documentos IETF. Autores que siguen estas pautas
       deberían incorporar esta frase cerca del comienzo de su documento:

          Las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBERÁ", "DEBERÁ
          NO "," DEBE "," NO DEBE "," RECOMENDADO "," PUEDE ", y
          "OPCIONAL" en este documento debe interpretarse como se describe en
          RFC 2119.

       Tenga en cuenta que la fuerza de estas palabras se modifica por el requisito
       nivel del documento en el que se utilizan.

    1. DEBE Esta palabra, o los términos "REQUERIDO" o "DEBERÁ", significa que el
       La definición es un requisito absoluto de la especificación.

    2. NO DEBE Esta frase, o la frase "NO DEBE", significa que el
       La definición es una prohibición absoluta de la especificación.

    3. DEBE esta palabra, o el adjetivo "RECOMENDADO", significa que hay
       pueden existir razones válidas en circunstancias particulares para ignorar un
       ítem particular, pero las implicaciones completas deben ser entendidas y
       pesado cuidadosamente antes de elegir un curso diferente.

    4. NO DEBE Esta frase, o la frase "NO RECOMENDADO" significa que
       Pueden existir razones válidas en circunstancias particulares cuando el
       El comportamiento particular es aceptable o incluso útil, pero
       implicaciones deben entenderse y sopesar el caso cuidadosamente
       antes de implementar cualquier comportamiento descrito con esta etiqueta.

    5. MAYO Esta palabra, o el adjetivo "OPCIONAL", significa que un elemento es
       Realmente opcional. Un proveedor puede optar por incluir el artículo porque un
       el mercado particular lo requiere o porque el vendedor siente que
       mejora el producto mientras que otro proveedor puede omitir el mismo artículo.
       Una implementación que no incluye una opción particular DEBE ser
       preparado para interoperar con otra implementación que hace
       incluir la opción, aunque quizás con funcionalidad reducida. En el
       misma veta una implementación que incluye una opción particular
       DEBE estar preparado para interactuar con otra implementación que
       no incluye la opción (excepto, por supuesto, para la función
       la opción proporciona)

    6. Orientación en el uso de estos imperativos.

       Los imperativos del tipo definido en este memo deben usarse con cuidado
       y con moderación En particular, solo DEBEN usarse donde está
       realmente requerido para la interoperación o para limitar el comportamiento que tiene
       potencial para causar daño (por ejemplo, limitar las retransmisiones)
       ejemplo, no deben usarse para tratar de imponer un método particular
       en implementadores donde el método no es necesario para la interoperabilidad.

    7. Consideraciones de seguridad

       Estos términos se usan con frecuencia para especificar el comportamiento con seguridad
       trascendencia. Los efectos sobre la seguridad de no implementar un DEBE o
       DEBE, o hacer algo que la especificación dice NO DEBE o DEBE
       NO se puede hacer puede ser muy sutil. Los autores de documentos deben tomarse el tiempo
       para elaborar las implicaciones de seguridad de no seguir
       recomendaciones o requisitos ya que la mayoría de los implementadores no tendrán
       tuvo el beneficio de la experiencia y discusión que produjo el
       especificación.

    8. Agradecimientos

       Las definiciones de estos términos son una amalgama de definiciones tomadas
       de una serie de RFC. Además, las sugerencias han sido
       incorporado de varias personas, entre ellas Robert Ullmann, Thomas
       Narten, Neal McBurnett y Robert Elz.

No estaría de más si su documentación se refiere a RFC como fuente de definiciones:

Este documento utiliza definiciones basadas en las especificadas en RFC 2119 .

Aprecio que no sea una respuesta a tu pregunta, pero en mi mundo, sigue siendo un requisito, incluso si por alguna razón no lo vas a cumplir.

Me gusta el enfoque MoSCoW (debe tener, debería tener, podría tener, no tendrá esta vez) para clasificar los requisitos con los usuarios, junto con otros factores (en mi mundo regulado, los requisitos pueden ser críticos o no críticos, y muchos se desata un argumento sobre requisitos opcionales pero críticos).

Una mejor palabra para un requisito opcional es " Recomendación "

¿Qué hay de identificarlo como una característica opcional o tareas opcionales? Esto solo se hará si en un momento determinado del proyecto se ha determinado que hay tiempo y dinero disponibles para completar estas funciones.

También podrían activarse si se produce un evento externo. Si los clientes cambian a Windows 8, las siguientes tareas deberán realizarse ...

La descripción de la función debe incluir una fecha límite para determinar si se realizará.

Los requisitos se clasifican en 4 áreas en Ingeniería de software:

1. Requisitos comerciales : se centra en las metas comerciales generales y los objetivos del sistema
2. Requisitos del usuario : se enfoca en los objetivos del usuario y en lo que los usuarios deben hacer para usar el sistema para lograr los objetivos comerciales
3. Requisitos funcionales : qué funcionalidad y tareas debe realizar el sistema para alcanzar los objetivos comerciales
4. Requisitos no funcionales : ¿Qué requisitos existen además de los funcionales? Esto incluye entorno, restricciones, interfaz, problemas de mantenimiento, etc.

Ahora los requisitos pueden ser opcionales u obligatorios , dependiendo de las 4 categorías anteriores, que he descrito anteriormente. Los requisitos opcionales también pueden caer dentro del alcance del sistema en consideración o también fuera de su alcance. Los requisitos opcionales son buenos medios para evitar Scope Creep y definir su alcance en términos precisos.

Los requisitos opcionales siempre serán parte de la ingeniería de software, ya que nos ayudan a identificar el alcance y son un buen medio para evitar el alcance del alcance. Nunca se puede decir que contradicen las prácticas de ingeniería de SDLC. Sin embargo, los requisitos tienen prioridad y están bien definidos.

En la plantilla Volere se usa el término "sala de espera".

... Esta plantilla está diseñada para usarse como base para sus especificaciones de requisitos. La plantilla proporciona cada uno de los tipos de requisitos apropiados para los sistemas comerciales, científicos y de software actuales. Proporciona una lista de verificación, estructura y trazabilidad para sus requisitos ... La plantilla es independiente de la herramienta y se ha utilizado con éxito con Yonix, Requisite, DOORS, Calibre RM, IRqA y otras herramientas populares ...

Las técnicas Volere se describen en el libro Dominando el proceso de requisitos de Suzanne Robertson y James Robertson ...

En mi negocio (nave espacial), se denominan "objetivos", lo que indica que están documentados y se hará un esfuerzo para cumplirlos, pero el sistema aún se considerará exitoso si no se cumplen; "deseos" (no es una palabra real, pero ahí está), lo que indica que alguien los quiere y están tratando de alcanzar el estado de objetivos pero aún no son aceptados o documentados; o "requisitos progresivos", que es una versión más despectiva de los deseos que indican cosas que están tratando de tomar recursos pero que no valen la pena en un proyecto que trata de lograr "lo suficientemente bueno" donde comprometerán o amenazarán con alcanzar los requisitos reales.

Si sus requisitos tienen prioridad , puede considerarlos requisitos de baja prioridad .

Estoy bastante sorprendido de que nadie haya mencionado que esos se llaman "objetivos". Todas las empresas para las que he trabajado los han llamado así. Se denotan mediante el uso de las palabras "will" o "should" en lugar de "should". A veces se incluyen en llaves cuando se habla de números. por ejemplo, el sistema funcionará continuamente sin necesidad de atención del operador durante 100 {250} horas. Lo que significa que el requisito que debe cumplirse es de 100 horas, pero el objetivo es de 250 horas.

Como nota al margen, rara vez alguien realmente diseña para cumplir con el requisito objetivo, a menos que haya algún tipo de incentivo involucrado.

El término "Deseo" a veces se usa para requisitos opcionales. Sin embargo, puede no ser apropiado para un documento formal.

Me sorprende que todas las respuestas estén relacionadas con los requisitos de seguimiento en el desarrollo de proyectos. A pesar de ser un desarrollador, nunca me he preocupado demasiado por esta terminología en ese contexto. Cuando leí la pregunta por primera vez, supuse que estaba relacionada con la especificación del producto del usuario, no con el desarrollo del producto. Por ejemplo, una enciclopedia puede enumerar una impresora a color como un requisito opcional. Es obligatorio si desea aprovechar al máximo la aplicación, pero opcional si desea ver la pantalla. Pero, ¿y si tuviera, por ejemplo, una impresora monocroma? ¿Cómo aclarar si su aplicación funciona con la restricción obvia de que algunas fotos podrían no verse tan bien? ¿O no imprimiré nada? Como otro ejemplo, ¿Cómo debo verificar la revisión de una impresora para verificar si la tinta es un requisito o un requisito opcional en una impresora multifunción? En otras palabras, ¿puedo seguir escaneando? Algunos consejos sobre terminología y qué buscar serían bienvenidos tanto como desarrollador / vendedor de productos como como consumidor.

Los llamaría "características opcionales", no requisitos opcionales. Los requisitos suenan como algo que debe tener , mientras que las características suenan como un complemento del producto original.