¿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.
¿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.
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.
Nos referimos a ellos como características "agradables de tener" en lugar de requisitos.
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 .
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).
Una palabra mejor 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 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.
Los requisitos se clasifican en 4 áreas en Ingeniería de Software:
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.
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 ...
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.
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.
El término "Desirement" 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 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.
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.
Lea otras preguntas en las etiquetas requirements terminology