Requerimientos de Software

Apuntes para el Final

Contenido
Unidad 1: Ingeniería del Software ........................................................................................................................... 3
Qué es el software............................................................................................................................................... 3
Características del software ................................................................................................................................ 3
Ingeniería de software ........................................................................................................................................ 3
Importancia de aplicar un Proceso de Ingeniería............................................................................................ 3
Crisis del software: .......................................................................................................................................... 3
Proceso de software ............................................................................................................................................ 3
Modelo de proceso de software ......................................................................................................................... 4
Proceso unificado de desarrollo .......................................................................................................................... 4
Calidad en un producto de software ................................................................................................................... 5
Relación Calidad-Métrica ................................................................................................................................ 6
Estudios de factibilidad ................................................................................................................................... 7
Unidad 2: Ingeniería de requerimientos de software ............................................................................................. 7
Requerimientos funcionales y no funcionales .................................................................................................... 7
Requerimientos funcionales............................................................................................................................ 7
Requerimientos no funcionales....................................................................................................................... 7
Requerimientos del dominio ........................................................................................................................... 8
Requerimientos del usuario ............................................................................................................................ 8
Requerimientos del sistema ............................................................................................................................ 8
Requerimientos verificables ............................................................................................................................ 9
Documentos de requerimientos de software ................................................................................................. 9
Proceso de ingeniería de requerimientos ........................................................................................................... 9
SRS/ERS.............................................................................................................................................................. 10
Características de un SRS: ............................................................................................................................. 10
Unidad 3: Captura y gestión de requerimientos ................................................................................................... 11
Obtención y Análisis de Requerimientos e Interfaces ...................................................................................... 11
Validación de Requerimientos .......................................................................................................................... 12
Gestión de requerimientos ............................................................................................................................... 12
 Técnicas de recolección de información ........................................................................................................... 13
Entrevistas ..................................................................................................................................................... 13
Cuestionarios ................................................................................................................................................. 14
Desarrollo Conjunto de Aplicaciones (JAD) ................................................................................................... 14
Brainstorming (tormenta de ideas) ............................................................................................................... 14
Unidad 4: UML y herramientas CASE .................................................................................................................... 15
Desarrollo de software orientado a objetos ..................................................................................................... 15
Modelos de Casos de Uso ................................................................................................................................. 16
Actores .............................................................................................................................................................. 16
Casos de uso ...................................................................................................................................................... 16
¿Qué es UML? ................................................................................................................................................... 16
Ejemplos de diagramas UML: ............................................................................................................................ 17
Diagrama de clases ........................................................................................................................................ 17
Diagrama de objetos ..................................................................................................................................... 17
Diagramas de casos de uso ........................................................................................................................... 17
Diagrama de Estados ..................................................................................................................................... 17
Diagrama de secuencias ................................................................................................................................ 17
Diagramas de actividades .............................................................................................................................. 17
Diagrama de colaboraciones ......................................................................................................................... 17
Diagrama de componentes ........................................................................................................................... 17
Diagramas de distribución ............................................................................................................................. 18
Unidad 5: Captura y gestión de requerimientos ................................................................................................... 18
Importancia de los métodos formales .............................................................................................................. 18
¿Qué son los métodos formales? .................................................................................................................. 18
Qué es el OCL .................................................................................................................................................... 18
Unidad 1: Ingeniería del Software

Qué es el software
El software es una serie de instrucciones que cuando se ejecutan, proporcionan características,
funciones y el que se busca para ciertas tareas. Estas estructuras permiten que los programas
manipulen de forma adecuada información para satisfacer una necesidad dada. Para entender la
definición de lo que es el software, es importante hacer una diferencia entre estos sistemas
lógicos y los seres humanos, o sistemas físicos, siendo así también diferenciados del hardware.

Características del software

El software se desarrolla, modifica con intelecto, no se manufactura.
Aunque existan similitudes entre el desarrollo de software y la fabricación de hardware, las dos
actividades son fundamentalmente diferentes. Es cierto que, entre ambas, una buena calidad se logra
a través de un buen diseño, pero la fase de manufactura del hardware introduce problemas de
calidad que no existen en el software. Ambos dependen de las personas, más no la relación entre los
individuos involucrados en el proceso de creación.
El software no puede considerarse un proyecto de manufactura.
El software no se “desgasta”.

Ingeniería de software
Aplicación sistemática de un conjunto de técnicas y procedimientos para mejorar el desarrollo de
software. El uso de los principios de ingeniería para obtener productos software de forma mantenible
(costeable), fiable y eficaz.

Importancia de aplicar un Proceso de Ingeniería

Se utilizan para llevar un orden, establecer prioridades en las actividades y tener objetivos claros en
el desarrollo de software de forma mantenible (costeable), fiable y eficaz.

Crisis del software:

Surgió en una conferencia en 1968, trataba sobre las dificultades que en ese entonces se
debían enfrentar al crear software, debido a la dificultad en los procesos de creación. Para
resolver estos problemas se desarrolló una nueva rama de la ingeniería, llamada Ingeniería
de Software.

Proceso de software
Es un conjunto de actividades y resultados asociados que producen un producto de software. Define
quién hace qué, cuándo y cómo para alcanzar cierto objetivo.
Existen 4 actividades fundamentales de procesos que son comunes para todos los proyectos de
software.

1. Especificación del software, donde los clientes e ingenieros definen el software a producir
y las restricciones sobre su operación.
2. Desarrollo del software donde el software se diseña y programa.
3. Validación del software donde el software se válida para asegurar que es lo que el cliente
requiere.
 4. Evolución del software donde el software se modifica para adaptarlo a los cambios
requeridos por el cliente y el mercado.

Diferentes tipos de sistemas necesitan diferentes procesos de desarrollo, así que cada actividad
puede organizarse de diferentes formas y describirse en diferentes niveles de detalle según la
necesidad.

Modelo de proceso de software

Un modelo de procesos de software es una descripción simplificada de un proceso del software que
presenta una visión del proyecto en cuestión. Estos modelos pueden incluir actividades que son parte
de los procesos y productos de software, y el papel de las personas involucradas en la ingeniería de
software. Algunos tipos de modelos pueden ser:

1. Modelo de flujo de trabajo: muestra la secuencia de actividades en el proceso junto con sus
entradas, salidas y dependencias. Representa las acciones humanas.

2. Un modelo de flujo de datos o de actividad: Representa el proceso como conjunto de

actividades, cada una de las cuales realiza alguna transformación en los datos. Muestra como
la entrada en el proceso, tal como una especificación, se transforma en una salida, tal como
un diseño. Representa transformaciones hechas por las personas o computadoras.

3. Modelo de rollación: representa los roles de las personas involucradas en el proceso del
software y las actividades de las que son responsables.

La mayor parte de los modelos de procesos del software se basan en uno de los tres modelos
generales o paradigmas de desarrollo:

1. El enfoque en cascada: Considera las actividades anteriores y las representa como fases de
procesos separados, tales como la especificación de requerimientos, el diseño del software, la
implementación, las pruebas, etc. Después de cada etapa, se “firma” y el desarrollo continúa.

2. Desarrollo interactivo: Este enfoque entrelaza las actividades de especificación, desarrollo y

validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones muy
abstractas. Este se refina basándose en peticiones de clientes, con el plan de satisfacer sus
necesidades.

3. Ingeniería del software basada en componentes: Esta técnica supone que las partes del
sistema existen y se enfoca en la integración de aquellas partes más que desarrollarlas.

Proceso unificado de desarrollo

El proceso unificado de desarrollo es una metodología de desarrollo de software que está basado en
componentes de interfaces definidas junto al UML, de tal forma que es el método más utilizado para
el análisis, implementación y documentación de productos de software. Por lo general, no se tiene
una cantidad de pasos establecidos, sino que son muchas técnicas que se adaptan al contexto de
cada desarrollo y depende de la necesidad. Cada fase representa un ciclo de desarrollo en la vida de
un software:
 1. Fase de inicio: que tiene como finalidad definir la visión, objetivos y alcance del proyecto,
tanto desde el punto de vista funcional como técnico, y de esta manera, se obtienen una
lista de casos de uso y factores de riesgo del proyecto.

2. Fase de elaboración: completa el análisis de los casos de uso, y define la estructura

principal del sistema, además de obtener una aplicación ejecutable que responde a los
casos de uso analizados con anterioridad. La arquitectura del sistema depende de los
requerimientos analizados y del alcance que se definió.

3. Fase de construcción: está compuesta por varias iteraciones, en las cuales se van
incorporando cada vez más casos de uso, de acuerdo a los factores de riesgo que se
analizaron en la primera fase. Este enfoque permite contar en forma temprana con el
sistema que va a satisfacer esos casos de uso que identificados.

4. Fase de transición: este re se refiere a cuando el sistema está instalado, siendo una
versión beta del sistema o el programa completo.

El proceso unificado de desarrollo agrupa las actividades en 9 flujos de trabajo principales, los cuales
son:
1. Modelo de negocio: describe e identifica quiénes participan y las actividades que
requieren automatizaciones.
2. Requerimiento: define lo que debe hacer el sistema y se identifican las funciones
requeridas y las restricciones que tiene.
3. Análisis y diseño: describe como el sistema será realizado con respecto a la funcionalidad
prevista y las restricciones impuestas, siendo estas programadas.
4. Prueba: Busca los defectos a lo largo de todo el ciclo de vida
5. Instalación o despliegue: se termina de confeccionar el producto y se le hace el empaque,
instalación, se capacita a los usuarios.
6. Administración del proyecto: involucra actividades con las que se busca producir un
software que satisfaga las necesidades de los clientes.
7. Administración de configuración y cambios: describe como controlar los elementos
producidos por todos los integrantes del equipo de trabajo, en cuanto: utilización de los
elementos, control de versiones, etc.
8. Ambiente: contiene actividades que describen los procesos y herramientas que
soportarán el equipo de trabajo del proyecto, así como el procedimiento para
implementar el proceso en una empresa.

Calidad en un producto de software

¿Cómo se define la calidad del software?
Según argumenta Pressman, se define en 3 puntos importantes.

1. Un proceso eficaz de software establece la infraestructura que da apoyo a la elaboración de

un producto de software de alta calidad. Los aspectos de administración del proceso generan las
verificaciones y equilibrios que ayudan a evitar que el proyecto se arruine, lo que provoca
fundamentalmente la mala calidad. Las prácticas de ingeniería de software permiten al desarrollador
analizar el problema y diseñar una solución sólida, lo cual constituyen fundamentalmente un
software de alta calidad.

2. Un producto útil que entrega contenido, funciones, y características que el usuario final
desea, de manera confiable y sin errores. Un producto útil siempre satisface el conjunto de
requerimientos en forma explícita por los participantes.

3. Agregar valor para el producto y para el usuario de un producto, el software de alta calidad
proporciona beneficios a la organización que lo produce, así como a la comunidad que lo vaya a usar.
La organización que elabora el software obtiene valor agregado porque el software de alta calidad
requiere menor esfuerzo de mantenimiento, menos errores que corregir, poca asistencia al cliente,
etc.

Relación Calidad-Métrica
“Medida cuantitativa del grado en que un sistema/componente/proceso posee un atributo dado.”
Las métricas sirven para evaluar y gestionar el progreso y desempeño con respecto al objetivo del
proyecto en curso, permitiendo valorar la calidad del producto.
Un proceso efectivo de medición permite definir planes viables de desarrollo de productos y
prestación de servicios de calidad, así como distinguir situaciones reales de riesgo, permitiendo una
buena toma de decisiones.
● La calidad de un producto de software puede depender de varios factores, entre estos se
encuentra que cumpla principalmente con los requerimientos del usuario y los estándares de
calidad durante el proceso de desarrollo. La calidad se puede evaluar mediante el uso de
métricas a través de diferentes procesos enfocados en el área del producto a analizar y
gestionar, la información proporcionada por estas métricas es de utilidad para los
desarrolladores y la optimización del producto de ser necesario.

Métrica directa: Métrica de un atributo que no depende de ninguna otra métrica de otro
atributo.

Métrica indirecta: Combinación de métricas

Tipos:
Métricas orientadas al tamaño: Provienen de la normalización de las medidas de calidad y/o
productividad considerando el tamaño del software que se haya producido. Si una
organización de software mantiene registros sencillos, se puede crear una tabla de datos
orientados al tamaño. Debe tenerse en cuenta que el esfuerzo y el coste registrados en la
tabla incluyen todas las actividades de ingeniería del software (análisis, diseño, codificación y
prueba) y no sólo la codificación.

Métricas orientadas a la función: Las métricas del software orientadas a la función

utilizan una medida de la funcionalidad entregada por la aplicación como un valor de
normalización. Ya que la funcionalidad no se puede medir directamente, se debe derivar
indirectamente mediante otras medidas directas. Esta métrica usa una medida llamada punto
de función se calculan llenando una tabla.

Métricas ampliadas de punto de función: Es una ampliación de la medida del punto de función
que se puede aplicar a sistemas y aplicaciones de ingeniería del software. La medida de punto
de característica se acomoda a aplicaciones en donde la complejidad del algoritmo es alta. Las
 aplicaciones de software de tiempo real, de control de procesos, y empotradas tienden a
tener alta complejidad de algoritmos y por lo tanto son adecuadas para el punto de
característica.

Métricas de proyecto: basadas en gestión.

Métricas de proceso: centradas en calidad de entorno de desarrollo.
Métricas de producto y servicio: basadas en la calidad del producto y del servicio prestado.

Estudios de factibilidad

Unidad 2: Ingeniería de requerimientos de software

Uso sistemático de principios contrastados, técnicas, lenguajes y herramientas para el análisis,

documentación, evolución de las necesidades de usuario y la especificación de requerimientos del
software.
Definición - Requerimiento: Descripción de las necesidades de los usuarios de un sistema.
Son las descripciones de lo que debe hacer un sistema, los servicios que ofrece y sus restricciones.
Son un reflejo de las necesidades del cliente por un sistema.

Requerimientos funcionales y no funcionales

A menudo, los requerimientos de sistemas de software se clasifican en funcionales, no funcionales o
como requerimientos de dominio.
Requerimientos funcionales
Son declaraciones de los servicios que debe proporcionar el sistema, de la manera que éste debe
reaccionar a las entradas particulares y de cómo se debe comportar en ciertas situaciones.
La especificación de requerimientos funcionales debe ser completa y consistente. Completo quiere
decir que todos los servicios solicitados por el sistema deben estar definidos, y consistente quiere
decir que no deben tener definiciones contradictorias. Aunque en la teoría parezca fácil, en sistemas
grandes es casi imposible lograr ambos.
Requerimientos no funcionales
Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo y estándares.
Los requerimientos no funcionales a menudo se aplican al sistema en su totalidad.
Normalmente apenas se aplican a características o servicios individuales del sistema.
Usualmente se los separa en 3.

1. Requerimientos de producto: especifican el comportamiento del producto en cuestión,

como, por ejemplo, la rapidez de ejecución del sistema, y cuánta memoria este va a requerir para
funcionar.
 2. Requerimientos organizacionales: se derivan de políticas y procedimientos en la
organización del cliente o del desarrollador. Por ejemplo, los estándares que deben usarse para
implementar, los lenguajes de programación, el método de diseño, etc.
3. Requerimientos externos: incluye todos los requerimientos que se derivan de factores
externos al sistema y de su proceso de desarrollo. Estos pueden incluir la manera en el que el sistema
interactúa con otras organizaciones, o que el sistema funcione bien acorde a valores legales y éticos
de donde se produce.
El problema más grande que tienen los requerimientos no funcionales es que son complicados de
verificar, así que suelen usarse como metas generales como facilidad de uso, capacidad del sistema
para recuperarse de fallos, etc.
Requerimientos del dominio
Los requerimientos del dominio se derivan del dominio de aplicación del sistema más que de las
necesidades específicas del usuario, normalmente incluyen terminología especializada del dominio o
referencias a conceptos del dominio. Puede ser requerimientos funcionales nuevos, o incluso no
funcionales, pero debido a esto, es un poco complicado entender cómo se relacionan con otros
requerimientos del sistema.
Los requerimientos de dominio son importantes debido a que reflejan fundamento del dominio
donde se aplican, y en el caso de que no satisfaga, es probable que el sistema no funcione de ninguna
manera.
Requerimientos del usuario
Los requerimientos de usuario para el sistema deben describir los requerimientos funcionales y no
funcionales de tal forma que sean comprensibles por los usuarios del sistema sin conocimiento
técnico detallado. Solamente debe especificar el comportamiento externo del sistema, y deben evitar
como sea posible las características del diseño del sistema. Deben redactarse en un idioma para
tontos con cosas sencillas. Usualmente se tienen los siguientes problemas:
1. Falta de claridad: algunas veces es difícil utilizar el lenguaje de forma precisa y no ambigua sin
hacer el documento poco conciso y difícil de leer.
2. Confusión de requerimientos: No se distinguen claramente los requerimientos funcionales, no
funcionales o incluso por qué carajo está en el documento si no tiene nada que ver con el
sistema
3. Conjunción de requerimientos: diversos requerimientos diferentes se pueden expresar en un
único requerimiento en vez de mil separados.
Requerimientos del sistema
Los requerimientos del sistema son versiones extendidas de los requerimientos de usuario que son
utilizados por los ingenieros de software como punto de partida para el diseño del sistema. Agregan
detalles, explican cómo el sistema debe proporcionar los requerimientos del usuario, etc. No se trata
de cómo se debe diseñar, pero sí su comportamiento y sus restricciones. El nivel de detalle tiene que
ser muy específico y lo más técnico que se pueda.
A menudo se utiliza el lenguaje natural para redactar, pero esto requiere que el lector pueda
comprender ese lenguaje natural, de lo contrario, produce ambigüedades. Es esencial redactar los
requerimientos en un lenguaje que los no especialistas puedan entender, pero al mismo tiempo, que
no tenga ambigüedades y describa lo que tenga que describir.
Requerimientos verificables
Un requerimiento es verificable si se puede contrastar, es decir que tiene que cumplir con las
necesidades especificadas. No todos los requerimientos lo son, y estos deben ser descritos de una
manera que sean fácilmente verificables. (Los requerimientos funcionales tienen que ser verificables)
Documentos de requerimientos de software
El estándar IEEE 830-1998 para la especificación de requerimientos de software es un conjunto de
recomendaciones para la especificación de los requerimientos o requisitos de software el cual tiene
como producto final la documentación de los acuerdos entre el cliente y el grupo de desarrollo para
cumplir las exigencias. Estas especificaciones describen el comportamiento del sistema, las
interacciones que tendrán los usuarios con el software, las restricciones del mismo.

Proceso de ingeniería de requerimientos

La ingeniería de requerimientos es el conjunto de técnicas que se utilizan en la primera fase del
desarrollo de un sistema, con el objetivo de obtener información sobre lo que el sistema deberá
realizar y la viabilidad de este sobre la organización en la que se implementará.
● El primer paso es el estudio de factibilidad
En este paso, se deberá considerar el sistema que el cliente necesita e información preliminar
de la empresa en la que se implementará con el objetivo de determinar si es viable o no desde
un punto de vista empresarial.
Se considera el costo-beneficio del sistema propuesto desde un punto de vista empresarial,
y si éste puede desarrollarse dentro de las restricciones tecnológicas/presupuestales
existentes.

● El segundo paso es la obtención de requerimientos

Se deberá recopilar información sobre lo que el sistema deberá realizar mediante observación
de las actividades dentro de la empresa o área a implementar o consultando con empleados o
encargados del área, esta última tarea se puede realizar de diferentes maneras, ya que podría
implicar una entrevista con un único potencial usuario, o para múltiples usuarios se utilizan
otras técnicas.
Durante esta etapa, en base a la información recolectada, se podrán hacer modelos
preliminares del sistema o prototipos para ayudar a capturar esta información, determinando
así las funciones que deberá realizar el sistema.
● El tercer paso es la especificación de requerimientos
En este paso se realiza el documento en el cual se detallarán los requerimientos analizados
anteriormente.

● El último paso es la validación de los requerimientos

 Es donde se validará lo detallado en el documento, determinando si estos cumplen con lo
solicitado para el sistema y si son implementables.

La ingeniería de requerimiento es una disciplina que abarca todas las actividades para la obtención de
requerimientos para el sistema a desarrollar.
El proceso de la ingeniería de requerimiento abarca ciertos pasos:
1) Viabilidad: En este proceso se determina si el sistema a desarrollar es viable o no.
2) Elicitación: En este paso se determina los requerimientos de usuarios.
3) Validación: En este paso los usuarios determinan si todos los requerimientos que se
obtuvieron son válidos.
4) Gestión de requisitos: En este paso se manejan los cambios que surgen mientras el
desarrollo del sistema se va realizando.

SRS/ERS
Documento oficial para los desarrolladores del sistema donde se encuentran los requerimientos del
usuario del sistema y la especificación detallada de los requerimientos que se deben implementar.
No existe SRS perfecta.
Características de un SRS:

Correcto: Cada requerimiento en el SRS debe representar un requerimiento real del sistema a
construir.
No ambiguo: La redacción de los requerimientos debe ser clara de modo que no se pueda
malinterpretar.
 Completo: Deben estar incluidos todos los requerimientos, deben estar definidas todas las
respuestas del software a todos tipos de datos de datos en todas las situaciones, todas las
referencias deben estar incluidas y se debe evitar la postergación de una sección del SRS, y si,
es postergado se debe aclarar el responsable de determinar el contenido y cuándo se hará.
Verificable: Cada uno de los requerimientos establecidos en él debe ser verificable.
Consistente: Ningún subconjunto de requerimientos debe tener conflictos.
Entendible para todos: Se debe incorporar documentación entendible por usuarios, o sea en
lenguaje informal.
Modificable: Debe permitir la modificación fácil, completa y consistente.
Rastreable: Debe ser claro el origen de cada requerimiento y facilitar la referencia de cada
requisito para un desarrollo futuro o modificación.
Anotado: Se deben incorporar anotaciones para guiar el desarrollo.

Unidad 3: Captura y gestión de requerimientos

Obtención y Análisis de Requerimientos e Interfaces

En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales del
sistema para determinar el dominio de la aplicación, qué servicios debe proporcionar el sistema, el
rendimiento requerido del sistema, las restricciones hardware, etcétera.
La obtención y el análisis del requerimiento puede afectar a varias personas de la organización. El
término stakeholders se utiliza para referirse a cualquier persona o grupo que se verá afectado por el
sistema, directa o indirectamente. Entre los stakeholders se encuentran los usuarios finales que
interactúan con el sistema y todos aquellos en la organización que se pueden ver afectados por su
instalación.
Obtener y comprender los requerimientos de los stakeholders es difícil por varias razones:
1. Los stakeholders a menudo no conocen lo que desean obtener del sistema informático excepto en
términos muy generales
2. Los stakeholders expresan los requerimientos con sus propios términos de forma natural y con un
conocimiento implícito de su propio trabajo
3. Diferentes stakeholders tienen requerimientos distintos, que pueden expresar de varias formas.
Los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de
requerimientos y descubrir las concordancias y los conflictos
4. Los factores políticos pueden influir en los requerimientos del sistema
5. El entorno económico y de negocios en el que se lleva a cabo el análisis es dinámico.
Se puede pensar en estas actividades dentro de una espiral de forma que las actividades se
entrelazan a medida que el proceso avanza desde el anillo interior a los exteriores de la espiral.
Las actividades del proceso son:
1. Descubrimiento de requerimientos: Es el proceso de interactuar con los stakeholders del
sistema para recopilar sus requerimientos. Los requerimientos del dominio de los
stakeholders y la documentación también se descubren durante esta actividad.
2. Clasificación y organización de requerimientos: Esta actividad toma la recopilación no
estructurada de requerimientos, grupos relacionados de requerimientos y los organiza en
grupos coherentes.

Validación de Requerimientos
Esto trata de mostrar que éstos realmente definen el sistema que el cliente desea. Coincide
parcialmente con el análisis ya que éste implica encontrar problemas con los requerimientos. La
validación de requerimientos es importante debido a que los errores en el documento de
requerimientos pueden conducir a importantes costes al repetir el trabajo cuando son descubiertos
durante el desarrollo o después de que el sistema esté en uso.
Durante el proceso de validación de requerimientos, se deben llevar a cabo verificaciones sobre
requerimientos en el documento de requerimientos. Estas verificaciones comprenden:
Verificaciones de validez: Un usuario puede pensar que se necesita un sistema para llevar a
cabo ciertas funciones
Verificación de consistencia: Los requerimientos en el documento no deben contradecirse (no
debe haber contradictorias de la misma función del sistema)
Verificaciones de completitud: El documento de requerimientos debe incluir requerimientos
que definan todas las funciones y restricciones propuestas por el usuario del sistema
Verificaciones de realismo: Utilizando el conocimiento de la tecnología existente, los
requerimientos deben verificarse para asegurar que se pueden implementar, esto debe tener
en cuenta el presupuesto y la confección de agendas para el desarrollo del sistema
Verificabilidad: Para reducir la posibilidad de discusiones entre el cliente y el contratista, los
requerimientos del sistema siempre deben redactarse de tal forma que sean verificables
Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación de requerimientos:
1. Revisiones de requerimientos: Los requerimientos son analizados sistemáticamente por un
equipo de revisores.
2. Construcción de prototipos: En este enfoque de validación, se muestra un modelo
ejecutable del sistema a los usuarios finales y a los clientes.
3. Generación de casos de prueba: Los requerimientos deben poder probarse. Desarrollar
pruebas para los requerimientos del usuario antes de que se escriba código es una parte
fundamental de la programación extrema.

Gestión de requerimientos
La gestión de requerimientos es el proceso de comprender y controlar los cambios en los
requerimientos del sistema. Es necesario mantenerse al tanto de los requerimientos particulares y
mantener vínculos entre los requerimientos dependientes de forma que se pueda evaluar el impacto
de los cambios en los requerimientos.
Durante el proceso del software, la comprensión del problema por parte de los stakeholders está
cambiando constantemente. Estos requerimientos deben entonces evolucionar para reflejar esta
perspectiva cambiante del problema.
Además, una vez que un sistema se ha instalado, inevitablemente surgen nuevos requerimientos. Es
difícil para los usuarios y clientes del sistema anticipar qué efectos tendrá el sistema nuevo en la
organización. Cuando los usuarios finales tienen experiencia con un sistema, descubren nuevas
necesidades y prioridades:
1. Normalmente, los sistemas grandes tienen una comunidad de usuarios diversa donde los
usuarios tienen diferentes requerimientos y prioridades.
2. Las personas que pagan por el sistema y los usuarios raramente son la misma persona. Los
clientes del sistema imponen requerimientos debido a las restricciones organizacionales y de
presupuesto.
3. El entorno de negocios y técnico del sistema cambia después de la instalación, y estos
cambios se deben reflejar en el sistema.

Técnicas de recolección de información

En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales del
sistema para determinar el dominio de la aplicación, qué servicios debe proporcionar el sistema, el
rendimiento requerido del sistema, etc.
Esta obtención de requerimientos puede afectar a varias personas en la organización a quienes
vamos a llamar stakeholders. Entre ellos se encuentran los usuarios fi ales, los que le dan el
mantenimiento, los gerentes del negocio, expertos en dominio del sistema, etc.
Entrevistas
Las entrevistas formales o informales con los stakeholders del sistema son partes de la mayoría de los
procesos de la ingeniería de requerimientos. En estas entrevistas, el equipo de la ingeniería de
requerimientos hace preguntas a los stakeholders sobre el sistema que utilizan y sobre lo que van a
desarrollar. Pueden ser de 2 tipos.
1. Entrevistas cerradas donde los stakeholders responden a un conjunto de preguntas que ya
estaban preparadas.
2. Entrevistas abiertas donde no hay un programa predefinido. El equipo de la ingeniería de
requerimientos examina una serie de cuestiones con los stakeholders del sistema y desarrolla
una mejor comprensión de sus necesidades.
Normalmente las entrevistas son una combinación de ambas cosas y sacar preguntas o predecir más
o menos la respuesta. Las discusiones TOTALMENTE abiertas no suelen salir bien, así que primero se
recomienda preguntar algunas cosas para empezar y después mantener un flujo centrado en toda la
entrevista.
Usualmente no suele ser un modo efectivo porque los especialistas usan una jerga que se les
acomode, cosa que no todos estamos acostumbrados a X terminología. Sin embargo, es posible
pilotearla para que sí funcione, como conociendo la estructura principal, y tratar de obtener
requerimientos en el contexto en el que se entrevista.
Cuestionarios
Los cuestionarios permiten que los analistas estudien actitudes, comportamientos y características de
varias personas que pueden ser afectadas por el sistema actual y propuesto. Son utilizados para
investigar una gran muestra de usuarios.
Los cuestionarios suelen usarse cuando las persona que necesitamos preguntarles están muy alejadas
de nosotros y dispersas (distinto a las entrevistas), también si son una gran multitud de personas o se
necesita para un estudio exploratorio para un proyecto.
Las preguntas que se hacen en estos cuestionarios tienen que ser más claras y seguir un flujo más
coherente que las entrevistas, pueden ser abiertas y cerradas también. Las abiertas deben ser muy
estrechas y dirigir al que responde de una forma específica y se necesitan para situaciones
exploratorias. Las preguntas cerradas se utilizan cuando se puedan listar todas las respuestas y si
estas son excluyentes.
Desarrollo Conjunto de Aplicaciones (JAD)
Es una técnica que se utiliza para promover la cooperación y el trabajo en equipo entre usuarios y
analistas. Consiste en realizar sesiones en las que participan usuarios expertos del dominio junto a
analistas de software. La idea es aprovechar la dinámica de grupos aplicando un proceso de trabajo
sistemático y organizado, apoyado por elementos visuales de comunicación y comprensión de
soluciones
Las razones que sirven de base a JAD (Joint Application Design) son las siguientes:
• Las entrevistas requieren mucho tiempo, no solo en prepararlas y hacerlas sino también en
redactar un conjunto de requisitos coherente a partir de opiniones diferentes de los distintos
entrevistados
• Es más difícil apreciar posibles errores en la especificación de requisitos, ya que sólo el
analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar
defectos
• El JAD propugna una participación más profunda de los usuarios en el proyecto, hasta tal
punto que los usuarios que participan adquieren un cierto sentido de propiedad en el sistema
que construyen
Brainstorming (tormenta de ideas)
Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren toda clase de
ideas sin juzgar su validez y después de recopilar todas las ideas se realiza un análisis detallado de
cada propuesta. Esta técnica se puede utilizar para identificar un primer conjunto de requisitos en
aquellos casos donde no están muy claras las necesidades que hay que cubrir, o cuando se está
creando un sistema que habilitará un servicio nuevo para la organización.
Reglas de oro de las Interfaces
Dar control al usuario:
● Ayudar a que usuario no realice acciones innecesarias o no deseadas
● Interacción flexible (teclado, mouse, etc.)
● Permitir interrumpir o deshacer operaciones
● Aligerar la interacción con el nivel de conocimiento (macros)
● Se refiere a que la interfaz en sí misma debe proporcionar todas las herramientas necesarias al
usuario para mantener el control sobre las operaciones que realiza.
Reducir la carga de memoria:
● Cuanto más tenga que recordar el usuario, más propensa a errores será su interacción con el
sistema
● Reducir la demanda de memoria a corto plazo
● Establecer valores por defecto útiles
● Definir las deficiencias que sean intuitivas
● Formato visual basado en metáfora del mundo real
● Desglosar información de forma progresiva
● Esta regla se refiere a que la interfaz debe ayudar al usuario proporcionando toda la
asistencia a la memoria posible, utilizando valores por defecto adecuados o evitando
desenvolver toda la información en pantalla.
Construir una interfaz consecuente:
● Toda la información está organizada de acuerdo con el diseño estándar que se mantiene
en todas las pantallas
● Permitir que el usuario realice una tarea en el contexto adecuado
● Mantener consistencia en toda la familia de aplicaciones
● No realizar cambios en los modelos a menos que haya una razón convincente
● Esta regla implica que la interfaz gráfica debe mantener un formato consistente en la que
la información y su contexto se organice de forma ideal.

Principiantes: No tienen conocimientos de la utilización de la aplicación o del sistema.

Esporádicos y con conocimientos: Conocimiento razonable, pero retención baja de información
necesaria para utilizar la interfaz.
Frecuentes y con conocimientos: Conocimiento suficiente. Síndrome del usuario avanzado:
interrupciones breves y modos abreviados de interacción.

Unidad 4: UML y herramientas CASE

Desarrollo de software orientado a objetos

La construcción fundamental es el objeto que combina estructuras de datos con los
comportamientos en una entidad única. Un objeto posee una identidad, es decir, dos objetos van a
ser distinto aun cuando todos sus atributos sean iguales. Se define con objetos y clases, las cuales
están compuestos de atributos y operaciones.
 1. Objetos: son entidades básicas del modelo de objeto. Son las cosas más simples, pero se
pueden dividir en cosas concretas o abstractas. Cualquier cosa que incorpore una estructura y
un comportamiento se puede considerar objeto.
2. Clases: describen un grupo de objetos con estructura y comportamiento común. Las
propiedades de la clase se conocen como atributos y el comportamiento se define como
operaciones.

Modelos de Casos de Uso

Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del usuario.
Es una herramienta valiosa dado que es una técnica de aciertos y errores para obtener los
requerimientos del sistema, justamente desde el punto de vista del usuario.
Los diagramas de casos de uso modelan la funcionalidad del sistema utilizando actores, y casos de
uso. Los casos de uso son servicios o funciones provistas por el sistema que se está haciendo.

Actores
Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el
sistema que estamos construyendo de la misma forma. Los actores son externos al sistema que
desarrollamos, por lo tanto, al identificarlos, estamos empezando a delimitar el sistema y definir su
alcance.
Es importante saber la diferencia entre usuario y actor, el segundo es una clase de rol, mientras que
el primero es quien cuando usa el sistema, asume el rol.
El usuario puede acceder al sistema como varios actores. También puede ocurrir que un actor sea
una máquina, o un software que controle una cosa en específico.

Casos de uso
Un caso de uso es iniciado por un actor, a partir de ese momento, ese actor junto a otros,
intercambian datos o control con el sistema, participando de ese caso de uso. El nombre del caso de
uso debe ser un verbo, seguido generalmente por el principal objeto del sistema es que afectado por
el caso.

¿Qué es UML?
Lenguaje de modelado unificado, es un lenguaje estándar para representar planos de software, que
representa distintas vistas de un mismo modelo. Esas vistas es una proyección de la organización de
la estructura del sistema, centrada en un aspecto en particular.
Por lo tanto, UML es un lenguaje utilizado para modelar un sistema real o software. Y tiene 4
funciones en específico:
1. Visualizar: como es un lenguaje gráfico, facilita la comunicación entre los distintos miembros
de un proyecto. Permite elevar el nivel de abstracción para obtener una visión más general de
una parte de un proyecto.
2. Especificar: construir modelos precisos, formales y completos.
3. Construir.
4. Documentar: Sirve para mejorar la comprensión del código, futuras aplicaciones, corrección
de errores, realizar pruebas.
Ejemplos de diagramas UML:
Diagrama de clases
Es una estructura estática de un sistema. Expresa cosas que existen o un grupo de cosas (clases), que
tienen ciertas propiedades (atributos) y acciones similares. Estas clases pueden ser cosas tangibles,
como cosas abstractas.
Diagrama de objetos
Están vinculados con los diagramas de clases. Son una instancia de clase, por lo que un diagrama de
objetos puede ser visto como una instancia de un diagrama de clases. Los diagramas de objetos
describen la estructura estática de un sistema en un momento en particular.
Diagramas de casos de uso
Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del usuario.
Es una herramienta que permite visualizar aciertos y errores a la hora de expresar los requerimientos
del sistema vista desde la perspectiva del usuario. Estos diagramas modelan la funcionalidad del
sistema, usando actores y casos de uso.
Diagrama de Estados
En cualquier momento, un objeto se encuentra en un estado particular, la luz está encendida o
apagada, el auto en movimiento o detenido, etc.
Diagrama de secuencias
Los diagramas de clases y los de objetos representan información estática. No obstante, en un
sistema funcional, los objetos interactúan entre sí, y tales interacciones suceden con el tiempo. El
diagrama de secuencias UML muestra la mecánica de la interacción con base en tiempos.
Diagramas de actividades
Un diagrama de actividades ilustra la naturaleza dinámica de un sistema mediante el modelado del
flujo ocurrente de actividad en actividad. Una actividad representa una operación en alguna clase del
sistema, y que resulta en un cambio en el estado del sistema. Típicamente, los diagramas de actividad
son utilizados para modelar el flujo de trabajo interno de una operación.
Diagrama de colaboraciones
El diagrama de colaboraciones describe las interacciones entre los objetos en términos de mensajes
secuenciados. Los diagramas de colaboración representan una combinación de información tomadas
de los diagramas de clases, secuencias, CU, comportamiento, etc.
Diagrama de componentes
Un diagrama de componentes, representa de forma estática el sistema de información.
Habitualmente se utiliza después de haber creado el diagrama de clases, pues necesita información
de este diagrama como pueden ser las propias clases.
Este diagrama proporciona una vista de alto nivel de los componentes dentro de un sistema. Los
componentes pueden ser un componente de software, como una base de datos o una interfaz de
usuario; o un componente de hardware como un circuito, microchip o dispositivo; o una unidad de
negocio como un proveedor, nómina o envío.
Diagramas de distribución
El diagrama de distribución UML muestra la arquitectura física de un sistema informático. Puede
representar a los equipos y a los dispositivos, y también mostrar sus interconexiones y el software
que se encontrará en cada máquina.

Unidad 5: Captura y gestión de requerimientos

Importancia de los métodos formales

¿Qué son los métodos formales?
Un método formal es una técnica basada en matemáticas usada para describir sistemas de hardware o
software. Permiten representar la especificación del software, verificación y diseño de componentes mediante
notaciones matemáticas.

El uso de métodos formales permite plantear de manera clara qué definen el comportamiento en
términos del "qué debe hacer" y no del "cómo se hace". Gracia a este proceso, se puede verificar
propiedades derivadas de cada módulo, mediante técnicas de razonamiento, asociadas a los modelos
formales.
Para los procesos de especificación, se reconoce las siguientes clasificaciones:
•Lenguajes basados en modelos y estados, que permiten especificar el sistema mediante un
concepto formal de estados y operaciones sobre estados. Los datos y relaciones/funciones se
escriben en detalle y sus propiedades se expresan en lógica de primer orden. Por ejemplo,
VDM, Z, B, OCL.
•Lenguajes basados en especificaciones algebraicas. Proponen una descripción de estructuras
de datos, estableciendo tipos y operaciones sobre esos tipos. Para cada tipo se define un
conjunto de valores y operaciones sobre esos valores. Las operaciones de un tipo se definen a
través de un conjunto de axiomas o ecuaciones que especifican las restricciones que deben
satisfacer esas operaciones. Ejemplos: Learch, OBJ, TADs.
Lenguajes de especificación de comportamiento:
◦métodos basados en algebra de procesos: modelan la interacción entre procesos
concurrentes. Esto ha potenciado su difusión en la especificación de sistemas de
comunicación y de sistemas distribuidos y concurrentes.
◦métodos en redes de petri: una red de petri es un formalismo basado en autómatas, es decir,
un modelo basado en flujos de información. Permiten expresar eventos concurrentes.
◦métodos basados en lógica temporal: se usan para especificar sistemas concurrentes y
reactivos. Los sistemas reactivos son aquellos que mantienen una continua interacción con su
entorno respondiendo a estímulos externos.

Qué es el OCL
El OCL es un lenguaje para la descripción formal de expresiones en los modelos UML. Fue adoptado
en octubre de 2003 por el grupo OMG como parte UML 2.0. Sus expresiones pueden representar
invariantes, precondiciones, postcondiciones, inicializaciones, guardias, reglas de derivación, así
como consultas a objetos para determinar sus condiciones de estado.