El Documento de Requisitos Técnicos (TOR) es uno de los aspectos más complicados en la relación entre el cliente y el equipo técnico. Este es un problema que existe desde siempre: los clientes no saben cómo redactarlo y los desarrolladores no pueden trabajar sin él.
¿Por qué sucede esto? Primero entendamos qué es el TOR. En esencia, es un documento técnico que describe todos los requisitos de un producto. El problema es que, la mayoría de las veces, el desarrollador y el cliente hablan idiomas diferentes, por lo que, para uno, el TOR del otro parece un texto en chino. El cliente piensa en términos de negocio; necesita un sitio web que venda. Para los desarrolladores, el concepto de “sitio web que venda” no sirve: necesitan instrucciones claras sobre qué elementos debe incluir el producto para ser efectivo.
De manera similar, al renovar un apartamento, explicas a los trabajadores en detalle cómo debe ser el diseño del azulejo en el baño, cuántos enchufes habrá en la sala, la altura de los techos y la marca de las ventanas. Si llegas con una solicitud de hacer una renovación “con estilo”, lo más probable es que al final te encuentres con que tu idea de estilo no coincide con la del equipo de construcción.
Cómo redactar un Documento de Requisitos Técnicos (TOR)
De hecho, no existe una forma universal de redactar el Documento de Requisitos. Por ejemplo, nosotros utilizamos un método interactivo, en el cual primero creamos prototipos con comentarios y luego redactamos el TOR basándonos en ellos. Este enfoque es conveniente para garantizar la claridad y facilitar la comunicación con el cliente. Así es como se ve este proceso:
La estructura del Documento de Requisitos Técnicos (TOR)
-
Descripción del proyecto y la empresa: tareas que el producto está diseñado para resolver, valores y requisitos del cliente, identidad corporativa, propuesta única de venta (USP) y público objetivo; todo lo que ayude al equipo de desarrollo a estar en el mismo contexto que el cliente y crear los primeros prototipos.
-
Prototipos: los primeros bocetos visuales del servicio futuro, que permiten demostrar visualmente su estructura.
-
Stack tecnológico: lenguaje de programación, framework, requisitos de hosting, entre otros.
-
Estructura propuesta del servicio: Por ejemplo, en el TOR para desarrollar una aplicación para aprender inglés, el cliente quiere ver una secuencia de secciones con teoría y práctica, un diccionario, una cuenta personal con configuraciones y una página principal donde se pueda seleccionar la lección deseada. Esta estructura puede presentarse en formato de descripción o de diagrama.
-
Requisitos funcionales para cada página o pantalla: una descripción de lo que debe suceder en la pantalla. Retomando el ejemplo de la aplicación para aprender inglés, en la pantalla de práctica aparecerá una pregunta y tres posibles respuestas. Al seleccionar una, se resaltará la opción correcta y luego la pantalla cambiará automáticamente a la siguiente pregunta.
-
Escenarios de usuario: qué sucede, por ejemplo, en caso de una suscripción paga o gratuita. O cómo el usuario puede obtener información sobre una regla específica del idioma a través de la aplicación. Contenido: imágenes, textos, videos, archivos de audio para entrenar pronunciación y más.
-
Prototipos finales: Después de crear el TOR y que el cliente lo apruebe, corregimos nuestros prototipos y los discutimos con el cliente.
¿Quién debe participar en el desarrollo del TOR?
Si el cliente necesita un sitio de información sencillo con un formulario de contacto, puede redactar los Requisitos Técnicos (TOR) por su cuenta. Pero para un producto complejo con funcionalidades avanzadas, siempre es mejor componer el TOR junto con los desarrolladores. De esta manera, será posible alinear las necesidades del negocio con los requisitos técnicos.
Y, por cierto, un proyecto que el cliente considera simple puede estar lleno de muchos obstáculos inesperados. Por lo tanto, antes de crear los Requisitos Técnicos, siempre es mejor consultar con el equipo técnico. Por ejemplo, con nosotros ;)