Tarea1

2.1 Tareas de la ingeniera de requisitos

Se define como un conjunto de actividades en los cuales, utilizando tecnicas y herramientas,
se analiza un problema y se concluye con la especificacin de una solucin. La ingeniera de
requisitos es el proceso de desarrollar una especificacin de software.
Inicio:
Tiene por objetivo identificar el mbito del proyecto general. Comienza con una serie de
conversaciones informales entre los participantes del mismo. Esta fase suele ser
acompaada de los documentos de definicin de la visin global y la visin del dominio del
sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo
servicio.
Obtencin:
Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los
usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que
se debe lograr, de que forma el producto satisface las necesidades del negocio y como se
utilizara el producto da d da. Se identifican una serie de problemas que ayudan a entender
porque es difcil la obtencin de requisitos:
1 Problema de mbito
1 Problema de comprensin
1 Problemas de volatilidad
Elaboracin:
Se crea un modelo de anlisis con la informacin obtenida del cliente en las fases de inicio y
obtencin. La informacin conseguida con el cliente durante el inicio y obtencin se expande
y se refina durante la elaboracin. Esta actividad se enfoca en el desarrollo de un modelo
tcnico refinado de las funciones, caractersticas y restricciones del software. La elaboracin
se conduce mediante la creacin y refinamiento de escenarios del usuario que describan la
forma en que el usuario final y otros actores interactan con el sistema.
Negociacin:
En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y lmites del
sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan
buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos
asociados con cada requisito.
Especificacin:
Es el producto final de la ingeniera de requisitos, y se convierte en la materia prima para las
actividades posteriores en el proceso de desarrollo del sistema. Una especificacin puede ser
un documento escrito, un conjunto de modelos grficos, un modelo matemtico formal, una
coleccin de escenarios de uso, un prototipo o cualquier combinacin de estos.
Validacin:

Un equipo de validacin toma el producto de la fase de especializacin, lo revisa para

detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia
de requisitos. La validacin de requisitos examina la especificacin para asegurar que todos
los requisitos de software se han establecidos de manera precisa; que se han detectado las
inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de
trabajo cumple con los estndares establecidos para el proceso, proyecto y producto.
Gestin de requisitos:
Ayuda a rastrear los requisitos segn las caractersticas de los mismos, el cdigo fuente
relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de
forma que pueda identificarse con rapidez para entender como afectara una modificacin
diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al
equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en
cualquier momento mientras se desarrolla el proyecto.

Tarea 2
A) Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el
cual se desarrolla en cooperacin con otros modelos.
B) Las caractersticas: de un requerimiento son sus propiedades principales. Un conjunto
de requerimientos en estado de madurez, deben presentar una serie de caractersticas
tanto individualmente como en grupo. A continuacin se presentan las ms importantes.
Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia en el
sistema a construir, y adems su capacidad, caractersticas fsicas o factor de calidad no
pueden ser reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fcil de leer y entender. Su redaccin debe ser
simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su redaccin,
es decir, si se proporciona la informacin suficiente para su comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretacin.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que
permita hacer uso de los siguientes mtodos de verificacin: inspeccin, anlisis,
demostracin o pruebas.

C) Tipos de requerimientos:
Requerimientos Funcionales: Son declaraciones de los servicios que proveer el sistema, de la
manera en que ste reaccionar a entradas particulares. En algunos casos, los requerimientos
funcionales de los sistemas tambin declaran explcitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se
espera que ste provea. Estos dependen del tipo de software y del sistema que se desarrolle y
de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario,
habitualmente se describen de forma general mientras que los requerimientos funcionales del
sistema describen con detalle la funcin de ste, sus entradas y salidas, excepciones, etc.
Requerimientos No Funcionales: Son restricciones de los servicios o funciones ofrecidos por el
sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estndares, y otros.
Son aquellos requerimientos que no se refieren directamente a las funciones especficas que
entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en
el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del
sistema como la capacidad de los dispositivos de entrada/salida y la representacin de datos que
se utiliza en la interface del sistema.
Requerimientos del Dominio: Son requerimientos que provienen del dominio de aplicacin del
sistema y que reflejan las caractersticas de ese dominio. stos pueden ser funcionales o no
funcionales. Se derivan del dominio del sistema ms que de las necesidades especificas de los
usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer
cmo se deben ejecutar clculos particulares. Los requerimientos del dominio son importantes

debido a que a menudo reflejan los fundamentos del dominio de aplicacin. Si estos
requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.
Ejemplo en un Sistema de Biblioteca, este deber proveer visores para que el usuario lea
documentos en el almacn de documentos
Atributos de calidad de Software.
Funcionalidad: Un conjunto de atributos que se relacionan con la existencia de un conjunto de
funciones y sus propiedades especficas. Las funciones son aquellas que satisfacen las
necesidades implcitas o explcitas.
Idoneidad
Exactitud
Interoperabilidad
Seguridad
Cumplimiento de normas.
Fiabilidad: Un conjunto de atributos relacionados con la capacidad del software de mantener su
nivel de prestacin bajo condiciones establecidas durante un perodo establecido.
Madurez
Recuperabilidad
Tolerancia a fallos
Usabilidad: Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la
valoracin individual de tal uso, por un establecido o implicado conjunto de usuarios.
Aprendizaje
Comprensin
Operatividad
Atractividad
Eficiencia: Conjunto de atributos relacionados con la relacin entre el nivel de desempeo del
software y la cantidad de recursos necesitados bajo condiciones establecidas.
Comportamiento en el tiempo
Comportamiento de recursos
Mantenibilidad: Conjunto de atributos relacionados con la facilidad de extender, modificar o
corregir errores en un sistema software.

Estabilidad
Facilidad de anlisis
Facilidad de cambio
Facilidad de pruebas
Portabilidad: Conjunto de atributos relacionados con la capacidad de un sistema software para
ser transferido desde una plataforma a otra.
Capacidad de instalacin
Capacidad de reemplazamiento
Adaptabilidad
Co-Existencia

Tarea 3
A)

Cuestionarios

El uso de cuestionarios permite a los analistas reunir informacin proveniente de un grupo grande de
personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos ms
confiables que otras tcnicas; por otra parte, su amplia distribucin asegura el anonimato de los
encuestados, situacin que puede conducir a respuestas ms honestas.
El inconveniente es que la respuesta puede ser limitada, ya que es posible que no tenga mucha
importancia para los encuestados llenar el cuestionario. Es recomendable conseguir apoyo de la alta
direccin para solicitar a las personas de la organizacin que contesten el cuestionario.
Al igual que con las entrevistas, se debe seleccionar a los encuestados. El analista debe asegurar que el
conocimiento y experiencia de stos califiquen para dar respuestas a las preguntas.

B)

Entrevistas

La entrevista es de gran utilidad para obtener informacin cualitativa como opiniones, o descripciones
subjetivas de actividades. Es una tcnica muy utilizada, y requiere una mayor preparacin y experiencia
por parte del analista. La entrevista se puede definir como un intento sistemtico de recoger informacin
de otra persona a travs de una comunicacin interpersonal que se lleva a cabo por medio de una
conversacin estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la
informacin necesaria. Es muy importante la forma en que se plantea la conversacin y la relacin que se
establece en la entrevista.
Estos son algunos de los aspectos ms importantes a tener en cuenta al realizar entrevistas:

Preparacin. Es necesario documentarse e investigar la situacin de la organizacin analizando

los documentos disponibles, de tal forma que la entrevista se enfoque en aquellos aspectos que
estn solamente en la mente del entrevistado y que no son accesibles por otros medios como la
observacin o el anlisis de documentos.

Entrevistar al personal adecuado. La mayora de los analistas adoptan un enfoque top-down,

comenzando a entrevistar a directivos para que brinden un panorama general de hacia donde
deberan ir las cosas, y terminando por hablar con los empleados que aportan detalles importantes
de la operacin.

Duracin. Una entrevista debera durar a lo sumo un par de horas.

Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan elaborar y dar
detalles, ms all de simplemente responder si o no.

C)

Casos de Uso

El modelo de casos de uso describe un sistema en trmino de sus distintas formas de

utilizacin, cada uno de estas formas es conocida como un caso de uso. Cada caso de
uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Dado que los

casos de uso describen el sistema a desarrollarse, cambios en los requisitos significarn

cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automvil
sera la secuencia de eventos desde que el conductor entra en el coche encendiendo el
motor hasta llegar a su destino final. Por lo tanto, para comprender los casos de uso de un
sistema primero es necesario saber quines son sus usuarios. Por ejemplo, conducir un
automvil es distinto a arreglarlo, donde los usuarios tambin son distintos, el dueo del
automvil y el mecnico, respectivamente.

D)

Escenarios

Estos se utilizan para documentar el comportamiento del sistema cuando se le presentan eventos
especficos. Cada evento de interaccin distinto, o la seleccin de un servicio del sistema, se documentan
como un escenario de eventos distinto. Los escenarios de eventos incluyen una descripcin del flujo de
datos y las acciones del sistema, y documenta las excepciones que puedan surgir.
Las convenciones para los diagramas utilizados en los escenarios de eventos son:
1. Los datos proporcionados desde un punto de vista o proporcionados a ste se representan como
elipses.
2. Las entradas y salidas de la informacin de control se ubican en la parte superior de cada
recuadro.
3. Las salidas de datos se ubican a la derecha de cada recuadro. Si no estn encerradas, significa
que pertenecen al sistema.
4. Las excepciones se muestran en la parte inferior del recuadro. Si existen varias excepciones
posibles, stas se encierran en un recuadro.
5. El nombre del siguiente evento esperado despus de completar el escenario se muestra en un
recuadro sombreado.
Los Casos de Uso son una tcnica que se basa en escenarios para la obtencin de requerimientos.
Actualmente se han convertido en una tcnica fundamental que se utiliza para analizar y describir
modelos de sistemas orientados a objetos. En su forma ms simple, un caso de uso identifica a los
actores involucrados en una interaccin y nombra al tipo de sta.