Programa educativo para especificaciones técnicas.

Beneficio: conozca qué es TK y cómo compilarlo. Enriquezca su vocabulario con palabras: modelo conceptual, flujo de datos, tarjeta mental, flujo de usuarios. casos de uso, wireframes, modelo ER, cliente-servidor, API.

Para quién: desarrolladores novatos y aquellos que quieren ser entendidos (por clientes, startups y gerentes).

Tiempo de lectura: 7 minutos.

Punto de partida - requisitos

¡Quiero un pastel, luego helado!
Vovka en el lejano reino lejano

Existe una idea errónea común de que es suficiente decir: "Se necesita una solicitud para un museo / gato / planta" e inmediatamente quedará claro lo que necesita.

Lamentablemente, esto no es tan simple. Imagina que necesitas construir una casa. Vas al constructor y él se pone a trabajar. No le proporcionó ningún dibujo o trama, ni siquiera le dijo de qué color debería ser la cerca. Pero dieron todo sobre todo durante seis meses y una cantidad significativa de dinero.

Revelación
.

¿Terriblemente cierto? El presupuesto ya se ha gastado y la fecha límite ha expirado.

Para evitar que esto suceda, todos los requisitos para el producto son fijos, esto es con lo que cualquier desarrollo comienza.

Tipo conveniente de requisitos - TK

Amasar y picar!
Vovka en el lejano reino lejano

Bueno. Hay requisitos Ahora los desarrolladores definitivamente te entenderán. Pero aquí viene la trampa # 1: la humanidad aún no ha aprendido a leer las mentes. Por lo tanto, es necesario de alguna forma transmitir información y la mejor manera de hacerlo son los Términos de Referencia.

También se llama TK, SRS, PRD: todos estos son los nombres del documento en el que los requisitos del producto se fijan en la forma correcta.

Peligro No. 2: la memoria de una persona no es ilimitada, siempre es mejor tener un lugar donde se arreglen todos sus deseos y requisitos (no correspondencia en un telegrama o llamada telefónica). Por lo tanto, TK es un documento de texto impreso con la aplicación de diagramas e infografías, no escrito a mano o fotografiado. Lo mejor en formato .PDF o Google Docs.

Receta para conocimientos tradicionales


Los términos de referencia para desarrolladores son una especie de receta para un producto exitoso. Un producto exitoso es uno que es fácil de mantener, puede desarrollarse y cambiarse, no se desmorona cuando un desarrollador cambia y obtiene ganancias de cualquier forma. ¿Quieres que tu proyecto esté completo? Multa. Escribe una buena receta para esto. Los ingredientes clásicos (según el estándar internacional IEEE-830) son:

  • Modelo conceptual
  • Tarjeta funcional
  • Ruta de usuario
  • Interfaz de usuario
  • Interfaces de software
  • requerimientos no funcionales

Los últimos 2 puntos son específicos, les aconsejo que presten atención a los lectores cercanos al desarrollo.

A continuación analizaré en detalle cada uno de los elementos. Para aquellos que no quieren entender en detalle, les dejo un enlace al estándar internacional con una plantilla de tarea técnica: enlace a un documento.

imagen

Modelo conceptual


Este artículo incluye una breve descripción del producto, refleja el propósito del proyecto y sus características distintivas.

Por ejemplo: "Una aplicación de citas donde puedes ver videos cortos en los perfiles de usuario y chatear". También es bueno decir algunas palabras sobre la audiencia del producto, para que el equipo del proyecto pueda comprender sus características y darle algunos consejos útiles. Cuéntanos sobre su edad, carácter y ubicación territorial, algunas características que deberían afectar el proyecto.

Por ejemplo: "Estos son jóvenes que viajan al extranjero por placer y están interesados ​​en la comunicación fuera de la barrera del idioma, a quienes les gusta tomar fotos y videos".

Vale la pena hablar sobre los tipos de usuarios y sus diferencias clave.

Por ejemplo:“La aplicación debe tener usuarios y moderadores regulares que reciban quejas de los usuarios sobre contenido o perfiles. Los moderadores pueden ver el chat de los usuarios comunes después de una queja y bloquear una cuenta que viole las reglas del servicio ".

Y finalmente, cuéntenos sobre los componentes de su producto.

Por ejemplo: panel de administración utilizado por moderadores; Una aplicación móvil que el usuario utiliza para registrarse, agregar contenido, participar en el chat, etc.

Las acrobacias aéreas se realizarán mediante el llamado flujo de datos o gráfico de contexto, que reflejará cómo los usuarios interactúan con el producto, sus componentes y entre sí.

Tarjeta funcional


El mapa funcional muestra el concepto general del proyecto con el nivel de detalle necesario para evaluar el alcance del trabajo y priorizar.En un formato tradicional, dicho mapa se asemeja a un mapa del sitio. Pero es más conveniente mostrarlo en forma de una tarjeta mental (tarjetas mentales, tarjetas de inteligencia). A menudo, los gerentes dibujan palabras en la reunión en una pizarra o en un pedazo de papel y las conexiones entre ellos, y este es el mapa mental. Esto se puede hacer convenientemente en servicios gratuitos (coggle, draw.io y mindmeister) o simplemente en Office Word.

Es muy importante reflejar todas las características del usuario en el mapa funcional. En una primera aproximación, esto es simplemente un conjunto de características del producto.

Por ejemplo: “La aplicación debe incluir el registro por correo, la creación y el llenado de datos de perfil, la capacidad de cargar y editar fotos y videos, una lista de las cuentas de otros usuarios con varios tipos de filtros, chat de texto y contacto con el soporte.

imagen

Ruta de usuario


El llamado flujo de usuario, o ruta de usuario, es una lista secuencial de acciones o pantallas que el usuario puede atravesar al interactuar con el producto. Describa cómo interactuará el usuario con el producto en su presentación. Muy convenientemente, esto también se puede hacer con un mapa mental o simplemente con una lista de acciones.

Por ejemplo: “Un usuario inicia sesión para encontrarse con sus compañeros. Llena su perfil con datos y sube fotos y videos. Luego, el usuario ingresa el feed y lo filtra de acuerdo con algunos criterios. Como resultado, recibe una lista de perfiles relevantes, puede mirarlos y escribir a otro usuario en el chat.

La ruta del usuario es un algoritmo general para trabajar con el producto. También hay casos de uso (casos de uso): este es un detalle del flujo de usuarios. En el caso de una aplicación de citas móvil, creó la ruta del usuario a través de las pantallas y luego describió lo que el usuario puede hacer en cada pantalla.

Por ejemplo: en la pantalla de registro, el usuario puede:
ir a la pantalla de autorización , registrarse a través de las redes sociales (Facebook, Twitter), ingresar el correo electrónico, la contraseña, luego repetirlo y confirmar el registro en el correo electrónico.

imagen

imagen

Interfaz de usuario


El producto no solo debería funcionar, sino también verse bien. Alejémonos un poco del tema de las aplicaciones, para no forzarlo a descargarlas para su revisión. Mejor mira sitios lindos:


Observamos un ejemplo de diseño deficiente, ahora limpie la sangre de los ojos y pasemos a la discusión de la interfaz. En esta parte de la tarea técnica, vale la pena adjuntar árbitros, ejemplos de cómo desea ver su producto. Pueden ser análogos de desarrollos similares o simplemente ejemplos cuyo diseño te haya gustado.

Describa en términos generales cómo desea ver su producto, qué colores debe tener, qué elementos usar, qué animación desea, etc. Si tiene una identidad corporativa o un libro de marca, excelente, consúltelos.

Los diseñadores le agradecerán mucho si especifica un estilo de diseño de interfaz, como diseño plano o diseño de material.

Aerobatics agregará wireframes (wireframes) - prototipos de la interfaz del producto en forma de circuitos aproximados.

imagen

Interfaces de software


Esta sección es para profesionales. Si tiene confianza en sus habilidades, continúe leyendo. La mejor tarea técnica también describe la arquitectura del producto, es decir, en qué componentes de software se compone. En el caso de una aplicación de citas cliente-servidor, el servicio se divide en una parte del servidor que almacena datos y los procesa, realiza algunas operaciones lógicas y una parte del cliente que muestra los datos.

El servidor se descompone en módulos: bases de datos, autenticación, chat, etc. El cliente se comunica con el servidor a través de API (interfaces de transferencia de datos), debe indicar su tipo (REST, WEB, RPC, etc.) y describir los métodos, respuestas y manejo de errores.

Los datos generalmente se almacenan en la base de datos en forma de estructuras especiales, a menudo tablas (para bases de datos relacionales) y estructuras json (para no relacionales). Los desarrolladores le agradecerán mucho si en la tarea técnica especifica las entidades de la base de datos (modelos ER) y describe los campos almacenados, indicando sus tipos de datos (cadena, int, etc.), claves (primarias, externas), obligatorias (requeridas ) y anulables.

imagen

requerimientos no funcionales


Estos son requisitos generales del producto. Se pueden dividir en requisitos técnicos, requisitos de seguridad y requisitos de rendimiento.Los requisitos técnicos indican los deseos para los dispositivos y el entorno operativo, por ejemplo, para aplicaciones de citas, estos son Android 7.0+ y JDK 8+, iOS 11.0+ y Swift 4.2.

En los requisitos de seguridad, puede especificar que la transferencia de datos en el chat se debe realizar utilizando el cifrado SHA-1 y que al registrarse, la complejidad de la contraseña debe ser de al menos 8 bits. para leer un mensaje de chat durante no más de 1 sy que la aplicación almacena parcialmente el caché y puede funcionar sin conexión durante un tiempo limitado.

Consejo


  1. PDF, . , .
  2. , , , .
  3. -, , .
  4. , , .
  5. . , .
  6. Prepárese para pasar más de unos días o consulte a un profesional para escribir un artículo. Los términos de referencia competentes lo salvarán de largas discusiones de detalles con los desarrolladores y delinearán criterios claros para la entrega del proyecto. Por ejemplo, un TK completo de acuerdo con el estándar IEEE-830, adjunto al contrato de desarrollo, es un argumento en la corte en caso de incumplimiento de los requisitos.

All Articles