El documento discute estrategias y tácticas para el trabajo con requerimientos de software. Propone un proceso iterativo de planificación, ejecución, evaluación y acción. También destaca la importancia de especificar requerimientos funcionales completos, correctos y no ambiguos, así como el uso adecuado de casos de uso y diagramas para moldear requerimientos.

1. Estrategias y tácticas en el trabajo con requerimientos
El trabajo con los requerimientos depende de las características del proyecto
y de la metodología con que se trabaje, colocamos un mini proceso que ira
creciendo con el proyecto nos permitirá cubrir proyectos grandes tipo
wordshop, terminado así con la participación de un analista entrevistando a un
usuario.
Este modelo propone planificar, hacer, verificar y actuar esto es común en
proyectos medianos y chicos desarrollar el elevamiento de requerimientos y su
análisis sin planificación alguna habrán reuniones con los usuarios para hablar
de sus necesidades. En su fortaleza consiste en que organizar el trabajo de
esta forma requiere de la participación de todos los involucrados , su debilidad
en que para que esto sea posible se requiere una madurez importante de todas
las partes.

2. Planear permite
Conocer el propósito de la reunión
quienes participaran preparar la
documentación
Planear evita
Reunión en la que se enteren del
motivo de esta postergaciones para
próximas reuniones por falta de
información y falta de documentación
Ejecutar permite
Desarrollar la reunión de la manera
planeada en el lugar establecido, en
los tiempos planificados con las
personas indicadas y definidas
Ejecutar evita
No contar con sala para el desarrollo
tratar temas dispersos con escaso
valor agregado
Evaluar permite
Ordenar los resultados de las
reuniones y publicarlos a todos los
involucrados contar con modelos
sobre los cuales basar los acuerdos
Evaluar evita
Generar sensación de que el esfuerzo
anterior fue en vano falta de acuerdo
por falta de visibilidad
Actuar permite
Mejorar y aprender de la forma de
trabajo corregir y hacer ajustes en la
dirección apropiada para el proyecto
Actuar evita
Repetir errores de organización
ausencia de conducción y sensación
de falta de gestión

3. Tácticas
Especificación de requerimientos de software y sus atributos de calidad
Derivado a partir del relevamiento de las necesidades del usuario estos
requerimientos funcionales expresan la totalidad que el sistema brindara hemos
observado errores de los más diversos cuando se trabaja de esa forma y con
esos diagramas sin pasar previamente por un listado de requerimientos que
cumplan con atributos tales como (gottesdiener; ellenn: 2002, op.cit)
 Completitud
 Correctitud
 No ambigüedad

4. Especificación de casos de uso
Uso como forma de moldear requerimientos hoy se sigue usando mal y de
manera excesiva estos diagramas la tentación creada por las herramientas
CASE que facilitan la creación de dichos artefactos hace que muchos
desarrolladores solo construyan estos diagramas sin ninguna especificación
textual de los casos de uso otro abuso y mal uso se debe a la utilización de
relaciones entre casos de uso en nuestra experiencia las relaciones útiles son
las de inclusión y extensión la razón es que si bien las herramientas facilitan su
diagramación ,es muy confusa su especificación textual los mejores libros que
tratan el tema de casos de uso son advanced use case modeling y use case
madeling, es muy importante darle claridad y consistencia a los diagramas de
este tipo definiendo ,al nivel del grupo el significado de las palabras claves
también es importante hacerlo cuando se listaron los requerimientos en aquel
caso para todos los involucrados en el proyecto