Plantillas gratuitas de especificación funcional: Hoja de ruta para una experiencia de desarrollo más fluida

Agile se centra en encontrar la forma más eficiente de entregar un producto útil a un usuario. En el desarrollo de Agile, los documentos y procesos de requisitos funcionales tradicionales a veces se consideran prohibitivos en términos financieros. Sin embargo, capturar planes y bocetos más detallados puede mejorar la claridad.

Una de las herramientas de requisitos ágiles más comunes es la historia de usuario. Las historias del usuario ponen las funciones en el contexto de lo que el usuario necesita lograr. Puede agrupar historias de usuario similares para formar épicas de Agile. Al igual que con las especificaciones de requisitos funcionales tradicionales, las historias de usuario describen la tarea o la función, pero no cómo deben implementarla los desarrolladores.

Las historias de usuario emplean la siguiente sintaxis: “Como usuario, quiero tener algo para obtener algunos beneficios”. A continuación, se mencionan algunos ejemplos:

• Como conductor, quiero saber cuándo debe reemplazarse mi batería.
• Como cocinero, quiero que la pantalla de una tableta se mantenga activa mientras completo una receta.
• Como gato, quiero que mi porción de comida caiga en mi tazón todas las tardes a las 4 p. m.

Para probar si una historia de usuario está bien formada, aplique el acrónimo INVEST.

• Independiente (Independent): ¿La historia puede sostenerse por sí sola?
• Negociable (Negotiable): ¿Puede cambiar o eliminar esta historia sin afectar el resto del proyecto?
• Valiosa (Valuable): ¿Esta historia tiene valor para el usuario final?
• Estimable (Estimable): ¿Puedes estimar el tamaño de la historia?
• Pequeña (Small): ¿La historia de usuario es lo suficientemente pequeña?
• Comprobable (Testable): ¿Puede probar esta historia?

Con fines de gestión de proyectos, en la herramienta de seguimiento, puede darle a las historias de usuario un nombre y un número de identificación. Además, puede marcar la prioridad de desarrollo, el sprint y el estado de la historia. Las historias entran en el backlog del producto Agile.

Las plantillas de historia de usuario suelen ser bastante simples: Se centran en identificar el rol del usuario, su tarea y lo que la tarea debe cumplir. Además, la siguiente plantilla incluye espacio para identificar la historia y la información del ciclo de desarrollo.

Descargar plantillas de historias de usuario simples de Agile

Excel | Word

La planificación de un sitio web requiere una comprensión de alto nivel de la tecnología necesaria y una comprensión detallada de quién utilizará el sitio y lo que usted (como propietario del sitio) desea que logren los usuarios. Las historias de usuario empleadas en el desarrollo ágil pueden ayudarle a centrarse en las necesidades de los usuarios. Otras preguntas también ayudan a contextualizar el sitio web.

La siguiente plantilla de especificación del sitio web realiza una serie de preguntas para ayudarle a definir el propósito del sitio web, para quién es el sitio web, las actividades que realizará en el sitio web y cualquier consideración especial, como los estándares de seguridad como PCI para las transacciones financieras.

Descargar plantilla de requisitos funcionales del sitio web

Word

Descargar plantilla de especificaciones técnicas del sitio web

Excel

Al desarrollar software y otras tecnologías con el método de desarrollo en cascada, a menudo puede usar una plantilla tradicional de requisitos o especificaciones funcionales. Los requisitos funcionales enumeran las funciones y características de lo que el producto "debe" hacer. Por ejemplo, “La aspiradora deberá recoger partículas de menos de cinco mm”.

‌ Descargar plantilla de especificaciones funcionales; Word

También es posible que prefiera una plantilla que se centre más en los requisitos empresariales. Esta plantilla minimalista le brinda espacio para que detalle el propósito de su producto o actualización en el contexto de sus objetivos empresariales, además de consideraciones de diseño de nivel superior.

‌ Descargar plantilla de requisitos funcionales; Word

 

Puede crear casos de uso para muchos tipos de productos, incluidos sitios web y software. Los casos de uso se centran en las tareas que un usuario debe realizar con el producto. Al concentrarse en las tareas, los documentos de casos de uso ayudan a los desarrolladores a crear productos centrados en el usuario. Estos documentos también impiden que las partes interesadas interpreten mal el diseño del producto. Utilice esta plantilla de casos de uso para definir una tarea en términos de actores, pasos y sucursales.

Descargar plantilla de casos de uso

Word

Un documento de especificaciones funcionales (FSD), también conocido como documento de requisitos funcionales (FRD), es considerado por muchos expertos en gestión de proyectos y desarrollo de software como la herramienta esencial para limitar la confusión y la mala dirección en un proyecto.

Aunque los FSD suelen asociarse al software y el desarrollo web, tienen un rol que desempeñar en cualquier proyecto, ya sea el lanzamiento de un producto nuevo, una actualización, el desarrollo de un producto de software o un elemento tangible o el establecimiento de procesos o cambios organizativos. Los documentos de especificaciones funcionales presentan tanto las expectativas de negocios como las de ingeniería. Todas las partes interesadas revisan y aprueban el documento. El resultado es un documento de referencia para el producto propuesto que aborda todas las partes de la organización, desde codificadores hasta diseñadores y personal de ventas.

Puede usar una plantilla de documento de especificación funcional para asegurarse de incluir toda la información esencial de desarrollo en un documento. Además, las plantillas garantizan que con cada nueva iniciativa, los equipos se centren en los requisitos del producto en lugar de perder tiempo determinando el diseño del documento de especificaciones. Las plantillas deben personalizarse para satisfacer las necesidades únicas de cada equipo o empresa.

Tradicionalmente, los FRD tienden a ser largos, secos y, a menudo, técnicos. Pero tal vez esos documentos no sean necesarios o incluso útiles. Debido a que el propósito del documento de requisitos funcionales es el alcance del proyecto para todas las partes interesadas, los FRD evitan largas discusiones técnicas. Si bien usted puede incluir muchos tipos de requisitos e información de respaldo (consulte la lista siguiente), la mejor práctica es describir únicamente las intenciones básicas del FRD. En esencia, el documento debe describir el contexto y las funciones que se desarrollarán. Se crea un documento de diseño técnico basado en las especificaciones de requisitos funcionales aceptadas. El FRD no debe duplicar ninguno de los otros requisitos o documentos de procesos.

Los documentos de especificaciones funcionales siguen un proceso de aprobación: Los usuarios empresariales comprueban que la solución responde a sus inquietudes y los revisores técnicos comprueban que se puede implementar la solución descrita. A menudo, los revisores clave incluyen evaluadores, usuarios finales, escritores técnicos y propietarios de productos o sistemas. Usted declara que el documento está completo cuando todos acuerdan el contenido. Luego, algunas organizaciones proceden a elaborar el documento de arquitectura de sistemas.

Una especificación de requisitos funcionales sirve como documento de referencia para todo el equipo. Muestra qué deben desarrollar los desarrolladores de productos, qué evaluar los evaluadores, qué deben documentar los escritores y qué venderán los vendedores. Una especificación funcional escrita muestra que el diseño y la intención se han considerado exhaustivamente antes de que comience el desarrollo. También ilustra que, luego de la aprobación de la especificación, todas las partes interesadas están en sintonía. No se deben escribir las especificaciones para completar el documento después de que se haya codificado el producto.

Algunos analistas de negocios y desarrolladores distinguen las especificaciones funcionales de los requisitos funcionales al decir que los requisitos describen qué debe hacer el software y las especificaciones describen cómo debe hacerlo el software. En la práctica, generalmente se combinan estos dos roles.

Las plantillas de documentos con especificaciones (o requisitos) funcionales también pueden tomar un grupo de formularios. El formato que elija dependerá de lo que funcione mejor para su organización.

• Requisitos funcionales: Tradicionalmente, esto es para software y otras tecnologías que utilizan el método de desarrollo en cascada. Los requisitos funcionales enumeran las funciones y características de lo que el producto "debe" hacer. Por ejemplo, “La aspiradora deberá recoger partículas de menos de cinco mm”.
• Casos de uso: Los casos de uso a menudo se sostienen por sí solos. Sin embargo, las organizaciones que valoran la experiencia del usuario suelen incorporar casos de uso a los requisitos funcionales. Los casos de uso establecen características y funciones en el contexto de las acciones del usuario. Por ejemplo, “El usuario toca dos veces la pantalla del teléfono. La pantalla se ilumina. El usuario desliza el dedo hacia la derecha de la pantalla para desbloquear el teléfono y su funcionalidad”.
• Historias de usuario: Las historias de usuario forman el núcleo del desarrollo de Agile porque describen el diseño del producto como lo que el usuario debe hacer. Este enfoque conciso ayuda a los equipos a otorgar valor a los usuarios de la manera más eficiente. Las historias de usuario toman el formato “Como usuario, puedo hacer algo para crear algún beneficio”.

Por lo general, los analistas de negocios y los líderes técnicos crean plantillas y especificaciones funcionales que comparten con las partes interesadas empresariales y técnicas que proporcionan revisiones para garantizar que la entrega esperada esté dentro del objetivo.

Puede usar especificaciones funcionales al desarrollar nuevos softwares y actualizaciones. También puede usarlos para cambios de ingeniería de sistemas y organización, desarrollo web y mucho más. Los usuarios de las especificaciones incluyen los siguientes grupos:

• Desarrolladores que codifican el producto
• Diseñadores que crean la interfaz de usuario (UI) para el software, dispositivo o sitio web
• Evaluadores que se aseguran de que el código funcione correctamente y según las especificaciones
• Comercializadores que preparan documentos que generan demanda en torno a la nueva funcionalidad
• Equipos de ventas que venden la función y el producto
• Escritores de asistencia técnica o al usuario que documentan cómo funciona el producto para administradores, usuarios finales y otros roles

Aunque existen muchas combinaciones y modificaciones de documentos, los documentos de especificaciones funcionales (FSD) y los documentos de requisitos empresariales (BRD) a veces son independientes.

Los BRD describen los requisitos empresariales de mayor nivel para un producto (lo que hace un producto). Los BRD evitan los detalles técnicos a favor de los fundamentos detallados del producto. Una comprensión clara de lo que ofrece el producto y por qué es necesario puede ayudar a guiar el desarrollo a través de las disputas sobre la dirección del producto. Los FSD pueden centrarse en definir las características y funciones del producto que necesita para alcanzar su objetivo final.

Crear un producto, ya sea tangible o transaccional, puede implicar generar muchos documentos. Las plantillas de especificaciones funcionales se pueden usar junto con cualquiera de las siguientes opciones:

• Requisitos del usuario: Este documento representa lo que el usuario espera que haga el producto. Algunos consideran que el requisito del usuario es una parte del documento de requisitos funcionales. Si este documento existe, debe incluirse en su proceso de desarrollo general. En el desarrollo de Agile, los requisitos del usuario (expresados como historias de usuarios) se consideran el centro de los requisitos funcionales.
• Requisitos del producto: Utilizado indistintamente con un documento de requisitos del mercado, este documento detalla el propósito de un producto.
• Documentos de procesos empresariales: En este documento se detalla un proceso empresariales.
• Evaluaciones de necesidades empresariales: En este documento se describen las diferencias entre las condiciones actuales y las condiciones de negocios deseadas.
• Especificaciones técnicas de diseño: Este documento describe (con el más mínimo detalle) los elementos de programación necesarios para el diseño propuesto.
• Documentos de validación: Los documentos de validación pueden incluir una matriz de trazabilidad (que hace un seguimiento de las funciones a lo largo del proceso de desarrollo), planes de prueba y requisitos de operación.
• Requisitos del sistema: Este documento esboza una expectativa de alto nivel para un sistema o producto.
• Requisitos de negocios: En este documento se describen las razones de alto nivel para crear un producto o actualización.
• Casos de uso: Este documento ofrece detalles funcionales y contexto para las funciones desde la perspectiva del usuario.
• Historias de usuario: Este documento se utiliza principalmente para el desarrollo de Agile. Comunique la intención del producto detallando lo que el usuario hará con él.

Los requisitos pueden clasificarse como especificaciones funcionales y no funcionales (el qué y el cómo).

• Requisito funcional: Esto describe el comportamiento, la actividad o el resultado esperado de un producto o sistema. Por ejemplo, “Filtrar partículas del agua” o "Imprimir una página”. Los requisitos funcionales comunes incluyen funciones de administración, autorización y autenticación, seguimiento de auditorías e informes y reglas de negocios.
• Requisito no funcional: Describe cómo funciona algo, que también puede considerarse una restricción, atributo o parámetro. Si la palabra en inglés que describe el proceso termina en -ity, no es funcional. Entre los ejemplos se incluyen “usability” (facilidad de uso), “maintainability” (mantenimiento) y “security” (seguridad), además del rendimiento y los requisitos normativos.

En SAP, un documento de especificaciones funcionales es una descripción del producto desde el punto de vista de la parte interesada, con expectativas precisas sobre cómo se relaciona la función con SAP. Usted crea especificaciones funcionales después de combinar el documento de requisitos de software y FSD en uno.

Como mínimo, los FRD deben incluir estos elementos:

• A quién está destinado el producto
• Quién está autorizado a usar el producto
• Entradas en el sistema
• Qué debería hacer cada pantalla
• Flujos de trabajo del sistema
• Resultados
• Requisitos normativos abordados por el producto
• Requisitos comerciales específicos de su empresa

Una descripción escrita de las funciones deseadas es una parte esencial del desarrollo del producto, pero la forma que toma la plantilla de requisitos funcionales también debe regirse por lo que funciona para su equipo.

Al desarrollar una plantilla, o incluso al considerar mejoras en un proceso de desarrollo existente, pídales a todos los que tengan interés en el resultado del producto lo que quieren en una plantilla. Cada formato ofrece ventajas y desventajas:

• Las declaraciones con "deberán" en los requisitos funcionales tradicionales suelen carecer de contexto y están más sujetas a la interpretación del desarrollador.
• Los casos de uso ofrecen contexto y detalles, pero el diablo puede estar en esos detalles, el alcance puede colarse a medida que los requisitos reales del usuario se vuelven claros. Los requisitos más pequeños pueden perderse entre los casos de uso.
• Las historias de usuario ofrecen la ventaja de describir las necesidades del usuario en el contexto de los requisitos empresariales. Sin embargo, pueden requerir un esfuerzo extra (es decir, investigación de una implementación adecuada). Los desarrolladores y otras personas también pueden centrarse tanto en las historias individuales que excluyen el contexto más amplio del producto.

Una vez más, al considerar qué herramienta usar para crear documentos de requisitos de software, las necesidades de su organización son fundamentales. Lo que funciona para otras empresas puede que no funcione para usted.

• Administración de documentación: Esta herramienta ofrece una de las herramientas más fáciles y omnipresentes para crear plantillas y representar documentos. Muchos documentos de requisitos funcionales están disponibles como plantillas de documentos.
• Software de hoja de cálculo: Las hojas de cálculo le permiten agregar columnas según sea necesario. También eliminan la presión de elaborar frases perfectas porque solo debe capturar los detalles esenciales que requiere un lector para crear el producto correcto.
• Aspectos básicos de la administración de proyectos de Agile: Muchas plataformas diseñadas con un fin ofrecen funcionalidad para capturar los requisitos o los detalles de la historia del usuario y el desarrollo de seguimiento de funciones.

Aunque algunos requisitos son básicos y esenciales para transmitir la intención de su producto, otros pueden o no ser valiosos para desarrollar su producto. El formato que elija también puede estar impulsado por lo que está desarrollando. A continuación, le mostremos una lista que puede usar como guía para preparar los requisitos funcionales:

• Sección frontal

  • Página de metadatos: Esto resume todo sobre el documento.
  • Instrucciones para los autores: Explica la información específica requerida por su organización en un documento de especificaciones. Estas instrucciones pueden aparecer en la introducción o en toda la plantilla.
  • Número de versión
  • Cambiar página de registro/revisión: En la plantilla y el documento de requisitos publicados, debe incluir todas las enmiendas, detalles, fechas y las iniciales del aprobador.
  • Bloque de aprobación: Esto implica firmar cada revisión y aprobar cada requisito con una firma.
  • Lista de distribución: Es posible que se requiera que algunos miembros del equipo revisen el documento. Como alternativa, la visualización puede limitarse a solo unos pocos miembros del equipo.

• Descripción general

  • Descripción del producto
  • Descripción general de requisitos empresariales
  • Alcance del trabajo (qué se cubrirá y qué no)
  • Descripción del sistema actual
  • Convenciones de documentos
  • Terminología (incluidos los acrónimos)
  • Referencias
  • Limitaciones y suposiciones generales
     

• Funcionalidad

  • Proceso de negocios
  • Métodos propuestos
  • Roles de usuario/comunidad de usuarios
  • Casos de uso
  • Historias de usuario
  • Flujos de trabajo dentro del sistema
  • Prototipos de diseño
  • Bastidores o guiones gráficos
  • Lista de funciones o descripciones de funciones
  • Requisitos de datos
  • Funcionalidad de administración
  • Administración de la configuración
  • Plataforma
  • Instalación
  • Portabilidad
  • Extensibilidad
  • Personalización
  • Impresión
  • Gestión de errores
  • Soporte y mantenimiento
  • Internacionalización
  • Ayuda y documentación
     

• Otro software

  • Entradas, salidas y procesamiento
  • Interfaces externas
  • Interfaces de usuario
  • Interfaces de hardware
  • Interfaces de software
  • Interfaces de comunicación
  • Soporte para bases de datos
     

• Atributos

  • Seguridad
  • Fiabilidad, disponibilidad, mantenimiento, facilidad de uso, compatibilidad
  • Requisitos normativos
     

• Apéndice

  • Modelos de análisis

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.