INGENIERÍA DE SOFTWARE

U1 Especificación de requisitos

BRENDA ESCAMILLA DOMINGUEZ

 INGENIERÍA DE
REQUERIMIENTOS
 INGENIERÍA DE
REQUERIMIENTOS
 El proceso de adquisición y análisis
de requerimientos
1. Descubrimiento de requerimientos Éste es el proceso de
interactuar con los participantes del sistema para descubrir sus
requerimientos, existen numerosas técnicas complementarias que
pueden usarse para el descubrimiento de requerimientos.
2. Clasificación y organización de requerimientos Esta actividad toma
la compilación no estructurada de requerimientos, agrupa
requerimientos relacionados y los organiza en grupos coherentes. La
forma más común de agrupar requerimientos es usar un modelo de la
arquitectura del sistema.
3. Priorización y negociación de requerimientos
Esta actividad se preocupa por priorizar los requerimientos, así como
por encontrar y resolver conflictos de requerimientos mediante la
negociación.
4. Especificación de requerimientos
Los requerimientos se documentan e ingresan en la siguiente ronda
de la espiral. Pueden producirse documentos de requerimientos
formales o informales.
 ENTREVISTAS
formales o informales con participantes del sistema son una parte de la
mayoría de los procesos de ingeniería de requerimientos. Los
requerimientos se derivan de las respuestas a dichas preguntas. Las
1. Descubrimiento de

entrevistas son de dos tipos:

1. Entrevistas cerradas: donde los participantes responden a un conjunto
requerimientos

de preguntas preestablecidas.
2. Entrevistas abiertas: se explora un rango de conflictos con los
participantes del sistema y, como resultado, desarrolla una mejor
comprensión de sus necesidades.

ESCENARIOS son particularmente útiles para detallar un bosquejo de

descripción de requerimientos.
Se desarrollan diferentes formas de escenarios y se ofrecen varios tipos
de información con diversos niveles de detalle acerca del sistema.

CASOS DE USO Los casos de uso son una técnica de descubrimiento

de requerimientos que se introdujo por primera vez en el método
Objectory (Jacobson et al., 1993). Ahora se ha convertido en una
característica fundamental del modelado de lenguaje unificado. En su
forma más sencilla, un caso de uso identifica a los actores implicados en
una interacción, y nombra el tipo de interacción. La información adicional
puede ser una descripción textual, o bien, uno o más modelos gráficos
como una secuencia UML o un gráfico de estado.
 CASOS DE USO
En esencia, un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final
(que tiene cierto número de roles posibles) con el sistema en circunstancias específicas.
 La historia puede ser un texto narrativo, un lineamiento de tareas o interacciones, una
descripción basada en un formato o una representación diagramática.
 Sin importar su forma, un caso de uso ilustra el software o sistema desde el punto de vista del
usuario final. El primer paso para escribir un caso de uso es definir un conjunto de “actores”
que estarán involucrados en la historia.
 Los actores son las distintas personas (o dispositivos) que usan el sistema o producto en el
contexto de la función y comportamiento que va a describirse. Los actores representan los
papeles que desempeñan las personas (o dispositivos) cuando opera el sistema. Con una
definición más formal, un actor es cualquier cosa que se comunique con el sistema o
producto y que sea externo a éste. Todo actor tiene uno o más objetivos cuando utiliza el
sistema. Es importante notar que un actor y un usuario final no necesariamente son lo mismo.
Un usuario normal puede tener varios papeles diferentes cuando usa el sistema, mientras que
un actor representa una clase de entidades externas (gente, con frecuencia pero no
siempre) que sólo tiene un papel en el contexto del caso de uso.
 CASOS DE USO

 El modelado de casos de uso fue desarrollado originalmente por Jacobson y sus colaboradores en
la década de 1990, y se incorporó en el primer lanzamiento del UML.
 El modelado de casos de uso se utiliza ampliamente para apoyar la adquisición de requerimientos.
Un caso de uso puede tomarse como un simple escenario que describa lo que espera el usuario de
un sistema.
 Cada caso de uso representa una tarea discreta que implica interacción externa con un sistema. En
su forma más simple, un caso de uso se muestra como una elipse, con los actores que intervienen en
el caso de uso representados como figuras humanas.
 CASOS DE USO

Una vez identificados los actores, es posible desarrollar casos de uso.

Jacobson sugiere varias preguntas que debe responder un caso de uso:

•¿Quién es el actor principal y quién(es) el(los) secundario(s)?

•¿Cuáles son los objetivos de los actores?
•¿Qué precondiciones deben existir antes de comenzar la historia?
•¿Qué tareas o funciones principales son realizadas por el actor?
•¿Qué excepciones deben considerarse al describir la historia?
•¿Cuáles variaciones son posibles en la interacción del actor?
•¿Qué información del sistema adquiere, produce o cambia el actor?
•¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente
externo?
•¿Qué información desea obtener el actor del sistema?
•¿Quiere el actor ser informado sobre cambios inesperados?
2. Clasificación de REQUERIMIENTOS FUNCIONALES

 Los requerimientos funcionales para un sistema refieren lo que el

requerimientos

sistema debe hacer.

 Tales requerimientos dependen del tipo de software que se esté

desarrollando, de los usuarios esperados del software y del enfoque
general que adopta la organización.

 Los requerimientos funcionales del sistema varían desde requerimientos

generales que cubren lo que tiene que hacer el sistema, hasta
requerimientos muy específicos que reflejan maneras locales de trabajar
o los sistemas existentes de una organización.
 REQUERIMIENTOS NO FUNCIONALES
Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de
2. Clasificación de

respuesta y uso de almacenamiento. De forma alternativa, pueden definir restricciones sobre

la implementación del sistema.
requerimientos
 El proyecto de desarrollo de software al igual que cualquier otro
proyecto tiene múltiples técnicas de priorización de requerimientos,
3. Priorización de

restricciones presupuestarias y plazos ajustados.

requerimientos

Por lo tanto, existe la necesidad de priorizar los requisitos de

software ya que es imposible hacer todo a la vez, se deben tomar
decisiones sobre qué conjunto de requisitos se deben implementar
primero y cuáles se pueden retrasar hasta una versión posterior.
4. Especificación de
requerimientos
USUARIOS DE UN DOCUMENTO DE
REQUERIMIENTOS
Validación de requerimientos
Se verifica que los requerimientos
definan realmente el sistema que en
verdad quiere el cliente.

Se traslapa con el análisis, ya que se

interesa por encontrar problemas con los
requerimientos.

La validación de requerimientos es
importante porque los errores en un
documento de requerimientos pueden
conducir a grandes costos por tener que
rehacer, cuando dichos problemas se
descubren durante el desarrollo del
sistema o después de que éste se halla
en servicio.
 Administración de requerimientos
Los requerimientos para los grandes sistemas de software siempre cambian.
Una razón es que dichos sistemas se desarrollaron por lo general para
resolver problemas “horrorosos”: aquellos problemas que no se pueden
definir por completo. Como el problema no se logra definir por completo, los
requerimientos del software están condenados también a estar incompletos.
Durante el proceso de software, la comprensión que los participantes tienen
de los problemas cambia constantemente (figura 4.17). Entonces, los
requerimientos del sistema también deben evolucionar para reflejar esa
visión cambiante del problema.

Administración
del cambio de
requerimientos
 DIAGRAMAS UML

El UML está compuesto por diversos

elementos gráficos que se combinan
para conformar diagramas.
Debido a que el UML es un lenguaje,
cuenta con reglas para combinar tales
elementos.
 DIAGRAMAS UML

La finalidad de los diagramas es presentar

diversas perspectivas de un sistema, a las
cuales se les conoce como modelo.

Recordemos que un modelo es una

representación simplificada de la realidad; el
modelo UML describe lo que supuestamente
hará un sistema, pero no dice cómo
implementar dicho sistema.
 DIAGRAMAS UML

A continuación se describirán los diagramas más

comunes del UML y los conceptos que representan:
 Diagrama de Clases
 Diagrama de Objetos
 Diagrama de Casos de Uso
 Diagrama de Estados
 Diagrama de Secuencias
 Diagrama de Actividades
 Diagrama de Colaboraciones
 Diagrama de Componentes
 Diagrama de Distribución

http://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.pdf
 ESTUDIO DE FACTIBILIDAD

El estudio de factibilidad es un
instrumento que sirve para orientar la
toma de decisiones en la evaluación de
un proyecto
 ANÁLISIS COSTO-BENEFICIO
La técnica de análisis costo/beneficio tiene como objetivo fundamental
proporcionar una medida de los costos en que se incurre en la realización de un
proyecto y comparar dichos costos previstos con los beneficios esperados de la
realización de dicho proyecto. Esta medida o estimación servirá para:

• Valorar la necesidad y oportunidad de acometer la realización del proyecto.

• Seleccionar la alternativa más beneficiosa para la realización del proyecto.
• Estimar adecuadamente los recursos económicos necesarios en el plazo de
realización del proyecto.

Cabe destacar la necesidad cada vez mayor de guiarse por criterios económicos y
no sólo técnicos para la planificación de trabajos y proyectos. Por ello se
recomienda el uso de las técnicas y métodos de evaluación de conceptos
económicos, con el fin de proporcionar a los profesionales criterios que les ayuden
en la planificación de proyectos y evaluación de alternativas.