Creación de clases a partir de análisis

Para este tipo de programas, una descomposición en clases quedaría un poco "forzada", ya que su nivel de complejidad no es tan elevado como para justificarlo.
Aún así, se podría separar la parte visual de la lógica, de modo que se pudiera reutilizar la mayor cantidad posible de código en caso de que más adelante se creara otra versión del programa en un entorno gráfico. Se podría crear una ListaPersonas, de esta manera los datos de cada persona pasarían de ser un struct a ser una clase.

Decisión de tareas a partir del análisis

Una vez realizados todos los requisitos tenemos que decidir las estructuras básicas que se van a emplear.
El programa propuesto es simple y podría realizarse en pocas horas, de modo que la fase de diseño podría reducirse a decidir qué estructuras usar.
Después se estudiará una versión más elaborada del programa, planteándolo como una serie de objetos que colaboran entre ellos.
La estructura de datos del programa podría ser:

• Cada dato se almacena en un struct, y cada struct se almacenará en un vector.

Y las funciones en las que se descompondría podrían ser estas:

• mostrarMenu: muestra la lista de opciones disponibles.
• nuevaFicha: pide los datos de una nueva persona y los añade a la lista.
• verFichas: muestra la primera ficha. Al pulsar sobre algunas teclas el usuario puede elegir si consultar la ficha anterior, modificar la actual o elegir otra.
• modificar(n): pide los campos de la ficha que se indique como parámetro. Si se desea cambiar un dato, se vuelve a introducir el texto. Si no se desea cambiar, bastará con pulsar Intro.
• intentarBorrar(n): si el usuario confirma que desea borrarlos, la ficha se elimina.
• buscarTexto: pide al usuario el texto que quiere buscar, cuenta las fichas y las muestra de una en una. Tras ver todas las fichas, se puede ir pasando de una en una. Si no existen más, la opción de continuar no aparece.
• buscarCumplesMes: muestra las fechas de nacimiento y los nombres y apellidos de las personas que cumplen en un cierto mes.
• guardar: vuelca todos los datos a fichero, reemplazando todo lo anterior a lo que actualmente estás guardando.
• cargar: lee todos los datos desde fichero. Se debe llamar automáticamente al principio del programa.

Diagrama de casos de uso

Un documento de especificación puede ser incomprensible para un cliente que no posea este tipo de conocimientos. Por este motivo, se suelen elaborar diagramas con un contenido más visual.
Uno de los más habituales es el diagrama de casos de uso. En estos, el sistema se representa como un rectángulo, las acciones se incluyen dentro de elipses y se dibujan figuras para simbolizar a diferentes tipos de personas que pueden interactuar con el sistema.
Por ejemplo, una versión mejorada del programa podría incluir al usuario normal, que tendría la capacidad de ver y manipular datos; también podría incluir a un administrador, que éste podría consultar y añadir datos. El diagrama quedaría de la siguiente manera:

Refinamiento

En las empresas de desarrollo de software, suele existir el analista (experto encargado de hablar con los clientes, observar la forma en que este trabaja y además, formular las preguntas adecuadas para el proceso de especificación sea lo más correcto posible). En pequeñas empresas puede que no exista este analista. En estos casos, una segunda lectura puede contribuir a afinar los detalles. Por ejemplo, para el programa del apartado anterior, se podrían detectar las siguientes carencias:
¿ No se podrán consultar los datos si no se hace una búsqueda?
¿Los datos se guardarán automáticamente o deberá seleccionarse, para ello, una opción determinada del menú?
¿Qué datos de cada persona que cumpla años deben mostrarse?
¿Es necesario guardar los datos en fichero usando algún formato específico o no van a compartirse con ninguna otra aplicación?
¿No será necesario modificar ni borrar datos?
Así, en la realización de un proyecto real, es cada vez más habitual repetir la secuencia análisis-diseño-implementación-verificación (proceso que incluye reuniones con el cliente). Es un proyecto de varios meses de duración, y es habitual realizar estas reuniones cada dos semanas.

Prototipos visuales

Una herramienta que puede resultar útil son los prototipos visuales, que consisten en la creación de "maquetas" de pantalla con las que se muestra al cliente una idea de cómo va a ser el resultado.
Los prototipos visuales permiten al usuario detectar si falta algún detalle o si el vocabulario es incorrecto. Por ejemplo, para la agenda de contactos, los ejemplos del margen podrían constituir prototipos visuales de la pantalla de menú, de visualización de datos y de visualización de un resultado de búsqueda.

Especificación

Es habitual elaborar un documento en el que se recopilen los requisitos que debe cumplir el programa, éstos podrían reflejarse en una lista de cosas que el programa tiene que hacer. Aunque hay que distinguir entre requisitos funcionales y técnicos.
Para un programa no muy complejo podríamos tener la siguiente lista:

• El programa será una agenda de contactos que te permite guardar información para consultar después.
• Deberá almacenar la información de cada persona, siendo lo único obligatorio el nombre.
• Permite guardar muchos datos.
• Los datos se guardarán en fichero para disponer de ellos cuando se acceda al programa.
• Permite buscar datos a través de una palabra introducida en la búsqueda.
• Buscará las personas que cumplen años en los próximos 30 días.
• Deberá estar creado en C++ y permitirá trabajar en modo texto, para compilar tanto en Windows como Linux, u otra versión.

Características del análisis de requisitos.

Si se desea crear un programa, el primer paso es pensar qué tareas se deben realizar. En un programa para uso propio, esto puede parecer poco importante, pero si es una creación por encargo, es muy importante.
Si creas una lista con los requisitos que debe cumplir el programa favoreces la orientación del trabajo, la determinación de las tareas importantes.... Lo más importante en un proyecto a medida es el establecimiento del momento en el que el proyecto se pueda dar por terminado. Así podemos evitar que el programa crezca indefinidamente.
Una vez estimado el tiempo necesario y aprobado el presupuesto, se deben anotar las  características nuevas para realizar una versión posterior, lo que conlleva volver a calcularlo todo.