Hable pepinillo y aprenda a reunir los requisitos para su proyecto

La recopilación de requisitos para un proyecto es un proceso complicado. Si no lo hace bien, puede perder dinero y tiempo. Los clientes que comienzan a trabajar con empresas de desarrollo de software a menudo tienen problemas para especificar sus necesidades. Para evitar fallas de comunicación al iniciar un proyecto, sin importar si usted es un cliente o un contratista, ¡aprenda a reunir los requisitos!

Análisis de ingeniería de requisitos

Definición del problema comercial: este es el primer paso del Análisis de Ingeniería de Requisitos. En esta tarea, no debemos centrarnos en los detalles, sino pensar en el problema a nivel mundial. Aquí hay un ejemplo de un problema bien planteado:

"Cada vez es más difícil encontrar especialistas calificados para el sector de las TIC"

El segundo paso es crear una solución a este problema. Puede ser un servicio, un producto o incluso un proceso. A continuación, el ejemplo de una solución para el problema planteado anteriormente podría ser:

"Creación de la aplicación SkillHunt.io: una plataforma de reclutamiento que permite a sus usuarios obtener una alta recompensa por recomendar un trabajo a su amigo"

En esta etapa, los detalles son innecesarios. Si evaluamos la idea, realizamos una investigación de mercado y resulta que nuestra solución tiene una justificación comercial, podemos comenzar a recopilar los requisitos. Para asegurarnos de que cumplen su función, debemos verificar si cumplen con los 3 criterios principales. Necesitan ser:

  • Explícito y sin ambigüedades
  • Comprensible para todos los interesados,
  • Actualizado y documentado.

Para facilitar el proceso de recopilación de requisitos y cumplir con todos los criterios presentados, podemos utilizar el lenguaje Gherkin. Es un lenguaje natural que puede ser útil tanto para los analistas de negocios que recopilan los requisitos como para los desarrolladores que crean los escenarios para las pruebas funcionales.

Habla el pepinillo con fluidez

El registro de requisitos en Gherkin es inequívoco, explícito y, lo que es más importante, fácil de entender para todas las partes involucradas. Debido a eso, la discusión sobre los requisitos es realmente posible.

Al igual que cualquier otro idioma, Gherkin tiene su sintaxis. Tiene una estructura específica, algunas palabras clave tienen que aparecer. Así es como se ve:

Característica: Cerrar sesión de la aplicación
Guión:
   Dado que estoy conectado
   Cuando hago clic en el botón "cerrar sesión"
   Luego me informan sobre el cierre de sesión exitoso
   Y soy redirigido a la página de inicio de sesión

Los requisitos recopilados en Gherkin se guardan en un archivo .feature. Gracias a eso, los desarrolladores pueden usar fácilmente estos archivos para escribir pruebas automatizadas en BDD (desarrollo basado en el comportamiento) usando Cucumber.

Cuando queremos crear una nueva descripción de requisitos, necesitamos definir la Característica que nos da el nombre de una nueva funcionalidad. Luego, seguimos escribiendo el Escenario. Vale la pena mencionar que un archivo puede contener más de un escenario. Cada escenario consta de tres pasos principales: Dado, Cuándo y Luego. La descripción que sigue a la palabra Given establece las condiciones previas, When define las acciones que tienen lugar en la funcionalidad particular y luego describe el resultado esperado de la acción. En el ejemplo presentado anteriormente, hay una palabra clave más: Y que continúa el método que sigue. Por lo tanto, cuando se enumera después de Cuándo, continuaría esta sección y definiría otra acción. Gherkin conoce una palabra clave más: Pero, pero, para ser honesto, en toda mi carrera como Gerente de Proyecto, nunca encontré una situación en la que pudiera aplicarse.

Volverse fluido

Eche un vistazo al ejemplo en el que el usuario inicia sesión en cada uno de los escenarios:

Característica: Seleccionar perfil
Fondo:
   Dado que estoy conectado
Escenario: primer perfil seleccionado
   Dado que voy a la aplicación después de iniciar sesión
   Cuando me preguntan qué perfil me gustaría elegir de mi lista
   Y selecciono el perfil de la lista
   Luego veo el tablero de este perfil
Escenario: Siguiente perfil seleccionado
   Dado que estoy en el tablero
   Y he seleccionado el perfil
   Cuando selecciono del menú desplegable con la lista
   Entonces veo el tablero para esto

Además, si queremos analizar los requisitos y, en el futuro, probar más de un escenario, vale la pena usar algunos ejemplos, usando la función Ejemplo. La recopilación de datos en este formulario es a menudo la más inequívoca. Para usar Example, necesitamos poner la variable dentro de corchetes angulares <> y poner las tablas debajo del escenario. Debemos recordar que si usamos ejemplos, nuestros escenarios deberían llamarse Escenario de escenario. El siguiente ejemplo debería dejarlo claro:

Característica: Iniciar sesión en la aplicación
Fondo:
   Dado que soy usuario registrado
   Y mi cuenta está activada
Esquema del escenario: inicio de sesión exitoso
   Dado que estoy en la página de inicio de sesión
   Cuando completo "iniciar sesión" con 
   Y completo "contraseña" con 
   Y hago clic en el botón "Iniciar sesión"
   Luego me redirigen a la página con selección de perfil
Ejemplos:
   El | iniciar sesión | contraseña correcta |
   El | Lukasz Gh3rk1n |
   El | Arek | Cucumb3r |
Esquema del escenario: inicio de sesión fallido
   Dado que estoy en la página de inicio de sesión
   Cuando completo "iniciar sesión" con 
   Y completo "contraseña" con 
   Y haga clic en el botón "Iniciar sesión"
   Entonces me informarán sobre el inicio de sesión fallido
Ejemplos:
   El | iniciar sesión | contraseña incorrecta |
   El | Lukasz Pepinillo |
   El | Arek | Pepino |
Escenario: entrada no autorizada
   Dado que no estoy conectado
   Cuando intento ir a la página Panel
   Luego me redirigen a la página de inicio de sesión

Por supuesto, en proyectos ágiles, los requisitos están cambiando. Es necesario aplicar cambios en los archivos .feature y, por lo tanto, los cambios continuos en las pruebas de aplicación. De esta manera podemos mantener nuestra documentación actualizada. Completar las tareas de conformidad con los escenarios da como resultado la entrega y ejecución de elementos que se ajustan perfectamente a los principios de la gestión ágil.

___

Publicado originalmente por Łukasz Nowacki en neoteric.eu/blog el 20 de octubre de 2016.