documentation - ¿Por qué los requisitos del software siempre se expresan con "shall" en lugar de "will"?
requirements (14)
"Will" simplemente indica intención. Usted podría decir: "Voy a arreglar este error" (tiene la intención)
"Deberá" indica obligación. Tu jefe podría decir "Arreglarás este error" (es un pedido)
Consulte http://en.wiktionary.org/wiki/shall y http://en.wiktionary.org/wiki/will
¿Por qué es cuando estoy documentando los requisitos, siempre tiene que ser expresado como "HARÁ esto ..." vs. "HARÁ esto ...".
Sé que esta es una pregunta extraña, pero a la que nunca he podido encontrar una respuesta. Siempre ha sido así, "así es como los escribes". Sé que es una pregunta tonta, pero que siempre me ha dejado perplejo.
Ayuda adicional para nosotros hablantes de inglés no nativos:
"will" y "shall", a primera vista, no nos importan mucho, porque no se usan a diario en el inglés que escuchamos o leemos. Por otro lado, "would" y "should" son más comunes, y su diferenciación es más familiar, por lo que podría vincular "will" y "would", "shall" y "should" (y luego "can" y "should" podría ", si no ya" de alguna manera en tu mente.
@Brent Longborough: gracias por el ejemplo que dio y su explicación. Debería haber una forma de trasplantar tal conocimiento básico.
Básicamente, RFC 2119 lo dice. La verdadera respuesta es que el inglés es impreciso a menos que usted exprese muy específicamente lo que quiere decir con más palabras de las que a las personas les importa leer, y alguien se tomó el tiempo de decir exactamente qué significan ciertas palabras.
En el Código Eléctrico Nacional </ nonprogramming> </ formerlife>, usan "Shall" para indicar un tipo de importancia, la falta de una opción o alternativa. Deberás hacerlo de esta manera, no hay otra forma de hacerlo, si no lo haces de la manera que dijimos aquí, entonces te equivocaste. Suplementará todo lo demás (generalmente incluso las "excepciones"). Al igual que alguien más dijo, proviene de un fondo legal.
"can", "may" se utilizan para indicar que tiene una opción en el asunto, "shall" significa que no tiene voz; así es como se DEBEN HACER. ;)
Es porque siempre estamos 90% Hecho y esa característica no está allí todavía;)
Redacted comentarios anteriores - Estaba ladrando el árbol equivocado :)
Gramática inglesa. Para la segunda y tercera persona, la voluntad es declarativa mientras que es imperativa , mientras que la primera persona es al revés.
El ejemplo clásico:
Luchando en el agua: "¡Nadie me salvará! ¡Me ahogaré!"
Suicidio: "¡Nadie me salvará! ¡Me ahogaré!"
Supongo que porque los orígenes del requisito de software y los documentos de especificación son legales (es decir, para detallar explícitamente las expectativas de un contrato de desarrollo) y como tales han heredado algunas de las convenciones legales como "deberá" en lugar de "voluntad".
a. La palabra "deberá" en el texto se usa para indicar un elemento obligatorio de la especificación.
segundo. La palabra "debería" en el texto se usa para indicar un elemento deseable pero no obligatorio de la especificación.
do. La palabra ''voluntad'' en el texto se usa para indicar una expresión de intención futura pero no un elemento obligatorio de la especificación.
re. La palabra "debe" en el texto expresa una suposición, el cumplimiento de la cual está fuera del alcance de este documento.
mi. La palabra "puede" en el texto expresa una práctica o acción permisible. No expresa un requisito de la especificación.
F. El uso del tiempo presente (por ejemplo, es, es) indica que el enunciado asociado es un material explicativo provisto en apoyo de la especificación.
¿El uso es más exclusivamente instructivo, declarando lo que debería ser?
Will se puede usar en lugar de shall, pero también se usa comúnmente para describir lo que realmente ocurre / se observa bajo ciertas condiciones (y el comportamiento esperado puede o no ser lo que debería ocurrir en relación con una especificación o ideal dado).
- "Will" anuncia el futuro, o al menos cómo usted pretende que sea
- "Deberá" dicta lo que debe hacerse
Esta es la razón por la cual las especificaciones usan "deberá", mientras que las buenas resoluciones y horóscopos de año nuevo usan "voluntad".
He estado usando "shall" en lugar de "will" para los requisitos, pero me pidieron que cambiara "should" por "will".
Tal vez estaba pensando en las cosas que podrían salir mal cuando indiqué en un documento de requisitos que "debería aparecer la siguiente pantalla". Mi jefe pensó que sonaba débil y me pidió que lo cambiara a "aparecerá la próxima pantalla".
Esta puede ser una respuesta extraña, pero ... Creo que no hay ninguna buena razón práctica para usar "shall", "should", "may" y otros verbos modales en documentos de requisitos. Todos esos verbos solo hacen que los documentos sean más difíciles de escribir y, lo más importante, mucho más difíciles de leer. (Y estoy convencido de que la mala legibilidad es una de las principales razones por las cuales los documentos de requisitos a menudo no definen claramente qué se supone que debe hacer el sistema de software para sus partes interesadas).
¿Por qué el uso de "debe" es tan común?
Bueno, como se mencionó en otras respuestas aquí, una posible razón es que esta práctica simplemente se toma prestada de documentos legales. Obviamente, los requisitos sí representan un contrato con un cliente, por lo que puede parecer natural expresarlos como otros documentos contractuales, es decir, en términos legales. Bueno, todos sabemos cómo a la gente le encanta leer jerga legal. :-)
Además, a algunas personas les resulta útil aplicar "convenciones must / should / may" definidas en RFC 2119 a los requisitos del software. ¿Por qué? Francamente, me gana. En mi humilde opinión, es un ejemplo clásico de mal uso de una buena idea. Esas convenciones pueden ser útiles cuando se definen protocolos muy técnicos, interfaces u otras normas que permiten diferentes niveles de cumplimiento . Pero incluso en esos casos, creo que no es la forma más eficiente de lograr el objetivo. Estoy seguro de que sería mucho más fácil para todos si, en lugar de rociar la prosa con TODOS los MAYORES, SHOULD y MAYS capitalizados, los autores demarcan claramente cada requisito y le proporcionan un atributo OBLIGATORIO | RECOMENDADO | OPCIONAL.
Creo que los requisitos del software no se escribirán en jerga legal (a menos que tenga algún cliente extraño que lo requiera). Creo que cualquier declaración de requisito es más fácil de escribir y leer (y mantener) en tiempo presente y voz activa. También creo que el "nivel de opcionalidad" no es un buen atributo intrínseco para un requisito de software. Cada requisito debe tener una prioridad como su atributo intrínseco (que, por ejemplo, ayudaría a decidir si la implementación de un requisito determinado es obligatoria, recomendada u opcional para un lanzamiento dado ).
Usted tiene la respuesta canónica, pero el documento "cómo escribir los requisitos" en el trabajo ofrece una toma más:
"shall" describe un requisito, es decir, algo que su software necesita para que suceda
"will" describe un hecho, es decir, algo que sucederá ya sea que su software lo haga o no
Evite toda la pregunta y los requisitos de captura con casos de uso.
Si vas a usar listas de requisitos, estoy de acuerdo con Yarik. Escriba la voz activa y comience la declaración de requisitos con un verbo o sustantivo.