¿Cuándo termina el análisis de un sistema de información?

Una de las preguntas más comunes tiene que ver con poder responder cuando una fase se ha cumplimentado en un ciclo de desarrollo de un producto de software. 
Suele ser común que la respuesta no sea única y cuando hacemos la pregunta:
¿Cuándo termina el análisis de un sistema de información?
No resulta sencillo dar respuesta, pues depende de algunos factores. 

Requerimientos estables
El primero y más importante es haber logrado estabilizar los requerimientos del sistema con el usuario. Una tarea que no siempre resulta sencilla.

Lograr la consistencia del modelo
A pesar de haber logrado el modelo de análisis, el analista tiene que asegurar por lo menos, que hay consistencia técnica en el modelo planteado.
Esto es, que no falten requerimientos menores, que las reglas que se plantean se respeten, que la idea de solución cierre como un todo. 
Aquí se cruzan las decisiones tomadas en los diferentes modelos: Ejemplo chequear que lo que hace el sistema sea posible de acuerdo a la memoria modelada, que la memoria modelada se integre con la información que el sistema debe producir, que se encuentren todos los requerimientos que permiten mover los estados de cada objeto, entre otras. Nota: hay más de lo que uno piensa.

Nivel de detalle adecuado
En más de una ocasión se logró lo anterior, pero cuando pasa la especificación del analisis al diseño o la programación (debería primero pasar al diseño...:)); encontramos que nuestros sucesores requieren aclaraciones. Estas aclaraciones pueden resultar de una documentación pobre o incompleta, cosas que no son lo mismo.
Si el analista recibe preguntas continuamente de sus sucesores, entonces el análisis no ha terminado.

Juntando pruebas para estimar el esfuerzo

Desde el comienzo cualquier oráculo (lease libro, incluye libros electrónicos) dirá que la estimación es una aproximación. Con esto básicamente todos los autores se lavan las manos e introducen alguno de los riesgos siguientes: subestimar o sobreestimar el esfuerzo de un proyecto de software. Estos son riesgos gemelos que nunca se verán (claro, cuando uno se presenta el otro no lo hace). 
Al estimar ya se introducen los 2 riesgos, pero uno solo se materializará. La única certeza es que uno de los 2 se hace presente. Nunca, pero nunca estimarás y concidirá con la realidad. JAMÁS. 
Superada esa necesidad de ser perfecto, como todo informático, alcanzarás el paraíso, aunque sea mientras estimás.
Lo único que podés hacer es reducir la incertidumbre, para ello debes hacer historia. Y todos sabemos que la historia se recuerda si se registra. Entonces lo que debes hacer es:

1.  Registrar la estimación, registrar los requerimientos que se estiman, los supuestos y las fuentes.
2. Monitorear tu proyecto. Hacer un registro de las circunstancias, hechos e impresiones detectadas.  Hacé un bitácora, si, una bitacora, como la de la película (film) de viaje a las estrellas.
3. Registrar el trabajo real
4. Llevar adelante un lecciones aprendidas o bien, una restrospectiva del proyecto.

Con loselementos mencionados juntarás la prueba que avalará tus decisiones.

Las pruebas según el CMMI: (esto es una visión totalmente personal, no está escrito en CMMI)

1. Nivel 1. Inicial. Arranco y dejo. Comienzo y abandono. Resultado: material incompleto. Moraleja: perdiste el tiempo; pero aprenderás. Aprenderás que así no funciona.
2. Nivel 2: generás tu historia, pero como lo haces a tu modo. Resultará útil solo para ti, pero  poco utilizada para otros. Te vuelves cada vez menos aproximado, pero nunca serás certero. Habrá quienes te crean y quienes te lean. Resultado: Tu sabes la verdad. Los desvíos son menos que en otros tiempos. Ups de repente tengo capacidades especiales (el poder X de estimar). Ojo hay otros heroes que juegan igual.
3. Nivel 3. La organización se preocupa y ocupa por cumplir los pasos mediante un mecanismo uniforme. Los datos ahora son comparables. Hay aprendizaje organizacional.
4. Nivel 4. Hay indicadores que regulan a la estimación. La organización cree en esos indicadores. Quien se corre de los indicadores es un disidente.
5. Nivel 5. Lo dejo a tu criterio.

Conclusión 
Estimar es una experiencia unica para quien cumpla con esa función, pero debe procurar aprender de sus errores o falsas visiones. Eso lo mejorará radicalmente como profesional. Los pasos son fundamentales para demostrar que soy serio al momento de hacer mi trabajo.

¿Cuál requerimiento analizo primero?

No resulta fácil distribuir el trabajo del análisis, y esto es por varias razones. 
La razón que vamos a trabajar aquí tiene que ver con las dependencias entre los requerimientos. Supóngase que tiene 10 casos de uso de usuario (no historias de usuario, hablo de casos de uso 😡) y el análisis lo tiene que distribuir entre 2 analistas o más.¿Cuáles son los casos que asigna a un analista y cuáles a otros?¿ Pueden comenzar los analistas a trabajar en paralelo?¿Debe haber una coordinación?

Para la explicación voy a plantear un ejemplo, pues transcribir el enunciado lo haría muy pesado. Estimado lector vas a tener que creerme que es así

El ejemplo trata de un sistema de información para cumplir con la meta de Realizar giras de álbumes de cantantes que los promocionan.
La matriz de dependencias de requerimientos que se plantea ( y no puede discutirse) es la siguiente:

		1.01	1.02	1.03	1.04
1.01	Definir Gira	---
1.02	Confirmar Gira	Si	---
1.03	Cerrar Gira	Si		---
1.04	Cerrar Presentación				---

¿Cómo se lee?
un cambio en el caso de uso de 1.03 afecta o impacta al caso de uso 1.01. Nota: recuerde que un caso de uso es un conjunto de requerimientos, principalmente funcionales)

Sin importar cuantos analistas hay, con la matriz de dependencias se puede evidenciar que los análisis de los casos de uso no son paralelos. Si se analiza el caso de uso 1.01, luego cuando se analice el caso de uso 1.03, el caso de uso 1.01 se modificará. 
Entonces está solución no aplica:

mientras que esta solución si:

Conclusión
La segunda programación es más realista y factible. Esto es independientemente de los recursos que se asignen.
Falta trabajar un poco más en la programación, pero esta segunda opción sin dudarlo es mejor que la primera.

Requerimientos versus casos de uso

Lo que voy a comentar puede no ser una novedad, pero es importante no perderlo de vista.
Un caso de uso con alcance sistema es una descripción de un conjunto de requerimientos organizados y pensados para ayudar a cumplir las metas de un actor. Si necesitas especificar requerimientos te sirven los casos de uso de alcance sistema.

Las definiciones enunciadas son parciales y mejorables, aunque espero te ayuden a entender hacia donde vamos. Como se dice por ahí: "los casos de uso son requerimientos y esencialmente de requerimientos funcionales"

Hoy en día no dudo en utilizar casos de uso como un método para especificar requerimientos y luego ir desarrollándolos (o completándolos).

Los casos de uso vinieron a cubrir ciertas necesidades de especificación y trabajo con los requerimientos, abandonando o dejando de lado la lista de requerimientos; pero la lista de requerimientos no ha muerto.

Hoy los casos de uso se han transformado en los favoritos de los analistas en sistemas de información, teniendo sobradas razones para serlo, pero la lista de requerimientos se sostendrá por mucho tiempo.

Los casos más significativos en donde la lista de reqeurimientos suele ser mejor especificación que los casos de uso se ven en:
no hay workflow, cuando los procesos no pueden precisar secuencias, cuando se trata de una serie de sub-características que debe poseer una aplicación, o cuando los requerimientos no funcionales son la razón de la aplicación, entonces allí la lista de requerimientos domina el territorio.

Pero atención no tienes que decidirte por una, puedes elegir cual usar según el momento, y por supuesto existirán variantes.

Ejemplo 1
Suponga que un actor, el recepcionista de una organización, en su trabajo diario debe escribir gran cantidad de texto sobre campos VARCHAR. El recepcionista en pos de mejorar su trabajo y mejorar el resultado solicita poder copiar y pegar texto, agregar negritas, itálicas, subrayados y cambios de tamaño.
Este tipo de requerimientos  o características es  mejor especificarlos en listas de requerimientos. Intentar organizar estos requerimientos bajo la imagen de un caso de uso no sirve.

Ejemplo 2
Un líder de proyecto indica que desea crear un proyecto y,  para ello define las tareas, luego los recursos, asigna recursos a tareas, las tareas a recursos, borra tareas, cambia recursos, indica costos, a veces decide calcularlos, otras no.
Este caso presenta otra complejidad. Aquí armar un caso de uso  presenta múltiples escenarios y se torna muy engorroso plantearlos a todos. Es más práctico una lista de requerimientos.

Debo reconocer que prefiero los casos de uso a la lista de requerimientos, pero no siempre es aplicable.
Es importante decidir cuando conviene una cosa y cuando otra.

Oportunidad de Mejora

Definición
Denomino oportunidad de mejora a la incorporación, modificación de ciertas cualidades y/o características del negocio y/o sistema que le proveen de una optimización significativa, mejorando algún aspecto del negocio y/o sistema actual.

Las oportunidades de mejora se presentan a lo largo del estudio del sistema al compartir con terceros la visión, los problemas actuales, el objetivo y los requerimientos del sistema de información.

Es muy común que al describir expresiones de deseo encontremos nuevas ideas por el solo hecho de compartir nuestra forma de ver/pensar un sistema, un componente, etc.

La oportunidad de mejora es, parafraseándola, encontrar una mejora a lo que ahora se realiza o se va a realizar.

Las oportunidades de mejora se ven restringidas por posibilidades técnicas o tecnológicas, de costo, de recursos o de tiempos, entre otras.

Ejemplos

1. En un sistema de ventas  con atención en mostrador, podría sugerirse que las personas que son clientes y realizan periódicamente los mismos pedidos, lo hagan por la web. Así la organización tiene dos mecanismos de ventas aumentando las oportunidades del negocio y mejorando la atención de cierto grupo de clientes.

2. Actualmente el sector de ventas realiza presupuestos, los imprime y se los remite por correo tradicional al cliente, previa llamada telefónica.
Hoy el presupuesto podría generarse como un archivo PDF, enviarse por correo electrónico al cliente y si se  posee el celular del responsable se le comunica mediante un SMS del envío.

3. En un negocio pequeño, el tomador de pedidos realiza la solicitud el pedido en forma manual en papel, repitiendo gran cantidad de datos del cliente en cada ocasión que este realiza un pedido. A través de un sistema automatizado ciertos datos ,como los personales, no serían obligatorios cada vez que se realiza la toma de un pedido.

Los ejemplos son numerosísimos... agregá otros....