¿Mejor palabra para los requisitos opcionales? [cerrado]

12

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

    
pregunta Aram Kocharyan 25.03.2012 - 15:09

14 respuestas

13

Posiblemente se pueda usar el término "requisito fuera de alcance". Esto significa que el requisito ha sido capturado dentro de su proceso y es rastreable, pero se ha determinado que el requisito es algo que cae más allá del alcance actual del sistema, debido a varias razones, como el presupuesto, el cronograma, el tiempo, o viabilidad.

Sin embargo, la frase "requisito opcional" se usa comúnmente para denotar algo que está dentro del alcance, pero que no es 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 cualquier cosa considerada 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.

    
respondido por el Thomas Owens 25.03.2012 - 15:14
25

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

    
respondido por el Morons 25.03.2012 - 15:38
11

Para la documentación de requisitos de software, el texto Requisitos opcionales está perfectamente bien, siempre que utilice este término en conformidad con RFC 2119 Palabras clave para indicar niveles de requisitos - es decir, para indicar elementos que son verdaderamente opcionales.

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

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

    Network Working Group                                         S. Bradner
    Request for Comments: 2119                            Harvard University
    BCP: 14                                                       March 1997
    Category: Best Current Practice


            Key words for use in RFCs to Indicate Requirement Levels

    Status of this Memo

       This document specifies an Internet Best Current Practices for the
       Internet Community, and requests discussion and suggestions for
       improvements.  Distribution of this memo is unlimited.

    Abstract

       In many standards track documents several words are used to signify
       the requirements in the specification.  These words are often
       capitalized.  This document defines these words as they should be
       interpreted in IETF documents.  Authors who follow these guidelines
       should incorporate this phrase near the beginning of their document:

          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
          NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
          "OPTIONAL" in this document are to be interpreted as described in
          RFC 2119.

       Note that the force of these words is modified by the requirement
       level of the document in which they are used.

    1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
       definition is an absolute requirement of the specification.

    2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
       definition is an absolute prohibition of the specification.

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

    4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
       there may exist valid reasons in particular circumstances when the
       particular behavior is acceptable or even useful, but the full
       implications should be understood and the case carefully weighed
       before implementing any behavior described with this label.

    5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item because a
       particular marketplace requires it or because the vendor feels that
       it enhances the product while another vendor may omit the same item.
       An implementation which does not include a particular option MUST be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In the
       same vein an implementation which does include a particular option
       MUST be prepared to interoperate with another implementation which
       does not include the option (except, of course, for the feature the
       option provides.)

    6. Guidance in the use of these Imperatives

       Imperatives of the type defined in this memo must be used with care
       and sparingly.  In particular, they MUST only be used where it is
       actually required for interoperation or to limit behavior which has
       potential for causing harm (e.g., limiting retransmissions)  For
       example, they must not be used to try to impose a particular method
       on implementors where the method is not required for interoperability.

    7. Security Considerations

       These terms are frequently used to specify behavior with security
       implications.  The effects on security of not implementing a MUST or
       SHOULD, or doing something the specification says MUST NOT or SHOULD
       NOT be done may be very subtle. Document authors should take the time
       to elaborate the security implications of not following
       recommendations or requirements as most implementors will not have
       had the benefit of the experience and discussion that produced the
       specification.

    8. Acknowledgments

       The definitions of these terms are an amalgam of definitions taken
       from a number of RFCs.  In addition, suggestions have been
       incorporated from a number of people including Robert Ullmann, Thomas
       Narten, Neal McBurnett, and Robert Elz.

No dolería si su documentación se refiere a RFC como la fuente de definiciones:

  

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

    
respondido por el gnat 25.03.2012 - 20:06
7

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 de MoSCoW (debe tener, debería tener, podría tener, no tendrá este tiempo) para La categorización de 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 argumentos estallan sobre los requisitos opcionales pero críticos).

    
respondido por el PaulHurleyuk 25.03.2012 - 21:20
4

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

    
respondido por el Michael Durrant 25.03.2012 - 18:17
2

¿Qué hay de identificarlo como una característica opcional o tareas opcionales? Esto solo se hará si en un determinado momento del proyecto se ha determinado que hay tiempo y dinero disponible 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 estar listas ...

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

    
respondido por el mhoran_psprep 25.03.2012 - 15:40
1

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

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

ahora pueden ser Opcionales o Obligatorios , según las 4 categorías anteriores, que he descrito anteriormente. Los requisitos opcionales también pueden caer en el alcance del sistema en consideración o fuera de su alcance también. Los requisitos opcionales son buenos medios para evitar Scope Creep y definir su alcance en términos precisos.

Los requisitos opcionales siempre formará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 de la dispersión. Nunca se puede decir que contradigan las prácticas de ingeniería de SDLC. Sin embargo, los requisitos deben ser priorizados y bien definidos.

    
respondido por el Maxood 25.03.2012 - 15:29
1

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

  

... Esta plantilla está diseñada para usarse como base para las especificaciones de sus requisitos. La plantilla proporciona cada uno de los tipos de requisitos adecuados para los sistemas empresariales, 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 de Volere se describen en el libro Dominar el proceso de requisitos por Suzanne Robertson y James Robertson ...

    
respondido por el Danny Varod 25.03.2012 - 17:57
0

En mi negocio (naves espaciales), se les llama "objetivos", lo que indica que están documentados y que 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ás), lo que indica que alguien los quiere y están tratando de alcanzar el estado de objetivos pero aún no están aceptados ni documentados; o "requisitos de arrastramiento", 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 comprometen o amenazan con cumplir los requisitos reales.

    
respondido por el Mark Adler 25.03.2012 - 20:25
0

Si sus requisitos son prioridad , puede considerarlos como requisitos de baja prioridad .

    
respondido por el calum_b 26.03.2012 - 17:51
0

Me sorprende bastante 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 "shall". A veces se incluyen en Braces cuando se habla de números. p.ej. El sistema funcionará continuamente sin necesidad de atención del operador durante 100 {250} horas. Lo que significa que el requisito que se debe cumplir es de 100 horas, pero el objetivo es de 250 horas.

Como nota al margen, muy pocas veces alguien diseña para cumplir el requisito objetivo, a menos que exista algún tipo de incentivo.

    
respondido por el Dunk 27.03.2012 - 00:29
0

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

    
respondido por el Craig Schwarze 27.03.2012 - 01:40
0

Me sorprende que todas las respuestas estén relacionadas con los requisitos de seguimiento en el desarrollo del proyecto. A pesar de ser un desarrollador, nunca me preocupé demasiado por esta terminología en ese contexto. Cuando leí por primera vez la pregunta, asumí que estaba relacionada con las especificaciones del producto del usuario, no con el desarrollo del producto. Por ejemplo, una enciclopedia podría enumerar una impresora a color como un requisito opcional. Se requiere si desea el beneficio completo de la aplicación, pero es opcional si desea ver la pantalla. Pero ¿y si tuvieras, por ejemplo, una impresora monocromática? ¿Cómo aclarar si su aplicación funciona con la obvia restricción de que algunas fotos no se verán tan bien? ¿O no puedo imprimir en absoluto? Como otro ejemplo, ¿cómo debo verificar una revisión de la impresora para verificar si la tinta es un requisito o un requisito opcional en una impresora multifunción? En otras palabras, ¿todavía puedo escanear? Algunos consejos sobre terminología y qué buscar serían bienvenidos tanto como desarrollador / vendedor de productos como consumidor.

    
respondido por el g1cmz 12.04.2012 - 18:40
0

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

    
respondido por el Billjk 12.04.2012 - 19:47

Lea otras preguntas en las etiquetas