Get best of the week

Requisitos de software de dedo

Una publicación sobre los conceptos básicos del desarrollo de requisitos, sin diagramas complejos, términos y tablas, pero con gifs.

imagen

En resumen, los pasos principales para desarrollar requisitos son:

  1. ¿Por qué tenemos que hacer algo? (Necesito más oro)
  2. qué hacemos? (todo es como la gente, pero más barato)
  3. Cómo hacemos esto? (con blockchain y datasientistas, por supuesto)
  4. ¿Cuándo haremos esto? (ayer, y refactorizar "más tarde")

Y ahora con más detalle.

Si alguna vez solicitó hacer algo, significa que creó requisitos. Pueden tener la forma de un deseo oral, carta, tarea técnica, tarea o cualquier otra cosa.
Entonces los requisitos están en todas partes.

imagen

Si, después de cumplir con la solicitud, algo salió mal, o estropeó al artista
o configuró la tarea incorrectamente.

Como saben, la tarea incorrecta puede ser bastante costosa. Por ejemplo, si durante medio año un equipo de 5 programadores desarrolló un sistema que nadie necesitaba.

En esta era turbulenta, los requisitos de diseño ágil a menudo se descuidan. Pero las metodologías flexibles no siempre lo salvan de grandes pérdidas. Por lo tanto, incluso si no tiene un analista en el proyecto, incluso si no tiene TI en absoluto, no se olvide del sentido común y tome de las mejores prácticas lo que necesita en este momento.

¿Cuáles son los requisitos y por qué es importante poder desarrollarlos?

Entonces, pasemos a las fuentes:

imagen

es decir, puede hablar sobre los requisitos y sobre las propiedades futuras. ¿Qué tal un producto que cumpla con los objetivos de desarrollo?

¿Dónde comenzar a desarrollar requisitos? Hay una pista oculta en la definición: debe comenzar con el objetivo: ¿por qué debemos hacer algo?

1. ¿Por qué?


imagen

Como "lo antes posible!" no había necesidad de hacer algo; es importante encontrar el tiempo y la energía para descubrir por qué esto es necesario.

Porque a menudo, después de aclarar el objetivo, la tarea cambia o se elimina por completo.
Por ejemplo, el

Cliente le mostrará rápidamente todos los pedidos realizados en el sistema. Digamos que nos tensamos y pusimos una tarea en medio de un sprint para mostrar todas las órdenes para el administrador. Después de eso, el cliente solicita mostrar en una ventana separada una lista de todas las empresas cuyos pedidos ve. Ellos también lo hicieron. Luego el cliente solicita retirar además todas las empresas asociadas. Bien ... Después de un tiempo, nos reunimos con el cliente y vemos cómo carga ambas listas en Excel, reconoce la diferencia y comienza a llamar a las compañías que no tienen órdenes para recordarles que hagan pedidos a través de nuestro sistema.

Si le preguntamos al cliente desde el principio qué objetivo quiere lograr al observar todos los pedidos, ahorraríamos mucho tiempo y esfuerzo al informar de inmediato a las empresas que no han realizado pedidos hasta el momento.
Puede utilizar el método "Five Why" o cualquier otro. Pero, por lo general, las personas no se resisten: si muestra interés en su trabajo, hay una solución disponible.

Una vez decidido un objetivo, es necesario definirlo claramente y establecer criterios mediante los cuales pueda decir con precisión que se ha logrado el objetivo.

Por ejemplo, el

proceso de pedido de materiales se considera automatizado si> 90% de las empresas asociadas realizan pedidos a través del sistema.

Esto facilita la comprensión de las tareas y, al mismo tiempo, libera las manos para elegir los medios para lograr el objetivo.

Y sí, no olvides coordinar esta belleza con los clientes. En general, no olvide coordinar los requisitos con todas las partes interesadas.

2. ¿Qué?


El objetivo se logra de diferentes maneras. Y el segundo paso importante en el desarrollo de los requisitos es simplemente elegir el camino: qué haremos exactamente para alcanzar el objetivo.

imagen



, :

. . . // .

. — , .

. . .

Para pensar en todas las opciones, debe averiguar: ¿qué está sucediendo ahora? ¿Cómo funciona el proceso sin su sistema, cómo funcionan los usuarios y clientes? Incluso si aún no hay un proceso, la información detallada sobre el estado actual es muy importante. Entonces entenderemos qué solución solucionará el problema y no crearemos otra.

imagen

Cada opción de implementación tiene sus pros y sus contras, sus recursos necesarios y su nivel de resultado. Después de haber modelado todas las opciones, haber trabajado, o al menos haber hablado esta información con las partes interesadas, podrá tomar una decisión equilibrada e informada.

3. ¿Cómo?


Entonces, entendimos nuestro objetivo y lo que haremos para lograrlo. Queda por descubrir cómo estamos implementando esto: qué páginas mostraremos a los usuarios, en qué forma mostraremos el informe para el cliente, cómo recibiremos datos de otro sistema, cómo los almacenaremos, etc.

Esta etapa es una cuestión de tecnología. Y si ha completado con éxito los dos anteriores, será mucho más fácil.
Aunque la técnica depende del contexto, es útil moverse a lo largo de la "lista de verificación" de Wigers y otras personas inteligentes. Si para usted algún tipo de requisitos no es relevante en este momento, está bien, no lo describiremos. Pero es importante no olvidarse y ponerse a prueba.

imagen

por ejemplo

  • El cuestionario debe contener un archivo con una foto, ya que una foto es necesaria al procesar documentos; este es un requisito comercial . Y tal vez una regla de negocios.
  • - , — . , .
  • , — , . , .
  • base64 . — .
  • , . : 10.

Para cada requisito comercial, por regla general, hay varios requisitos de usuario. Un requisito de usuario se descompone en varios funcionales. Para cada requisito funcional, se deben considerar los requisitos y limitaciones no funcionales.

Además, los requisitos y restricciones no funcionales pueden derivarse directamente tanto de los requisitos del usuario como de los requisitos y reglas comerciales.
De esta manera, los árboles se obtienen de los requisitos, en la parte superior de cada uno de los cuales es un requisito comercial.

imagen

4. ¿Cuándo?


En el "bosque" de sus requisitos, es probable que haya algunos que se excluyan mutuamente y que se repitan. Por lo tanto, es útil documentar y presentar toda esta belleza en forma de tablas y diagramas.

Aquí hay muchas herramientas: por ejemplo, BPMN para describir procesos comerciales y UML para crear esquemas de interacciones entre servicios y componentes.

Si logra explicar a todos qué y cómo quiere hacer con el sistema, usando una servilleta y 3 manchas de café, entonces usted es John Wick de análisis y esto es increíble.

imagen

Sin embargo, como regla, el nivel de detalle "puntual" no le permite ver las trampas y pensar en todos los escenarios posibles. Después de todo, todo parece estar claro, pero dibujé un pequeño diagrama, y ​​aquí tienes un desafío interminable, una rama de proceso olvidada y el camino más corto hacia el oro.
Por lo tanto, es útil saber qué herramientas están disponibles para revertir el caos.

En forma esquemática y estructurada, los requisitos deben priorizarse, dependiendo de la utilidad (el cliente y los usuarios le dirán esto) y la complejidad (el equipo de desarrollo le informará esto).

imagen

Y luego ya puede dispersarse en sprints / etapas de desarrollo e implementación. Bueno, repita estos ejercicios dentro de cada iteración. Y serás feliz: sin alteraciones, un cliente satisfecho, un equipo feliz, un producto que funciona y se beneficia, los elfos tocan el arpa en un arco iris de fondo.

imagen

Por supuesto, siempre habrá problemas. Habrá alteraciones, plazos quemados y errores. No siempre será posible pasar por todas las etapas y hacer análisis normales, aceptar o incluso hablar con el cliente, documentar y rastrear los requisitos. Pero en cualquier situación, comprender "cómo debería ser" ayuda a mejorar el producto. Incluso si en este momento está haciendo "cómo resulta", es consciente de que se está perdiendo y conoce los riesgos. Y si conoce los riesgos, puede manejarlos.

Recomiendo leer más sobre los requisitos en el libro de Wigers and Beatty: "Desarrollo de requisitos de software". Aunque el libro no siempre es simple, pero sí muy útil. La mayoría del otro material sobre el tema es un recuento de estas verdades con diversos grados de libertad.

Gracias por su atención y buen diseño.

More articles:


All Articles