tiempo de lectura: 9 minutos
los requisitos claramente definidos son señales esenciales en el camino que conduce a un proyecto exitoso. Establecen un acuerdo formal entre un cliente y un proveedor de que ambos están trabajando para alcanzar el mismo objetivo. Los requisitos detallados y de alta calidad también ayudan a mitigar los riesgos financieros y mantener el proyecto en un calendario., De acuerdo con la definición de Business Analysis Body of Knowledge, los requisitos son una representación utilizable de una necesidad.
crear requisitos es una tarea compleja, ya que incluye un conjunto de procesos como la obtención, el análisis, la especificación, la validación y la gestión. En este artículo, discutiremos los principales tipos de requisitos para los productos de software y proporcionaremos una serie de recomendaciones para su uso.
clasificación de los requisitos
antes de discutir cómo se crean los requisitos, vamos a diferenciar sus tipos.,
requisitos de alto nivel en cascada hacia abajo a detalles específicos
requisitos comerciales. Estos incluyen declaraciones de alto nivel de metas, objetivos y necesidades.
requisitos del Stakeholder. Las necesidades de los grupos de partes interesadas discretos también se especifican para definir lo que esperan de una solución particular.
requisitos de la Solución. Los requisitos de la solución describen las características que debe tener un producto para satisfacer las necesidades de las partes interesadas y del propio negocio.,
- Los requisitos no funcionales describen las características generales de un sistema. También se conocen como atributos de calidad.
- Los requisitos funcionales describen cómo debe comportarse un producto, Cuáles son sus características y funciones.
requisitos de Transición. Un grupo adicional de requisitos define lo que se necesita de una organización para pasar con éxito de su estado actual a su estado deseado con el nuevo producto.
exploremos los requisitos funcionales y no funcionales con mayor detalle.,
los requisitos funcionales y sus especificaciones
los requisitos funcionales son características del producto o funciones que los desarrolladores deben implementar para permitir a los usuarios realizar sus tareas. Por lo tanto, es importante dejarlas claras tanto para el equipo de desarrollo como para las partes interesadas. Generalmente, los requisitos funcionales describen el comportamiento del sistema bajo condiciones específicas. Por ejemplo:
una función de búsqueda permite al usuario buscar entre varias facturas si desea acreditar una factura emitida.
Aquí hay otro ejemplo simple: como invitado, quiero un sofá en el que pueda dormir durante la noche.,
Los requisitos generalmente se escriben en texto, especialmente para proyectos ágiles. Sin embargo, también pueden ser visuales. Estos son los formatos y documentos más comunes:
- documento de especificación de requisitos de Software
- casos de uso
- historias de usuario
- Estructura de desglose de trabajo (WBS) (descomposición funcional)
- prototipos
- modelos y diagramas
documento de especificación de requisitos de Software
los requisitos funcionales y no funcionales se pueden formalizar en el documento de especificación de requisitos (SRS)., (Para obtener más información sobre la documentación del software, Lea nuestro artículo sobre ese tema.) El SRS contiene descripciones de funciones y capacidades que el producto debe proporcionar. En el documento también se definen limitaciones y supuestos. El SRS puede ser un solo documento que comunica los requisitos funcionales o puede acompañar a otra documentación de software como historias de usuario y casos de uso.
no recomendamos componer SRS para toda la solución antes del inicio del desarrollo, pero debe documentar los requisitos para cada característica individual antes de construirla., Una vez que reciba los comentarios iniciales del usuario, puede actualizar el documento.
SRS debe incluir las siguientes secciones:
Propósito. Definiciones, visión general del sistema y antecedentes.
descripción General. Supuestos, restricciones, Reglas de negocio y visión del producto.
requisitos Específicos. Atributos del sistema, requisitos funcionales, requisitos de la base de datos.
es esencial hacer que el SRS sea legible para todas las partes interesadas. También debe usar plantillas con énfasis visual para estructurar la información y ayudar a entenderla., Si tiene requisitos almacenados en otros formatos de documento, enlace a ellos para que los lectores puedan encontrar la información necesaria.
ejemplo: si desea ver un documento real, descargue este ejemplo de SRS creado en la Universidad Estatal de Michigan, que incluye todos los puntos mencionados anteriormente, además de presentar casos de uso para ilustrar partes del producto.
casos de uso
los casos de uso describen la interacción entre el sistema y los usuarios externos que conduce al logro de objetivos particulares.
cada caso de uso incluye tres elementos principales:
actores., Estos son los usuarios fuera del sistema que interactúan con el sistema.
Sistema. El sistema se describe mediante requisitos funcionales que definen un comportamiento previsto del producto.
Objetivos. Los propósitos de la interacción entre los usuarios y el sistema se describen como objetivos.
Hay dos formatos para representar casos de uso:
- especificación de caso de uso estructurada en formato textual
- diagrama de caso de uso
una especificación de caso de uso representa la secuencia de eventos junto con otra información relacionada con este caso de uso., Una plantilla típica de especificación de caso de uso incluye la siguiente información:
- Descripción
- condición previa y posterior a la interacción
- ruta de interacción básica
- ruta alternativa
- ruta de excepción
Ejemplo:
plantilla de especificación de caso de uso
Un diagrama de caso de uso no contiene muchos detalles. Muestra una visión general de alto nivel de las relaciones entre los actores, los diferentes casos de uso y el sistema.
El diagrama de casos de uso incluye los siguientes elementos principales:
casos de Uso., Generalmente dibujados con óvalos, los casos de uso representan diferentes escenarios de uso que los actores pueden tener con el sistema (Iniciar sesión, realizar una compra, Ver artículos, etc.).)
límites del sistema. Los límites están delineados por el cuadro que agrupa varios casos de uso en un sistema.
actores. Estas son las figuras que representan a usuarios externos (personas o sistemas) que interactúan con el sistema.
Asociaciones. Las asociaciones se dibujan con líneas que muestran diferentes tipos de relaciones entre los actores y los casos de uso.,
ejemplo:
ejemplo de diagrama de caso de uso
historias de usuario
Una historia de usuario es una descripción documentada de una característica de software vista desde la perspectiva del usuario final. La historia del usuario describe exactamente lo que el usuario quiere que haga el sistema. En los proyectos ágiles, las historias de usuario se organizan en un backlog, que es una lista ordenada de funciones del producto. Actualmente, las historias de usuario se consideran el mejor formato para los elementos atrasados.,
Una típica historia de usuario se escribe así:
Como <tipo de usuario>, Quiero <algún objetivo> para que <alguna razón>.
ejemplo:
como administrador, quiero agregar descripciones a los productos para que los usuarios puedan ver más adelante estas descripciones y comparar los productos.
Las historias de usuario deben ir acompañadas de criterios de aceptación., Estas son las condiciones que el producto debe satisfacer para ser aceptado por un usuario, partes interesadas o propietario de un producto. Cada historia de usuario debe tener al menos un criterio de aceptación. Los criterios de aceptación efectivos deben ser comprobables, concisos y completamente comprendidos por todos los miembros del equipo y las partes interesadas. Se pueden escribir como listas de verificación, texto plano, o usando el formato/When/Then dado.
ejemplo:
Este es un ejemplo de la lista de verificación de criterios de aceptación para una historia de usuario que describe una función de búsqueda:
- Un campo de búsqueda está disponible en la barra superior.,
- Se inicia una búsqueda cuando el usuario hace clic en Enviar.
- El marcador de posición predeterminado es un texto gris escriba el nombre.
- El marcador de posición desaparece cuando el usuario comienza a escribir.
- El idioma de búsqueda es el inglés.
- El Usuario no puede escribir más de 200 símbolos.
- no admite símbolos especiales. Si el Usuario ha escrito un símbolo especial en la entrada de búsqueda, muestra el masaje de advertencia: la entrada de búsqueda no puede contener símbolos especiales.,
Finalmente, todas las historias de usuario deben ajustarse al modelo de calidad INVEST:
- I-Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
Independent. Esto significa que puede programar e implementar cada historia de usuario por separado. Esto es muy útil si implementa procesos de integración continua.
Negociable. Esto significa que todas las partes acuerdan priorizar las negociaciones sobre la especificación. Esto también significa que los detalles se crearán constantemente durante el desarrollo.
Valioso., Una historia debe ser valiosa para el cliente. Debe preguntarse desde la perspectiva del cliente «por qué» necesita implementar una característica determinada.
estimable. Se puede estimar una historia de usuario de calidad. Esto ayudará a un equipo a programar y priorizar la implementación. Cuanto más grande es la historia, más difícil es estimarla.
Pequeño. Las buenas historias de usuario tienden a ser lo suficientemente pequeñas como para planificar lanzamientos de producción cortos. Las historias pequeñas permiten estimaciones más específicas.
comprobable. Si una historia puede ser probada, es lo suficientemente clara y lo suficientemente buena., Las historias probadas significan que los requisitos están hechos y listos para su uso.
Functional decomposition or Work Breakdown Structures (WBS)
una descomposición funcional o WBS es un documento visual que ilustra cómo los procesos complejos se descomponen en sus componentes más simples. WBS es un enfoque eficaz para permitir un análisis independiente de cada parte. WBS también ayuda a capturar la imagen completa del proyecto.
sugerimos la siguiente lógica de descomposición funcional:
- encontrar la función más general.
- encuentra la subfunción más cercana.,
- encuentra el siguiente nivel de subfunción.
- Compruebe su diagrama.
o el proceso de descomposición puede tener este aspecto:
High Level Function ->Sub-function -> Process -> Activity
Las características deben descomponerse en el punto en el que el las partes de nivel no se pueden descomponer más.,
ejemplo:
un ejemplo de descomposición funcional
prototipos de Software
El prototipo de Software es un término general para diferentes formas de entregables en etapas tempranas que se construyen para mostrar cómo se deben implementar los requisitos. Los prototipos ayudan a cerrar las brechas de visión y permiten que las partes interesadas y los equipos aclaren áreas complicadas de los productos en desarrollo. Tradicionalmente, los prototipos representan cómo funcionará la solución y dan ejemplos de cómo los usuarios interactuarán con ella para realizar sus tareas.,
Los prototipos pueden ser representaciones visuales baratas y rápidas de requisitos (prototipos desechables) o más complejas (prototipos evolutivos). Este último puede incluso convertirse en las primeras versiones del producto que ya tienen algunas piezas del código final. Efectivamente, los prototipos evolutivos pueden incluso convertirse en MVP que hemos descrito en un artículo separado.
los documentos de diseño y prototipos
los requisitos de diseño generalmente se recopilan y documentan utilizando tres formatos principales que se transforman entre sí:
Wireframes., Los Wireframes son estructuras gráficas de baja fidelidad de un sitio web o una aplicación. Ayudan a mapear diferentes páginas de productos con secciones y elementos interactivos.
Maquetas. Una vez que los wireframes están listos, se convierten en Maquetas, diseños visuales que transmiten la apariencia del producto final. Eventualmente, las maquetas pueden convertirse en el diseño final del producto.
diseñar prototipos. Estos documentos contienen elementos visuales y permiten algunas interacciones de interfaz, como desplazarse, hacer clic en enlaces o rellenar formularios., Los prototipos de diseño se pueden construir desde cero utilizando HTML y CSS, pero la mayoría de los equipos de UX utilizan servicios de creación de prototipos como InVision.
ejemplo:
para obtener más información sobre cómo se manejan los procesos de diseño de experiencia de usuario, consulte nuestro estudio de caso sobre la creación de una solución de gestión de viajes para Cornerstone, un proveedor corporativo de SaaS, en el que utilizamos los tres tipos de requisitos de diseño.
requisitos no funcionales
los requisitos no funcionales describen cómo debe comportarse un sistema y establecen restricciones de su funcionalidad. Este tipo de requisitos también se conoce como atributos de calidad del sistema.,
echemos un vistazo de cerca a los requisitos no funcionales típicos.
usabilidad
usabilidad define lo difícil que será para un usuario aprender y operar el sistema. La usabilidad se puede evaluar desde diferentes puntos de vista:
eficiencia de uso: el tiempo promedio que tarda en lograr los objetivos de un usuario, cuántas tareas puede completar un usuario sin ninguna ayuda, el número de transacciones completadas sin errores, etc.
intuición: lo sencillo que es entender la interfaz, botones, encabezados, etc.,
carga de trabajo percibida baja: cuántos intentos son necesarios por los usuarios para llevar a cabo una tarea en particular.
ejemplo: los requisitos de usabilidad pueden considerar las barreras del idioma y las tareas de localización: las personas que no entienden francés deben poder usar el producto. O puede establecer requisitos de accesibilidad: los usuarios de teclado que naveguen por un sitio web utilizando <tab>, deben poder acceder al botón» Agregar al carrito»desde una página de producto dentro de 15 clics <tab>.,
seguridad
los requisitos de seguridad garantizan que el software esté protegido del acceso no autorizado al sistema y a sus datos almacenados. Considera diferentes niveles de autorización y autenticación en diferentes roles de usuarios. Por ejemplo, la privacidad de datos es una característica de seguridad que describe quién puede crear, ver, copiar, cambiar o eliminar información. La seguridad también incluye protección contra virus y ataques de malware.
ejemplo: los permisos de Acceso para la información particular del sistema solo pueden ser cambiados por el administrador de datos del sistema.,
confiabilidad
confiabilidad define la probabilidad de que el software funcione sin fallas durante un período de tiempo determinado. La confiabilidad disminuye debido a errores en el código, fallas de hardware o problemas con otros componentes del sistema. Para medir la confiabilidad del software, puede contar el porcentaje de operaciones que se completan correctamente o rastrear el período promedio de tiempo en que se ejecuta el sistema antes de fallar.
ejemplo: el proceso de actualización de la base de datos debe revertir todas las actualizaciones relacionadas cuando falla alguna actualización.,
Performance
Performance es un atributo de calidad que describe la capacidad de respuesta del sistema a varias interacciones del usuario con él. Un rendimiento deficiente conduce a una experiencia de usuario negativa. También pone en peligro la seguridad del sistema cuando está sobrecargado.
ejemplo: el tiempo de carga de la página principal no debe ser superior a 2 segundos para los usuarios que accedan al sitio Web mediante una conexión móvil LTE.
disponibilidad
la disponibilidad se mide por el período de tiempo que la funcionalidad y los servicios del sistema están disponibles para su uso con todas las operaciones., Por lo tanto, los períodos de mantenimiento programados influyen directamente en este parámetro. Y es importante definir cómo se puede minimizar el impacto del mantenimiento. Al escribir los requisitos de disponibilidad, el equipo tiene que definir los componentes más críticos del sistema que deben estar disponibles en todo momento. También debe preparar notificaciones de usuario en caso de que el sistema o una de sus partes no esté disponible.
ejemplo: la implementación del nuevo módulo no debe afectar la página principal, las páginas de productos y la disponibilidad de las páginas, y no debe tardar más de una hora., El resto de las páginas que puedan experimentar problemas deben mostrar una notificación con un temporizador que muestre cuándo el sistema volverá a estar activo.
escalabilidad
los requisitos de escalabilidad describen cómo el sistema debe crecer sin influir negativamente en su rendimiento. Esto significa servir a más usuarios, procesar más datos y realizar más transacciones. La escalabilidad tiene implicaciones tanto de hardware como de software. Por ejemplo, puede aumentar la escalabilidad agregando memoria, servidores o espacio en disco. Por otro lado, puede comprimir datos, usar algoritmos de optimización, etc.,
ejemplo: el límite de asistencia del sitio web debe ser lo suficientemente escalable como para admitir 200.000 usuarios a la vez.
palabras finales
todos los proyectos de software incluyen los límites de información que describen los objetivos del producto y del proyecto. Estos límites se dibujan en los requisitos y especificaciones del proyecto. El valor de crear una especificación de requerimientos de software está en la optimización del proceso de desarrollo. Las especificaciones de requisitos de Software responden a todas las preguntas del desarrollador sobre el producto que se requieren Para comenzar el trabajo., La especificación funcional es aprobada por el cliente y asegura que los desarrolladores están construyendo lo que el cliente quiere.