requisitos funcionales: ¿utilizar palabras basadas en verbos?

Pregunta

¿Deberían los requisitos funcionales en un documento de requisitos utilizar una redacción basada en verbos?

Contexto

Asignación de escuela, trabajando en equipo, trabajando a través del SDLC. El documento de requisitos se ha realizado y ahora estamos en el diseño.

Problema

El documento de requisitos tiene una lista enumerada de lo que yo llamaría características de la aplicación: los requisitos funcionales. En esa lista hay cosas que pensaría como "cómo" en lugar de "qué" y ahora, al tratar de trabajar en el diseño, siento que una parte del diseño ha sido dictada prematuramente.

¡No he hecho esto antes! Para mí, debería tratar estrictamente con cosas que describen "qué".

Ejemplo de corriente

Finge que el trabajo es hacer una tortilla. Listado: romper el huevo, romper en un tazón, revolver, etc .; cruza la línea hacia el territorio de cómo. A lo largo de esa pista, también lo hace la redacción como: crear, generar, enumerar, calcular, determinar, validar, etc. - verbos, básicamente. En este momento, tengo una lista de requisitos que están parcialmente enraizados en verbos.

Mi idea de un documento de requisitos para una tortilla sería más como: tiene dos huevos, x onzas de jamón, x onzas de tocino, x onzas de queso montery-jack, x onzas de cilantro, etc., nada más que (sustantivos) .

Podría haber hablado y podría haber hablado antes de finalizar el documento de requisitos si hubiera tenido alguna experiencia.

Puede y debe usar verbos en sus requisitos. Lo importante es asegurarse de que cada requisito sea:

• Sin ambigüedades : cada requisito solo puede significar una cosa y solo puede interpretarse de una manera.
• Atómico : cada requisito no puede desglosarse en múltiples requisitos.
• Verificable : se puede demostrar que cada requisito se ha cumplido o no mediante alguna forma de prueba.

Se sorprenderá de lo buenos que resultan sus requisitos simplemente siguiendo estas tres pautas a toda costa.

Además, asegúrese de escribir una justificación para cada requisito. Esto es muy importante y útil en el futuro cuando alguien se pregunta por qué se creó un requisito particular.

Y sí, tiene razón, los requisitos deben describir QUÉ hará el software, no CÓMO lo hará.

"¿Deberían los requisitos funcionales en un documento de requisitos utilizar una redacción basada en verbos?"

La respuesta corta es "sí", pero el camino para llegar allí es sinuoso.

Si el documento de requisitos es una colección de declaraciones "deberá" escritas como oraciones en inglés, debe tener una frase verbal. Y esa frase verbal será "deberá xxx" como en "el sistema deberá xxx". La parte "xxx" es uno de los tres tipos de verbos, "be", "do" y "have". Estas oraciones deben describir el sistema como una caja negra, solo registrando aquellas cosas que se pueden ver desde afuera. Como dijiste, "el qué más que el cómo". Si es visible desde el exterior, es un "qué".

La única función posible que está disponible para un sistema digital es cambiar el valor de una variable. Por lo tanto, todos los requisitos funcionales deben indicar qué variable se modifica y los cálculos que se utilizan para realizar el cambio. Estos son los requisitos de "hacer".

Los requisitos de "ser" tienden a describir características en lugar de funciones. "El sistema podrá ...". Describen un "estado del ser".

Los requisitos de "tener" son los sustantivos de los que habló. "El sistema tendrá ..." Proporcionan los sustantivos para las oraciones de requisitos funcionales.

En un nivel alto hay muy pocos requisitos funcionales. La mayoría de los requisitos son requisitos de características, requisitos de rendimiento o requisitos de composición (tener).

Todos los requisitos de alto nivel que necesitan niños son, por definición, ambiguos. Si no fueran ambiguos, no necesitarían niños para definirlos. Además, un requisito solo es inequívoco si la mayoría de las personas en una revisión de requisitos declaran que sí. Es decir, la ambigüedad es subjetiva. La definición más cercana para un requisito FUNCIONAL inequívoco que conozco está en BarBaraBea.com en la página "Requisitos funcionales inequívocos". Básicamente se dice que todos los sustantivos en un requisito funcional deben derivarse de las entradas del sistema a través de una cadena de requisitos funcionales inequívocos, y que la declaración del cálculo en el requisito debe describir un algoritmo. La definición de "algoritmo" es mucho menos subjetiva que la definición de "requisito inequívoco".

... Finge que el trabajo es hacer una tortilla. Listado: romper el huevo, romper en un tazón, revolver, etc .; cruza la línea hacia el territorio de cómo ...
...
Mi idea de un documento de requisitos para una tortilla sería más como: tiene dos huevos, x onzas de jamón, x onzas de tocino, x onzas de queso montery-jack , x onzas de cilantro, etc. - nada más que (sustantivos) ...

Bueno, para la tortilla, preferiría los requisitos de la primera versión a la segunda, simplemente porque la segunda versión me pone en riesgo de obtener dos huevos, x onzas de jamón, etc., nada más que eso, ni frito ni revuelto.

La segunda versión garantiza obtener lo que necesito, pero también apesta, solo porque la única forma de asegurarse de que se cumplan los requisitos parece ser permanecer en la cocina observando de cerca cada uno de los pasos para preparar una comida.

Verá, preferiría requisitos que de alguna manera me permitieran probar / verificar el resultado sin tener que ver cómo prepara la comida.

Una forma de lograrlo sería especificar los requisitos para pasar la comparación con la referencia. Usando un ejemplo de tortilla, haría mi propia tortilla de "referencia" siguiendo las mismas instrucciones que usted, y luego compararía la suya por estar lo suficientemente cerca de ella.

• ^{Utilicé ese enfoque cuando necesitaba probar una versión altamente optimizada de un algoritmo particular. La "tortilla de referencia" en este caso se presentó mediante un algoritmo simplificado y no optimizado. Ejecuté la misma entrada con dos tipos de algoritmo y luego verifiqué si la salida producida por la versión optimizada estaba lo suficientemente cerca de la referencia.}

Otra forma sería establecer requisitos para que estos describan el resultado. Para tortilla que sería como "4 onzas de huevos revueltos y fritos, etc.". Me ocupé principalmente de este tipo de requisitos, creo que esta es la forma más típica.

• ^{En aras de la exhaustividad, probablemente tenga que describir otro tipo de requisitos específicos con los que me he ocupado, basado en pruebas. No puedo imaginar una forma que no suene aburrida para el ejemplo de la tortilla, algo así como "cuando un experto la mira y la prueba, dicen que está bien", pero tengo que admitir, en el único caso que he visto que se usa para software , tampoco se sentía particularmente inteligente.}

Un programa funcional está compuesto de funciones. ¿Qué son las funciones? Son métodos que realizan acciones. ¿Qué son las palabras de acción? Verbos

Si estuvieras haciendo programación orientada a objetos, entonces estarías trabajando con sustantivos. En realidad, estarías trabajando con sustantivos y verbos.

Estilo funcional:

crack(egg)

Estilo orientado a objetos:

egg.Crack();

A nivel de requisitos, no estoy seguro de que nada de esto importe, aunque sin duda sería útil que los requisitos se establecieran en forma de acciones, ya que las funciones son lo que usted escribirá.

Todos los requisitos se pueden reducir esencialmente a una colección de declaraciones que giran en torno al uso de verbos. Sí, puede agregar algunos sustantivos y adjetivos, pero son los verbos los que describen cómo se comporta un sistema y qué es lo que el cliente quiere que haga el software. Incluso se puede pensar en gran parte de la funcionalidad específica del estado de un programa en términos de comportamientos cuando se presenta el estado a través de métodos getter y setter.

Es justo como CFL_Jeff menciona en su respuesta , que desea que sus requisitos describan lo que hará un sistema, y ​​no describir cómo se debe hacer. Esta es posiblemente la razón por la que encuentro el desarrollo impulsado por el comportamiento tan convincente, porque alienta el uso de verbos que describen los requisitos y el uso de verbos al escribir pruebas unitarias para describir los requisitos como comportamientos a ser probados.

Considere por un momento los siguientes requisitos y plantillas de escenarios:

• As an {actor} I want to {do something} in order to {achieve an outcome}
• Given {an initial context} When {something is done} Then {expect an outcome}

En BDD, las características son siempre el bit descrito en la sección "Quiero" de la plantilla, y siempre están cargadas de verbos que describen lo que hace la característica. Cuando se prueba, Given-When-Thense usa una plantilla para validar escenarios específicos relacionados con la característica, y una vez más la sección "Cuándo" de la plantilla siempre se define por los verbos utilizados, que se relacionan de alguna manera con los verbos utilizados en la especificación de la característica.

Usando su ejemplo de omelete, definir una serie de comportamientos como una serie tiene mucho sentido. Tiene una colección de comportamientos y resultados, y como una serie forman un flujo de trabajo. Si en su lugar definiera una lista de ingredientes, está describiendo la arquitectura de manera muy flexible, sin embargo, le quedan muchas preguntas. ¿Cuál es el flujo de trabajo? ¿Cómo se usan los ingredientes? Básicamente te estás perdiendo el "pegamento" que guiará tus decisiones sobre cómo armar tu sistema y cómo se supone que debe comportarse.

Al definir los requisitos en términos de comportamientos y resultados, puede proporcionar una imagen muy clara de lo que quiere que logre el software, sin preocuparse de cómo lograr específicamente dichos resultados en el software.