Tabla de contenido del curso
1.
2.
3.
4.
5.
6.
7. < —
8. - -
9.
—
¡A veces parece que la tarea del desarrollador es simplemente obvia! Pero no confíe demasiado en el sentido común para plantear el problema. Para cualquier tarea, incluso la más simple, las discrepancias son posibles, porque la gente tiende a vivir en un mundo de sus propias ilusiones. Por ejemplo, en la República de Cuba se cree que las paredes deben ser brillantes y abigarradas, e incluso si el cliente pide pintar las paredes de blanco, los trabajadores pueden agregar manchas de color, porque "así es más hermoso". Lo mismo ocurre con el desarrollo.
Un documento como los requisitos ayuda a superar el "muro de los malentendidos". La presencia de requisitos le permite crear la misma idea de lo que se debe hacer en el producto, cuál debería ser exactamente la característica.
Cómo se construyen los requisitos
Al formular los requisitos de desarrollo, debe comprender para qué usuario estamos desarrollando el producto. Aquí es donde User Persona resulta útil (ya hemos hablado de ellos aquí ). La Persona del Usuario es el llamado Actor en el sistema, y para cada actor definimos un conjunto de reglas y capacidades.
Por ejemplo, los siguientes actores se pueden definir en una aplicación de foro web:
- El administrador puede hacer todo, literalmente todo, incluida la asignación de roles (personas) a otros usuarios.
- Un usuario habitual solo puede dejar mensajes.
- El moderador puede dejar mensajes, borrar los mensajes de otras personas, prohibir a los usuarios habituales.
En el caso de la aplicación de llamada de taxi, que recordamos periódicamente durante nuestro curso, las personas pueden ser un pasajero, un taxista y un operador.
Para formular un requisito adecuado, debe redactar un documento que llamamos Descripción de características. Y para ello necesitas responder las siguientes preguntas:
- ¿Para qué? ¿Cuál es el propósito? ¿Cuáles son los beneficios comerciales?
- ¿Por qué? ¿Cuáles son los riesgos? ¿Qué perderemos si no lo hacemos? ¿Qué pasa si lo hacemos?
- ¿Qué? ¿Qué problema queremos solucionar? ¿Para quien?
- ¿Cómo? Requisitos funcionales y caso de uso (secuencia de acciones).
También debe prever la presencia de un vocabulario de términos del área temática. Esto es especialmente cierto para acrónimos específicos. Por ejemplo, es posible que el desarrollador no conozca todos los nombres de procesos y los detalles de la industria del acero o la cocina.
Finalmente, el documento necesita crear una sección de “Aprobaciones”, en la que, por un lado, los clientes de la característica (stakeholders, clientes, product manager) acuerdan que la descripción corresponde a lo que quieren del producto. Por otro lado, los desarrolladores (jefes de equipo, arquitectos) confirmarán que la descripción de la tarea en los requisitos es clara y completa. Así, todos los participantes en el proceso de desarrollo deben decir: “Sí, entendemos el documento, ahora se puede hacer”.
Métricas auxiliares
Cuando se trabaja con requisitos, las métricas auxiliares ayudan a lograr una ejecución precisa de la tarea, así como a reducir el tiempo dedicado a verificar el cumplimiento.
- La definición de Terminado es una breve descripción de cómo saber si una función está funcionando.
- Requisitos no funcionales : requisitos para parámetros técnicos como la capacidad de respuesta de la interfaz de usuario, la carga de backend, las limitaciones de CPU y RAM. Este es un punto muy importante, porque si no expresas los requisitos, puedes obtener un monstruo: photoshop incorporado en lugar de simplemente elegir el color del automóvil.
- Requisitos de seguridad : cifrado, almacenamiento de datos personales, etc.
- Corner Case : prueba de casos de borde. ¿Qué pasa si el precio del producto es 0? ¿Cuántos taxis puede pedir una persona al mismo tiempo?
- — , . , , , , — Visa, MasterCard, , .
- . , , , , . , , . , .
- . , “ ”, “ ”.
Requisitos funcionales y no funcionales, casos de uso
Detengámonos un poco en los requisitos funcionales y no funcionales.
Los requisitos funcionales explican lo que se debe hacer, enumeran las acciones de la aplicación como reacción a las acciones del actor. Estos requisitos se implementan en los escenarios de uso enumerados.
Los requisitos no funcionales capturan las condiciones bajo las cuales la solución debe seguir siendo efectiva, o las cualidades que la solución debe poseer. Los ejemplos más comunes de requisitos no funcionales son:
- escalabilidad
- fiabilidad, tiempo de inactividad mínimo,
- métodos de apoyo.
Los casos de uso también se utilizan para describir los requisitos. Este es el elemento principal de nuestro documento, que preparamos al generar una solicitud de función. Los scripts deben proporcionar un algoritmo completo paso a paso de lo que el usuario puede hacer con su aplicación.
Los scripts personalizados generalmente contienen las siguientes secciones:
Sección: Contexto
Responde a la pregunta: ¿Qué componente? ¿Cuál es la condición?
Ejemplo: el usuario no está autorizado.
Sección: Actor
Responde a la pregunta: ¿Qué persona?
Ejemplo: usuario habitual.
Sección: Condiciones previas
Responde a la pregunta: ¿Cuáles son las características?
Ejemplo: hay una invitación para recibir un estado VIP.
Sección:Propósito
Responde a la pregunta: ¿Qué pretende hacer / obtener el usuario?
Ejemplo: iniciar sesión.
Sección: Escenario principal
Responde a la pregunta: ¿Qué acciones se deben tomar para lograr el resultado?
Ejemplo: Ingrese su nombre de usuario y contraseña, presione el botón "Enter".
Sección: Scripts incorrectos
Responde a la pregunta: Qué puede salir mal, una lista de errores, incluido el texto de los mensajes de error para el usuario.
Ejemplo: No se presiona el botón, el idioma no cambia, la conexión no se puede establecer a través del protocolo https, etc.
Sección: Diseños
Responde a la pregunta: Posibles diseños o prototipos de diseño de UI.
Ejemplo: Dibujar en Figma o Sketch.
En una forma simplificada, los scripts personalizados podrían verse así:
Para descubrir
. ( e-mail) ( ). , , : « » « . »
¿Cómo se lee la descripción de la función?
Cada categoría de usuarios puede recopilar información útil para ellos mismos a partir de los requisitos. Por eso es muy importante tener en cuenta que los requisitos serán leídos por diferentes personas:
- Desarrolladores : es importante que sepan por qué se necesita la función y qué problema resuelve. Para no perder tiempo en correcciones más adelante, los desarrolladores deben proporcionar una lista completa de todos los escenarios, así como prestar atención a los casos Corner. Si informa al desarrollador a tiempo sobre lo que añadiremos más adelante, por ejemplo, pagos con tarjeta MIR, podrá prever esta posibilidad a nivel de arquitectura. Por lo tanto, los costos se pueden reducir significativamente al evitar el reprocesamiento.
- , QA — , . Corner Cases. , — , .. ( , , ) . , . .
- DevOps Datacenter Operations— , , , . DevOps , , , .
- — , , . , , .
Si escribe requisitos de desarrollo, asegúrese de hacer la pregunta: quién es su usuario, qué hace (o puede hacer), en qué condiciones se encuentra. Cree un diagrama de su comportamiento, ayudará a describir todos los aspectos de los requisitos.
Al redactar un documento, debe ser lo más breve posible y no dejar lugares incomprensibles. Los requisitos abarcarán varias páginas de todos modos. Debe ser leído por muchas personas y debe ser legible.
Siga una regla simple: comience con lo principal y solo luego agregue detalles. Además, debe obtener comentarios de QA, desarrolladores, DevOps y otras partes interesadas. Lo más probable es que la descripción de la función adquiera nuevos detalles después de la comunicación con las partes interesadas.
Intente pensar en escenarios no obvios. Es aconsejable determinar inmediatamente qué debe hacer su aplicación en situaciones de emergencia. Piense en los componentes externos que afectan su función. Y cuando todo esté listo, vuelva a hacer la pregunta: "¿Qué más puede probar además de los pasos descritos en los scripts personalizados?"
Conclusión
En el próximo artículo, hablaremos sobre el plan de negocios y los precios del nuevo producto.
Mientras tanto, comparta en los comentarios su experiencia de trabajar con los requisitos, tanto del lado del gerente como del ejecutor. Cuéntenos, ¿hubo algún ejemplo en su práctica en el que un cliente funcional quería una cosa, pero al final resultó completamente diferente debido a un malentendido?
→ La grabación de video de todas las conferencias del curso está disponible en YouTube
Lecture sobre la hoja de ruta y los requisitos para el desarrollo: