Al menos en los EE. UU., "voluntad" ha reemplazado a "deberá" en la mayoría de los contextos, con la notable excepción del "deberá legal". Shall se usa en lugar de will en documentos legales para indicar un sentido de obligación o requisito; por ejemplo, "el demandado deberá desalojar las instalaciones antes del 16 de octubre".
En el software, los documentos de requisitos y los documentos de especificación sirven casi para el mismo propósito que los documentos legales antes mencionados; ¿Significa esto que se debe usar de manera similar como resultado?
Opción 1: usar RFC 2119
Según RFC 2119 :
- DEBE Esta palabra, o los términos "REQUERIDO" o "DEBE", significan que la definición es un requisito absoluto de la especificación.
Este es también el uso más actual de la palabra "deberá" por lo que he visto en los requisitos.
Opción 2: usa el tiempo presente
Si los requisitos son en su mayoría obligatorios, también puede formular los requisitos en tiempo presente, sin "debe", "deberá" u otras palabras clave. Ejemplo:
El historial de deshacer se conserva cuando se cierra la aplicación.
El requisito establece claramente, por su tiempo presente, que el requisito es obligatorio. El historial debe conservarse y, de no ser así, el software no cumple este requisito.
Esta forma de escribir los requisitos les permite ser un poco más legibles, sin perder su propiedad obligatoria.
Opción 3: usa tus propias convenciones
Tenga en cuenta que puede definir su propia terminología en los documentos que escriba. Es por eso que la mayoría de la documentación comienza definiendo los términos, incluidos "debe", "puede", etc. Por ejemplo, la especificación HTTP contiene esta sección: 1.2 Requisitos .
Las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBE", "NO DEBE", "DEBE", "NO DEBE", "RECOMENDADO", "PUEDE" y "OPCIONAL" en este documento son debe interpretarse como se describe en RFC 2119 [34].
Una implementación no es compatible si no cumple con uno o más de los requisitos de nivel IMPRESCINDIBLE o REQUERIDO para los protocolos que implementa. Se dice que una implementación que satisface todos los requisitos de nivel DEBE o REQUERIDO y todos los requisitos de nivel DEBERÍA para sus protocolos es "cumple incondicionalmente"; uno que satisface todos los requisitos de nivel DEBE pero no todos los requisitos de nivel DEBERÍA para sus protocolos se dice que es "condicionalmente compatible".
Usar una convención que difiere mucho de la práctica generalmente aceptada sigue siendo una mala idea, y debe hacerse solo si tiene razones serias para hacerlo.
Shall todavía se usa en la documentación del software. Fue un tema de discusión en mi curso de ingeniería de software y también está presente en la documentación de campo.
Se puede encontrar un ejemplo en el estándar de codificación C++ de Joint Strike Fighter . En la sección 4.2 bajo Reglas en la página 11. Define específicamente lo siguiente:
4.2.1 Reglas de debería, voluntad y deberá
Hay tres tipos de reglas: debería , voluntad y reglas . Cada regla contiene un "debería" , "voluntad" o "deberá" en letras negritas que indican su tipo.
Debería reglas son reglas de asesoramiento. Sugieren fuertemente la forma recomendada de hacer las cosas.
Las reglas de testamento están destinadas a ser requisitos obligatorios. Se espera que se sigan, pero no requieren verificación. Están limitados a requisitos no críticos para la seguridad que no pueden verificarse fácilmente (p. ej., convenciones de nomenclatura).
Las reglas deben son requisitos obligatorios. Deben seguirse y requieren verificación (ya sea automática o manual).
Entonces, al menos, dentro de la última década para el trabajo por contrato del gobierno, tendrá mucha fuerza. Sospecho que sigue siendo muy similar en el sector privado, aunque quizás no sea tan estricto en el caso de proyectos que no involucren aviónica multimillonaria.
RFC 2119 define los significados de varias palabras utilizadas en las especificaciones (como otras RFC). Define DEBE como sinónimo de DEBE. Creo que es preferible usar MUST, ya que transmite el significado más claramente.
Antecedentes: hablo desde el punto de vista de aproximadamente treinta años de experiencia, casi todos en la industria de defensa (excepto dos años en telecomunicaciones, en Nortel Networks).
Definición: Un requisito es algo que debe verificar. Puede verificar mediante análisis, demostración, prueba, prueba matemática o alguna otra forma aprobada, pero debe verificar absolutamente que su producto cumpla con ese requisito. Si su producto no cumple con ese requisito, o si no ha PROBADO que su producto cumple con el requisito, no ha terminado.
En la industria de la defensa, al menos, una declaración en una especificación de requisitos se considera un requisito si y solo si utiliza la palabra "deberá". No hay excepción alguna a esta regla. Si decía "deberá", era un requisito, si no, no lo era. Período. Fin de oración, fin de párrafo, fin de capítulo, fin de libro.
Esto hace que sea MUY fácil decidir si una declaración particular en una especificación de requisitos es o no algo que debe probarse o verificarse de otra manera.
RFC2119 términos técnicos formalizados utilizados durante mucho tiempo para escribir RFC. En el momento en que se escribieron los RFC originales, mucho antes de que se escribiera el RFC2119, los redactores originales de RFC, que estaban muy familiarizados con las convenciones de especificación de la industria de defensa, se esforzaban mucho por evitar que pareciera que estaban escribiendo especificaciones de requisitos para la red en su conjunto. . El mismo nombre, "Solicitud de comentarios", fue elegido por esa razón específica, para evitar dictar a los otros investigadores. (Arrear gatos es mucho más fácil que arrear investigadores). Por lo tanto, evitaron cuidadosamente usar la palabra "deberá" y usaron "debe" en su lugar. La idea era la misma: si deseaba escribir, por ejemplo, un cliente Telnet y afirmar que se ajustaba a las RFC de Telnet, debía cumplir con las declaraciones "obligatorias".
Durante mi breve período en telecomunicaciones, tuve que leer RFC y tuve que leer y escribir especificaciones de requisitos que no son RFC. Todos los RFC usaban "debe" para denotar requisitos. Todas las especificaciones de requisitos usaron "deberán" para ese propósito.
Si estuviera en su lugar y escribiera especificaciones de requisitos que no son RFC, usaría "deberá" y solo "deberá" para denotar requisitos y solo requisitos, por las razones descritas anteriormente. De manera similar, si está escribiendo RFC, use el lenguaje RFC 2119 e incorpore RFC 2119 en su RFC como lo describió el otro tipo.
Varias buenas respuestas aquí, la respuesta corta es "sí", debe usar "deberá" en la documentación de requisitos técnicos. Como analista de requisitos técnicos y propietario del producto, puedo agregar una pieza que no veo en algunas de estas muy buenas respuestas.
En la metodología ágil de desarrollo de software, a menudo reemplazamos el lenguaje que suena legalista con un lenguaje que es más conversacional. Esto no significa de ninguna manera que los requisitos sean menos exactos o estrictos, solo que a menudo se expresan de manera algo diferente.
Por ejemplo: "El modal de la dirección aparecerá cuando el usuario active el botón de pedido" podría reemplazarse con una historia de usuario que suena más como esto: "Como usuario, necesito una forma de asegurarme de que el pedido se envíe a la dirección correcta para que que puedo asegurarme de que mi envío me llegue". El formato para esto es; Como X, necesito Y, de modo que Z. Esto realmente garantiza que se incluya una gran cantidad de información contextual en el elemento de trabajo que los desarrolladores seleccionan, que normalmente no se incluye en el lenguaje de requisitos de tipo de caso de uso clásico.
Usamos lo que llamamos "historias de usuarios", "épicas" y "temas" para elaborar requisitos en el desarrollo ágil. Se leen más como una historia (de ahí el nombre), por lo que generalmente no usa palabras como "deberá" (aunque en realidad he usado "deberá" en los requisitos de productos ágiles), pero debe asegurarse absolutamente de que estas historias de usuario, las epopeyas, etc., son tan específicas, comprobables y verificables como cualquier caso de uso clásico. Aunque es posible que no use "deberá" muy a menudo en los requisitos de software ágil, las cosas deben explicarse de tal manera que sean absolutamente explícitas y "deberá" bien podría haberse usado.
Si no está escribiendo requisitos para un proceso de desarrollo ágil, consulte las excelentes respuestas anteriores: los requisitos deben ser verificables, comprobables y definidos con precisión, o los proyectos de desarrollo de software se descarrilan muy rápidamente.
Con requisitos, deberá / no deberá. Nada más. "Deberá" es muy específico; es una palabra clave que puedo buscar. Must, must not, will, will not: Eso es para el texto explicativo. (Y no deberás en el texto explicativo. Eso anula hacer "deberá" un término de búsqueda).
Cómo no hacerlo: ayudé a escribir una propuesta hace mucho tiempo en la que la RFP tenía requisitos obligatorios, requisitos obligatorios, opciones obligatorias y opciones obligatorias. ¡Que desastre! Una propuesta viable tenía que cumplir con todos los requisitos de deber y las opciones de deber, y tenía que abordar todos los requisitos de deber ("no podemos hacer esto" era una forma de abordar esas cosas). Si las opciones fueran opcionales. El precio base ofrecido tenía que cubrir todos los requisitos (debería y debería); las opciones debían cotizarse por separado e individualmente. No ganamos; nadie lo hizo Alguien en lo alto eventualmente puso fin a esa intrincada RFP.
Con pruebas, debe y no debe pertenecer. Los criterios de prueba dicen cómo interpretar los resultados de la prueba: ¿Pasó o no pasó la prueba? Los criterios pueden ser lenguaje simple, un booleano, matemáticas, pero no deben. No hay razón para decir deberá. Que la prueba finalmente debe pasar está implícito.
El lenguaje "deberá" es universalmente aceptado, como lo atestigua la recomendación oficial de ISO (Organización Internacional de Normalización):
“shall” indicates a requirement “should” indicates a recommendation “may” is used to indicate that something is permitted “can” is used to indicate that something is possible, for example, that an organization or individual is able to do something
FUENTE: http://www.iso.org/iso/foreword
Los estándares ISO se producen en áreas internacionales y disciplinarias/comerciales, por lo que diría que este lenguaje es definitivamente un buen punto de partida, ¡y la mejor práctica es decir explícitamente qué términos usará y qué significan!
Ciertamente podría usar "deberá" de esta manera, y no sería algo malo , pero no espere que sus programadores noten la diferencia. Nunca vi este uso durante quince años de escribir código a partir de especificaciones formales, por lo que probablemente muchos otros programadores tampoco lo hayan visto. Si tiene un uso para la distinción, adelante, pero tenga cuidado de explicar lo que está haciendo.
Aunque la ISO puede estar a favor de mantener "deberá", estoy de acuerdo con PlainLanguage para este: https://plainlanguage.gov/guidelines/conversational/shall-and-must/
Use "debe" y no "deberá" para imponer requisitos. “Shall” es ambiguo y rara vez ocurre en las conversaciones cotidianas. La comunidad legal se está moviendo hacia una fuerte preferencia por “debe” como la forma más clara de expresar un requisito u obligación.
Favorezco debe para requisitos, debería para una recomendación, podría para una opción y voluntad para declaraciones de hecho.
Debemos adelantar nuestros relojes para el horario de verano. Debe planificar su horario de sueño para tener esto en cuenta . Podría mudarse a un estado que se quede con un esquema de tiempo todo el año. Independientemente, la tierra orbitará alrededor del sol como siempre lo ha hecho.
KMån