Los autores a veces hacen las cosas más largas y complicadas de lo necesario. Algunos lectores pueden sentir que yo mismo he sido culpable de esto. La tercera edición de mi libro. Requisitos de Software, en coautoría con Joy Beatty, tiene unas 245.000 palabras, casi 640 páginas en una fuente bastante pequeña. Tal vez eso parezca una exageración, pero para ser justos, el dominio de los requisitos es grande y complejo.
libros como Requisitos de Software, Dominar el proceso de requisitos por Suzanne y James Robertson, y el IIBA Cuerpo de conocimientos de análisis empresarial describir docenas de técnicas valiosas para la obtención, el análisis, la especificación, la validación y la gestión de requisitos. Todos son útiles cuando se aplican cuidadosamente en situaciones apropiadas. Pero si no tiene tiempo para leer estos grandes volúmenes, es posible que le guste esta versión TL; DR de las seis prácticas de requisitos más importantes que todo equipo de proyecto debe realizar. Este artículo está adaptado de Fundamentos de los requisitos de software: Prácticas básicas para un análisis comercial exitoso por Karl Wiegers y Candase Hokanson.
Las organizaciones emprenden un proyecto para resolver un problema, explotar una oportunidad de negocio o crear un nuevo mercado. La definición de los objetivos comerciales del proyecto comunica a todos los participantes y otras partes interesadas por qué están trabajando en el proyecto. La organización podría aspirar a alcanzar los objetivos comerciales financieros y no financieros con el nuevo producto. Trate de cuantificar los objetivos comerciales y hacerlos medibles, con afirmaciones como estas:
- Capture una cuota de mercado del X por ciento en Y meses.
- Alcanza un volumen de ventas de X unidades o ingresos de $Y en Z meses.
- Ahorre X dólares por año gastado actualmente en un sistema heredado de alto mantenimiento.
El uso de objetivos comerciales alinea todo el trabajo del equipo y las decisiones clave. Sin objetivos comerciales definidos, no se puede elaborar una declaración clara de la visión del producto o establecer el alcance de todo el proyecto o de cualquier incremento de desarrollo. El equipo no puede tomar buenas decisiones sobre los cambios de alcance o la funcionalidad propuesta a menos que sepa cómo esos cambios coinciden con los objetivos comerciales.
Mantener el alcance enfocado ayuda al equipo a evitar fluencia del alcance sin dejar de adaptarse a las cambiantes realidades empresariales. ¿Y cómo puede saber si el proyecto fue un éxito a menos que alguien definiera sus objetivos comerciales y criterios de éxito por adelantado?
Abogo firmemente por tomar una enfoque centrado en el uso de los requisitos desarrollo y diseño de soluciones, en lugar de un enfoque centrado en características o productos. Comprender las tareas que los usuarios deben realizar y los objetivos que desean lograr permite al analista de negocios (BA) derivar la funcionalidad que los desarrolladores deben implementar.
Cuando se enfoca en explorar características en lugar de objetivos de usuario, es fácil pasar por alto algunas funciones necesarias. También es fácil incluir funciones que parecen geniales pero que no ayudan a los usuarios a realizar su trabajo. Los casos de uso son una técnica eficaz para mantener esta mentalidad centrada en el uso.
Tratar de comprender lo que los usuarios deben hacer con el producto implica varias otras actividades importantes de BA, incluidas las siguientes:
- Identificar una amplia gama de partes interesadas del proyecto
- Caracterización de distintas clases de usuarios que tienen requisitos muy diferentes
- Identificar individuos para servir como la voz del cliente para cada clase de usuario (campeones de producto)
- Seleccionar técnicas apropiadas de elicitación de requisitos para interactuar con los usuarios
- Establecer procesos de toma de decisiones para resolver conflictos y prioridades entre clases de usuarios
- Creación y evaluación de prototipos o versiones preliminares para estimular la retroalimentación de los usuarios
Anuncio
Dudo que algún proyecto haya implementado alguna vez cada parte de la funcionalidad solicitada. Incluso si pudiera implementarlo todo, no puede hacerlo todo a la vez. Su objetivo es ofrecer el máximo valor comercial a sus clientes al menor costo y en el menor tiempo posible. Lograr este objetivo exige priorizar los requisitos para que el equipo pueda trabajar en ellos en la secuencia más adecuada.
La priorización implica considerar cuánto contribuye cada requisito propuesto al logro de los objetivos comerciales del proyecto. La priorización de requisitos le permite al equipo decidir cuál de los elementos de trabajo que quedan en la cartera de pedidos aplazar u omitir debido a limitaciones de tiempo y recursos. Hay numerosos técnicas de priorización de requisitos disponible, incluyendo estos:
- Dentro o fuera
- Comparación por pares y ordenación por rangos
- escala de tres niveles
- Moscú
- Ponderación relativa
- prueba de $100
Algunos de estos métodos requieren más esfuerzo que otros, pero esos métodos también ayudan al gerente del proyecto o al propietario del producto a tomar decisiones más detalladas. Elija cualquier técnica que permita a las partes interesadas adecuadas tomar buenas decisiones comerciales a lo largo del proyecto para evitar una frenética “fase de descoping rápido” al final del juego.
Las personas, naturalmente, se enfocan en la funcionalidad de un producto cuando discuten los requisitos, pero esos son solo una parte de la solución. Los requisitos no funcionales contribuyen en gran medida a la satisfacción del usuario y a la idoneidad para su uso. Cuando se habla de “requisitos no funcionales”, la gente suele pensar en atributos de calidad, a veces llamado “-ilidades”. Estas características del producto incluyen usabilidad, mantenibilidad, seguridad, confiabilidad y muchas otras. Para ayudar a los diseñadores a idear la solución más adecuada, los BA deben analizar los requisitos no funcionales como parte de la obtención de requisitos.
Por lo general, los desarrolladores no implementan directamente los requisitos que describen la seguridad, la confiabilidad, la portabilidad, la seguridad u otras características. En cambio, estos atributos sirven como origen de muchos requisitos funcionales y decisiones de diseño de impulso. La Tabla 1 indica las categorías probables de información técnica que generarán los diferentes tipos de atributos de calidad.
Tabla 1. Traducir los atributos de calidad en especificaciones técnicas (desde Requisitos de software, 3.ª edición)
Otro desafío es que no es posible optimizar todos los factores de calidad deseados a la vez. Los diseñadores deben tomar decisiones de compensación entre los diversos atributos. Por lo tanto, el equipo debe determinar cuáles son los más importantes para el éxito del cliente y optimizarlos. Especificar cuidadosamente los atributos de calidad le permite crear un producto que deleite a sus usuarios, más allá de simplemente hacer lo que se supone que debe hacer.
¿Cómo sabe si sus requisitos son precisos? ¿Cómo puede saber si son lo suficientemente claros para que todos los miembros del equipo sepan qué hacer con ellos y otras partes interesadas sepan qué esperar en la solución? No importa cómo elija representar el conocimiento de los requisitos, a veces es ambiguo, incompleto o simplemente incorrecto.
Una de las prácticas de calidad más poderosas disponibles es revisión por pares de requisitos Convoque a algunos colegas para revisar tanto los requisitos textuales como los diagramas. Los diferentes participantes del proyecto (BA, diseñadores, desarrolladores, probadores, usuarios) encontrarán diferentes tipos de problemas durante estas revisiones. Las revisiones de requisitos plantean algunos desafíos particulares. En lugar de simplemente invitar a las personas a revisar los requisitos, brinde capacitación para que los revisores sepan cómo participar de manera efectiva y puedan encontrar tantos problemas como sea posible.
Una práctica de validación de requisitos relacionada es escribir pruebas conceptuales basadas en requisitos. Probar los requisitos es algo que puede hacer al principio de cada ciclo de desarrollo para revelar muchos errores antes de que se conviertan en código. Los requisitos y las pruebas son visiones complementarias de un mismo conocimiento. Los requisitos describen cómo debe comportarse el producto bajo ciertas condiciones; las pruebas describen cómo saber si está exhibiendo los comportamientos correctos.
No importa qué tan bien comprenda el problema y qué tan cuidadosamente prepare los requisitos, no serán perfectos, completos o estáticos. El mundo cambia a nuestro alrededor mientras trabajamos. Aparecen nuevos usuarios y nuevas ideas. Las reglas de negocio emergen y evolucionan. Los proyectos inevitablemente crecen más allá de su alcance previsto originalmente. Cada equipo debe anticipar cambios en los requisitos y establecer mecanismos para enfrentarlos sin descarrilar los compromisos del equipo.
Cuando sabe que el resultado del proyecto no está completamente definido y es probable que cambie mucho, un enfoque ágil e incremental es una buena forma de afrontarlo. Planea construir los requisitos, y la solución, en una serie de pequeños fragmentos, esperando que la dirección cambie y aceptando la incertidumbre de lo que tendrá al final y cuándo lo tendrá.
Cuando el grado probable de cambio sea menos extremo, planee acomodar cierto crecimiento (junto con riesgos, estimaciones imprecisas y eventos inesperados) mediante la creación de amortiguadores de contingencia en los cronogramas de desarrollo. Establezca un proceso de cambio de requisitos para que las personas adecuadas puedan obtener la información correcta para tomar buenas decisiones comerciales sobre qué cambios propuestos incorporar para agregar valor con la mínima interrupción.
Sin embargo, no use la expectativa de cambio como una justificación para escatimar en el pensamiento de requisitos. La rotación excesiva de requisitos a menudo indica que los objetivos no estaban claros o que el enfoque de obtención no fue efectivo.
Por supuesto, hay muchas otras actividades de requisitos valiosas además de estas seis. Sin embargo, estas prácticas aumentan en gran medida sus posibilidades de crear una solución que logre los resultados comerciales deseados de manera eficiente y eficaz. Aplicarlos no garantiza el éxito de ningún BA, propietario de producto o gerente de producto. Pero descuidarlos probablemente asegura el fracaso.
Puntos de vista: 32
