Al escribir requisitos, a menudo surge la pregunta de hasta qué nivel vale la pena detallar los requisitos y qué artefactos deberían aparecer como resultado del análisis del sistema.
Intento adherirme a la posición de que esto es puramente individual y depende del equipo y de quién se siente cómodo trabajando. Sucede que el caso de uso es suficiente para que los desarrolladores hagan el diseño, y para los probadores es suficiente escribir casos de prueba. Por lo tanto, escribiré sobre los artefactos que pueden surgir al redactar los requisitos y en los que debe pensar exactamente cuando se complete el desarrollo, y usted mismo decide y acepta dentro del equipo cuándo vale la pena describirlo. Es inequívoco que al final del desarrollo, la documentación debe contener todo lo que se discutirá más adelante.
Si no tiene en cuenta las características pequeñas, cuya implementación implica mejoras menores, simplemente puede realizar cambios en las descripciones existentes. De manera sistemática, podemos distinguir dos tipos de tareas que entran en el trabajo de un analista de sistemas y deben describirse de diferentes maneras:
La tarea de desarrollar un nuevo servicio o una nueva funcionalidad que solo afecta indirectamente a otros sistemas o componentes.
Tareas, cuya implementación implica mejoras en varios sistemas por proceso (y, como usted sabe, los sistemas a menudo están segmentados por proceso, y una característica comercial generalmente pasa por todo el proceso y requiere mejoras en varios sistemas)
Para describir las tareas del primer tipo, identifiqué la siguiente estructura y bloques de descripción:
Requerimientos generales
Un bloque que asume la designación del contexto. Qué tipo de sistema es, para qué sirve, qué objetos contiene, cuáles son sus límites.
- objetivo
-
, ,
-
, , . , Confluenc , , , ,
-
, . , .
, , .
, , , . , , .
, , ,
, ( ), , .
(Use case)
, . . , UML-
UML. .
, , / . .
ER-.
, . , , , . . , , , .
, , ( ). .
-
, , \ . , , , ( ).
-
, swagger ( ), ( ), ftp .
.
:
, , , , , . ( ).
:
, . , .
(Use-case)
.
Es más fácil mostrar las interacciones del sistema y los flujos de datos para la implementación. Es necesario descomponer toda la funcionalidad en sistemas en términos de datos, llamadas y disparadores. indicar todas las relaciones y dependencias de las tareas. Más detalles ya a nivel de cada sistema por separado.