¿Por qué crea un documento de requisitos técnicos?
Rachel S. Smith, author of Writing a Requirements Document, explains that a technical requirement document, “Presents why a product is needed, puts the product in context, and describes what the finished product will be like.” For software projects, a technical requirements document generally refers to how the software will be built including the operating system it is being programmed for and other standards.
Si no crea un documento de requisitos técnicos, pueden aparecer problemas reales, según Smith. Estos problemas pueden incluir los siguientes:
- Construir un producto que no satisfaga una necesidad real.
- Desarrollar "corrupción de funciones".
- Tener un grupo en el equipo piensa que están construyendo una hormiga, mientras que otro grupo piensa que están construyendo un elefante.
Renee Fellman, a Portland, Oregon-based business expert who specializes in turning around businesses on the brink of failure, has found that failure to adequately document technical requirements can cause serious problems for a company that impact their bottom line.
Problems that arise from not having technical requirements documentation can range from simple to complex. “In one company I consulted for,” Fellman said, “Vital FDA compliance issues weren’t being addressed because human resources had failed to do something as simple as assign the duty of taking care of regulatory affairs.”
Guía para la gestión de proyectos
Su ventanilla única para todo tipo de gestión de proyectos
¿Está listo para sacar más provecho de sus esfuerzos de gestión de proyectos? Visite nuestra guía completa de gestión de proyectos para obtener consejos, prácticas recomendadas y recursos gratuitos para gestionar su trabajo de manera más efectiva.
El valor de los documentos de requisitos técnicos
Un documento de requisitos técnicos permite a su equipo llegar a un entendimiento mutuo de lo que se requiere, técnicamente, para que su proyecto o producto sea un éxito. Fuera de las 5 fases de la gestión de proyectos, se deben crear documentos de requisitos técnicos durante la fase 2 del ciclo de vida de su proyecto. Durante esta fase, se define el alcance de su proyecto y se establecen objetivos. Los documentos de requisitos técnicos también le proporcionarán información que le ayudará a:
- Determinar su presupuesto.
- Crear su cronograma de desglose del trabajo.
- Desarrollar el gráfico de Gantt del proyecto.
- Iniciar un plan de comunicación.
- Defina aspectos de la gestión de riesgos.
Expectativas de quienes preparan los documentos de requisitos técnicos
Cualquiera que prepare un documento de requisitos técnicos debe entender qué comprende un "buen" requisito del sistema y cómo comunicar esta información de forma clara.
- Tenga en cuenta los siguientes puntos:
- Sea creativo sobre las fuentes que elija explorar a medida que analice sus requisitos técnicos y utilice siempre la necesidad de su negocio como un punto de referencia básico
- Ayude a otros a entender sus resultados utilizando un lenguaje fácil de entender
- Utilice los prototipos para descubrir lo que falta
- Asegúrese de comprender las interrelaciones, las prioridades, el costo, la implementación y las consecuencias ambientales cuando decida qué incluir.
- Defina los límites del sistema
Otros tipos de documentos de requisitos que se encuentran comúnmente en el negocio
Al determinar su lista inicial de requisitos técnicos, tenga en cuenta que hay otros documentos que también preparan otros equipos dentro de su empresa. Estos documentos son sobre el mismo proyecto pero para diferentes audiencias. Es muy posible que algunos de estos documentos puedan contener información redundante. Puede sentir que algunos artículos pertenecen a su documento de requisitos técnicos y no al documento de requisitos comerciales o de mercado, pero no se preocupe, puede tenerlos en ambos. Debe crear un documento de requisitos técnicos que funcione mejor para sus propósitos. Asegúrese de recopilar la información más útil para usted.
Michael Shrivathsan, vicepresidente de Gestión de Productos de Accompa, es un experto en tipos de documentos de requisitos y sus funciones.
“There can be some overlap between business, market, and technical requirement documents,” said Shrivathsan. “Depending on the organization, they may or may not use all these document types. At large companies (1,000 employees plus), they typically do use all three of these docs. Most mid-sized companies (200 employees or more) use at least two of them.”
Puede haber información importante en estos otros informes que pueden informar, influir o crear contingencias con su documento de requisitos técnicos. A continuación, le mostramos algunos otros documentos que pueden crearse por otros departamentos para respaldar su proyecto:
Documentos de requisitos comerciales (BRD)
Escrito por: Gerentes de producto, Gerentes de marketing deproductos
Audiencia: Gerentes denegocios
Revisado y aprobado por: Ejecutivo de nivel C
Un documento de requisitos empresariales define primero el caso de negocios de alto nivel del proyecto y, por lo general, se prepara primero.
Un documento de requisitos empresariales define el objetivo del proyecto desde el punto de vista del negocio. La documentación para esta fase define los objetivos empresariales a un alto nivel. Los miembros de este equipo deben haberse reunido con los gerentes de negocios adecuados en su empresa o en la empresa de su cliente para recopilar la información empresarial requerida que se centre tanto en la necesidad de su negocio como de los clientes.
A partir del documento de requisitos empresariales, puede aprender la siguiente información que podría ayudarlo con su documento de requisitos técnicos:
- La naturaleza de las necesidades de sus clientes
- Cómo se alinean estas necesidades con la misión de su empresa
- Cómo su producto, sistema o software resolverá las necesidades de sus clientes a un alto nivel
- Se recomienda un retrato de la relación entre todas las partes interesadas del proyecto, mediante el flujo adecuado, los diagramas o gráficos organizativos para garantizar la claridad.
Documento de requisitos de mercado (MRD)
: Gerentes de productos, gerentes de marketing de productos
Audiencia: Los gerentes de negocios
revisados y aprobados por: El director-nivel
Un documento de requisitos de mercado agrega más información a la BRD, en términos de lo que necesita el mercado y identifica el panorama actual del mercado para productos o programas como el que está desarrollando. Saber algo sobre lo que ya está ahí, cómo se comercializa y a quién, puede ayudarlo a determinar las brechas en otras funciones del producto.
A partir del documento de requisitos de mercado, puede aprender la siguiente información que podría ayudarlo con su documento de requisitos técnicos:
- El tipo de producto que se planifica
- Clientes a los que se dirige
- Personas que definen:
- Características del cliente
- Los desafíos a los que se enfrentan
- Cómo su producto propuesto ayudará a afrontar estos desafíos
- Los productos que compiten entre sí y sus ventajas y desventajas
- Formas en las que su producto será mejor
Si nadie en su empresa está preparando los informes anteriores, es posible que tenga que hacer un trabajo adicional para obtener una imagen completa del universo en el que existirá su producto.
Los requisitos técnicos deben centrarse en los resultados deseados
Los requisitos técnicos de desarrollo de software incluyen componentes como la planificación de desarrollo, la arquitectura técnica, las pruebas de software y la implementación. Fellman aconseja que la buena documentación de requisitos técnicos empiece por centrarse en los resultados que desea y no centrarse en exceso en el proceso. ¿Por qué? Porque a dónde quieres ir determina todo sobre cómo vas a llegar allí. Por ejemplo, no iría en camello a la cima del Everest, pero podría montar en uno si tu objetivo final fuera llegar a una antigua tumba en el desierto egipcio.
Fellman advierte lo siguiente: "No hacer las preguntas correctas antes de comenzar a preparar el documento de requisitos técnicos puede conducir a un documento que en realidad no resuelve el problema que está buscando resolver".
Las preguntas, por supuesto, variarán dependiendo de sus clientes, su empresa y el servicio o producto previsto, pero para los documentos de requisitos técnicos, explore lo que desea que logre su nuevo sistema o software, especialmente desde el punto de vista del usuario. Es posible que quiera consultar a sus desarrolladores y preguntar, desde su punto de vista, qué es posible y qué no.
La lista de verificación de requisitos técnicos con plantillas son herramientas organizativas valiosas
El uso de una lista de verificación con plantillas, como la Lista de verificación de recopilación de requisitos de Smartsheet, puede permitirle mantenerse enfocado en los tipos de información que debe recopilar como parte de su análisis de requisitos técnicos.
Asegúrese de incluir lo siguiente:
- Requisitos funcionales y las tareas que realizará
- Impulsar las fechas en términos de hitos
- Requisitos físicos para un producto tangible, como el tamaño, el peso, el color, la forma, la textura y la solidez
- Detalles del entorno técnico
- Requisitos de datos
- Interfaces externas
- Compatibilidad/portabilidad
- Mantenimiento
Recopile información de diversos grupos
Smith sugiere información para este tipo de documentos que pueden provenir de una variedad de fuentes, incluidos los usuarios finales, los clientes, los desarrolladores y otras partes interesadas. La información se puede recopilar a través de entrevistas, encuestas, cuestionarios, investigación o incluso discusiones en mesas redondas entre los equipos y dentro de ellos.
Utilice el análisis de uso
Identifique los tipos de usuarios que usarán su producto y determinar sus patrones de uso. Esto le permitirá determinar los requisitos necesarios para el nivel de rendimiento que desee lograr.
Desarrolle casos de uso
Los modelos para las interacciones de los usuarios típicos deben incluirse en un documento de requisitos técnicos o en el documento de requisitos empresariales, utilizando diagramas de casos e informes de casos.
Explore las necesidades y los resultados deseados
Considere recopilar los siguientes tipos de información para su documento de requisitos técnicos:
1. Defina las expectativas y necesidades del usuario final, y cómo se utilizará el producto en el mundo real. Haga preguntas (a continuación, le mostramos algunas muestras):
- ¿Qué problema central resolverá su producto o software para su audiencia?
- ¿Qué quiere que logren las personas mientras usas su producto o software?
- ¿Cómo se hará la vida más fácil y productiva?
2. Defina la estructura y contingencias del equipo
- ¿Qué miembros del equipo son responsables de los aspectos del trabajo? (Recuerde el ejemplo anterior de Fellman y asegúrese de que se asignen todas las responsabilidades laborales importantes).
3. Defina el producto
- Usa maquetas, narrativas o listas.
- Requisitos de interfaz de estado claramente.
- Aclare los requisitos del cliente o del cliente especialmente si el producto o software está diseñado para la especificación de un cliente.
- Defina las etapas de desarrollo.
- Incluya pasos específicos para la finalización y cree un cronograma inicial que se pueda perfeccionar a medida que se descubren y deciden más detalles.
- Identifique contingencias explorando qué partes del proceso dependen unas de otras y por qué.
4. Crear un prototipo para ayudar a aclarar los resultados que los usuarios anticipan del nuevo producto o sistema cuando se complete
5. Defina todo el ciclo de vida del desarrollo de productos, incluidas las personas, el proceso, el desarrollo de software y tecnología, la gestión de cambios
6. Asegúrese de que cada requisito del sistema describa lo siguiente:
- La función relevante que realiza.
- Cualquier tipo de límites, en términos de diseño, restricciones o riesgos normativos o legales.
- Requisitos de diseño del entorno para la ubicación operativa, el uso o el almacenamiento.
Considere las cualidades del sistema
Considere las siguientes cualidades del sistema al describir la calidad de servicio que necesita para satisfacer sus requisitos empresariales y de usuario.
- Disponibilidad: Cuánto "tiempo de actividad" puede esperar que tenga su sistema en función de los recursos, servicios y accesibilidad de su sistema para los usuarios finales.
- Capacidad latente: Cómo lidiará su sistema con picos inesperados de uso independiente de más recursos.
- Rendimiento: Dadas las condiciones de carga específicas de una gama de usos, cuál será el tiempo de respuesta y la capacidad latente.
- Escalabilidad: La rapidez con la que se puede aumentar o disminuir la capacidad y el número de usuarios, sin cambios en la arquitectura original.
- Facilidad de servicio: ¿Qué tan fácil es monitorear, reparar y actualizar los componentes del sistema de hardware y software? Los factores a considerar incluyen la planificación del tiempo de inactividad, las oportunidades de mantenimiento basadas en patrones de uso, los tiempos críticos para la disponibilidad del servicio, los cronogramas para el diagnóstico y el monitoreo.
- Seguridad: ¿Qué tan seguro es el sistema, incluida la autorización y autenticación de usuarios e información durante la transferencia?
Valide y perfeccione sus requisitos técnicos
Una vez que haya definido sus requisitos técnicos, tómese el tiempo necesario para validarlos y perfeccionarlos. Smith dijo lo siguiente: "Observamos factores como cuántas partes interesadas solicitaron un requisito determinado, cuántos otros requisitos dependían de él, si haría que el sistema fuera más fácil de usar o realizaría una función que los usuarios no podrían hacer de otra manera, así como otras medidas cualitativas”.
Para Smith, validar los requisitos era un proceso para obtener tantas miradas como sea posible, escuchar los comentarios y debatir las implicaciones de mantener o rechazar un requisito determinado. "Realmente no hay un acceso directo. Se trata de involucrar a las partes interesadas clave y trabajar con ellas para comprender y resolver las diferencias de opinión".
Smith predice que nunca sabrá si ha capturado todos los requisitos necesarios. "Probablemente se reúna más de lo que necesita. Pero una vez que los tenga, priorícelos y trabaje en los requisitos de máxima prioridad que se ajusten a su tiempo y presupuesto. A veces los requisitos más importantes no son los más cruciales".
Mantenga informadas a las partes interesadas
Hoy en día, hay herramientas que ofrecen a las partes interesadas una visión directa del proceso de desarrollo, donde pueden seguir visualmente los avances, revisar (pero no editar) los requisitos a medida que se van aplicando y probar los primeros prototipos. "El desarrollo de software es algo tan complicado", dijo Smith. Las personas se entusiasman con las características antes de que se desarrollen, y pueden realmente decepcionarse si no se cumplen sus expectativas". Por lo tanto, mantener a las personas informadas y darles acceso temprano y actualizaciones periódicas de cualquier manera que funcione para ellos es clave para la satisfacción del usuario final una vez que se lanza el producto.
¿Agile Modeling es para usted?
Agile Modeling (AM) es otra forma de crear y documentar un modelo que se puede implementar en el desarrollo de sistemas y productos basados en software. Su alcance va más allá de la documentación de requisitos técnicos para incluir todo el proceso y combina las mejores prácticas basadas en los valores y principios más efectivos para crear el mejor software posible, dado el tiempo y el presupuesto.
Para obtener más información sobre Agile Modeling, a continuación le mostramos algunos libros recomendados:
- Entrega Agile disciplinada (DAD): Guía del profesional para la entrega de software Agile en la empresa por Scott W. Ambler y Mark Line, IBM Press, ISBN: 013281013
- El Objetivo Primer 3.ª Edición: Desarrollo basado en Agile Modeling con UML 2. Prensa de la Universidad de Massachusetts, 2004 nro. ISBN: 0-521-54018-6
- Introducción a la entrega Agile disciplinada: Un recorrido del equipo pequeño desde Scrum hasta la entrega continua por Mark Lines y Scott W. Ambler, Consorcio Agile disciplinado, ISBN: 978 149 754 4383
Plantillas de requisitos técnicos vs. Software
Las plantillas son fáciles de usar y el costo es adecuado, pero también hay alternativas. La empresa de Shrivathsan, Accompa, desarrolla un software de documentos de requisitos que gestiona los problemas que podrían surgir en función de la información redundante o malinterpretada.
Este software:
- Realiza un seguimiento de las dependencias entre estos tres tipos de documentos. Si cambia algo en el documento de requisitos empresariales, puede tener un efecto en cascada en el mercado y en los documentos de requisitos técnicos.
- Proporciona un repositorio para mantener toda la información para que pueda consumirse fácilmente (Shrivathsan mencionó que en la mayoría de las grandes empresas, esta información se puede fracturar en múltiples silos, lo que hace que sea muy difícil de encontrar y usar).
"Para cualquier proyecto, salvo los más pequeños, es casi imposible hacer un seguimiento manual de estas dependencias", afirma Shrivathsan. "Por eso se necesita una herramienta informática asequible".
Consejos para redactar el documento de requisitos técnicos
Redactar requisitos técnicos es un poco diferente a otros documentos de negocios estándar. Es un arte redactarlos para que los entiendan las personas que los van a utilizar para completar un proyecto o crear un nuevo tipo de software. Estos son algunos consejos que pueden permitirle redactar requisitos técnicos útiles:
- Utilice un lenguaje simple y sencillo para que todos tengan una comprensión común de lo que significa.
- Sea conciso. Empiece con un párrafo introductorio, seguido de los puntos de viñeta para aumentar la legibilidad.
- Mantenga la estructura de su oración simple para transmitir solo una idea principal a la vez.
- A veces una imagen vale más que 1000 palabras, especialmente si simplifica un concepto o muestra la relación de un concepto con otro.
Documentos de requisitos técnicos para instituciones educativas y empresas
Algunas instituciones educativas y negocios tienen páginas web en sus sitios dedicados a los requisitos técnicos básicos para hardware, software y navegadores. Si estos requisitos técnicos básicos no se cumplen, los alumnos, las profesores o los empleados no podrán acceder a la intranet. En caso de los alumnos esto significa que no pueden tomar clases en línea. En caso de las empresas, significa que los empleados pueden no poder hacer su trabajo.
La información generalmente incluye lo siguiente:
- Configuraciones mínimas para las plataformas Windows y Mac, como el procesador mínimo o la velocidad de CPU, la memoria mínima y el tipo de sistema operativo.
- Velocidad de conexión de red para el acceso a Internet
- Lista actual de navegadores compatibles, además de enlaces para descargarlos
- Lista actual de complementos del navegador, además de enlaces para descargarlos
- Información de acceso a Internet
- Cómo registrarse para obtener una cuenta de correo electrónico de una escuela o empresa
- Software requerido
Smartsheet plantillas transformen sus requisitos técnicos en una lista de verificación de trabajo para gestionar cualquier proyecto
Empodere a sus empleados para que vayan más allá gracias a una plataforma flexible, diseñada para satisfacer las necesidades de su equipo y capaz de adaptarse cuando esas necesidades cambien. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas claves y obtenga visibilidad en tiempo real acerca del trabajo en curso gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en el mismo tiempo. Pruebe Smartsheet gratis hoy mismo.