¿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.
terminology
requirements
Aram Kocharyan
fuente
fuente
Respuestas:
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.
fuente
Nos referimos a ellos como características "agradables de tener" en lugar de requisitos.
fuente
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:
fuente
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).
fuente
Una mejor palabra para un requisito opcional es " Recomendación "
fuente
¿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á.
fuente
Los requisitos se clasifican en 4 áreas en Ingeniería de software:
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.
fuente
En la plantilla Volere se usa el término "sala de espera".
fuente
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.
fuente
Si sus requisitos tienen prioridad , puede considerarlos requisitos de baja prioridad .
fuente
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.
fuente
El término "Deseo" a veces se usa para requisitos opcionales. Sin embargo, puede no ser apropiado para un documento formal.
fuente
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.
fuente
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.
fuente