INFORMATICA Y

TELECOMUNICACIONES

TI1217-Ing y Gestión de requerimentos

PROFESOR:César Salinas Zepeda

FECHA:marzo 2017
Requerimientos
 Criterios para el análisis.

•  principios para desarrollar correctamente un sistema de información:

1. Involucrar al usuario.
El usuario es una parte imprescindible para el adecuado desarrollo de un sistema. Implicando al usuario se logrará
mejor sus necesidades y reducir su potencial resistencia a los nuevos sistemas de información.

2. U<lizar métodos de solución de problemas como es el ciclo de vida de sistemas.
Cualquier ac>vidad compleja necesita aplicar lógicas contrastadas. El ciclo de vida es en sí un método de resolución
de un problema específico.

3. Abordar adecuadamente cada una de las fases.
El ciclo de vida moderno incorpora una serie de fases: planificación, análisis, diseño, implantación y soporte de
sistemas. En términos generales se puede decir que se desarrollan secuencialmente, y cada una de ellas
incorpora mayor grado de detalle que la anterior. Las fases planificación y análisis han de abordarse
correctamente, puesto que por muy inteligentes que sean las soluciones técnicas, sin un análisis correcto será
muy diEcil que el sistema sea todo lo ú>l que potencialmente podría ser.
4. Normalizar y documentar.
Es fundamental que se fijen normas sobre las ac<vidades, sobre las responsabilidades, requisitos documentales y
controles de calidad para asegurar en el <empo la supervivencia del sistema. Los analistas y programadores
responsables de un sistema pueden dejar su puesto y si no existe la documentación apropiada, todo puede resultar
caó>co. La necesidad de documentar aumenta en la medida que el sistema que se desarrolle sea más complejo.

5. Jus<ficar adecuadamente el sistema.
Desarrollar sistemas de información supone inver>r en el futuro de la empresa. No se puede considerar un gasto,
sino una inversión y como tal ha de plantearse.

6. Cancelar o revisar el proyecto si es necesario.
Si es necesario, durante el desarrollo se ha de ser lo suficientemente flexible como para cancelar un proyecto.
Durante el ciclo de vida existen dis>ntos momentos en los que se efectúa un control progresivo que es un control de
la viabilidad del proyecto.

7. Descomponer y simplificar.
Un sistema complejo se ha de abordar dividiéndolo en subsistemas más simples. De esta manera disminuye la
complejidad y es más abordable por el ser humano.

8. Diseñar sistemas flexibles.
Si los sistemas no se diseñan previendo futuras modificaciones, sólo servirán para momentos concretos en el >empo.
Si se hace necesario cambiar un sistema que no es flexible, consumirá muchos recursos y talento de las unidades
involucradas en el soporte o mantenimiento del sistema.
 Análisis de sistemas
•  El análisis de sistemas es el estudio de una aplicación del
sistema de información y de empresa actual y la definición de
las necesidades y las prioridades de usuario para conseguir una
aplicación nueva o mejorada.

•  Trata básicamente de determinar los obje<vos y límites del
sistema objeto de análisis, caracterizar su estructura y
funcionamiento, marcar las directrices que permitan alcanzar
los obje<vos propuestos y evaluar sus consecuencia.

•  Conlleva el estudio del sistema actual y la definición de las

necesidades reales de los usuarios.

 Fases de Análisis de sistemas

•  Incluye las siguientes fases:

•  Iden<ficación del problema

•  Análisis de requerimientos

•  Análisis de la Viabilidad del Proyecto (o fase de inspección).

•  Análisis del sistema actual ( o fase de estudio).

•  Definición y establecimiento de prioridades entre las necesidades de

usuarios( o fase de definición).

•  Planeación del Sistema

Fase del: Iden>ficación del problema.
•  Tener claro que problema se deberá resolver
el Sistema de Información.

•  Es un proceso que deberá recabar la

información necesaria para emprender una
acción que solucione el problema.
Fase de análisis de Requerimientos

•  Es establecer lo que el cliente o

el usuario requiere de un
Sistema de SoSware.
Fase de análisis de Requerimientos

-Tiene la función de fortalecer el proceso de desarrollo de

soSware, tanto en su definición como en lo que se desea que
haga.
- Permiten administrar las necesidades del proyecto en
forma estructurada
- Mejora la capacidad de predecir resultados
- Disminuyen los costos y retrasos del proyecto
- Mejora la calidad del soSware
- Mejora la comunicación entre los equipos
- Evita rechazos de usuarios finales
 Que son los requerimientos

Es la condición o necesidad de un usuario

para resolver un problema del negocio o
alcanzar un obje>vo.
 Qué es un Requerimiento

•  Es la condición o necesidad de un usuario para resolver un

problema del negocio o alcanzar un obje>vo.
–  Puede ser la base para una declaración de un contrato,
por lo tanto, deber estar abierto a interpretación.
–  Puede ser la base para el contrato en sí, por lo tanto,
debe ser definido en detalle.
 Tipos de Requerimientos
•  El proceso de establecer los servicios que el cliente
requiere de un sistema y los limites bajo los cuales opera y
se desarrolla.

•  Los Requerimientos pueden ser Funcionales o No-

Funcionales

–  Los Requerimientos funcionales describen servicios o
funciones
–  Los Requerimientos No-funcionales son aspectos
secundarios que no >enen que ver con la funcionalidad
de un sistema. Por ejem. Logos, colores, etc.
Caracterís<cas de un requerimiento

-Debe ser especificado por escrito como un contrato o

acuerdo de ambas partes
- Se debe de probar o verificar para detectar su
cumplimiento
- Debe ser conciso fácil de leer y entender
- Debe ser completo
- Debe ser consistente y sin contradicciones
- No debe ser ambiguo no debe causar ninguna confusión
 Dificultades para definir los requerimientos

- Los requerimientos vienen de muchas fuentes y no son obvios

- Son diEciles de expresar en palabras
- La gran can>dad de requerimientos puede ser diEcil de manejar y
clasificar
- Pueden cambiar a lo largo del ciclo de desarrollo del soSware
- Al usuario se le dificulta explicar lo que hace
- Generalmente se habla de lo que no funciona
- Los usuarios >enen vocabulario dis>nto al de los desarrolladores
Requerimientos Definición/Especificación

•  Definición de Requerimientos
–  Una declaración en un Lenguaje Natural incluye los
diagramas de los servicios del sistema y sus límites
operacionales. Escrito para clientes.
•  Especificación de Requerimientos
–  Un documento estructurado con descripción o detalle de
los servicios del sistema. Escrito como un contrato entre el
cliente y el contra>sta.
•  Especificación de SoSware
–  Descripción detallada de soSware, la cual, puede servir
como una base para diseño o implementación. Escrito
para desarrolladores.
 Documento de Requerimientos
•  Es la declaración oficial de lo que es requerido
para que el sistema sea desarrollado.
•  Incluye la definición y especificación de
requerimientos.
•  No es un documento de diseño. Tanto como
sea posible, es un conjunto de lo que es el
sistema y como lo hará.
Requerimientos del Documento de Requerimientos

•  Especificación de la conducta externa del sistema.

•  Especificar los límites de la implementación.
•  Fácil de cambiar.
•  Sirve como una herramienta de referencia para
mantenimiento.
•  Recuerda el ciclo de vida del sistema, esto es,
predice cambios.
•  Proporciona respuestas caracterís>cas a un evento
no esperado.
 Estructura del Documento de Requerimientos

•  Introducción.
–  Describe la necesidad de crear el sistema y cuales son sus
obje>vos.
•  Glosario.
–  Define los términos técnicos usados.
•  Modelos del Sistema.
–  Define los modelos que muestran los componentes del
sistema y las relaciones entre ellos.
•  Definición de Requerimientos Funcionales.
–  Define los servicios que serán proporcionados.
 Estructura del Documento de Requerimientos
•  Definición de Requerimientos No-funcionales.
–  Definir las limitantes del sistema y el proceso de
desarrollo.
•  Evolución del Sistema.
–  Definir las suposiciones fundamentales en las cuales el
sistema se basa y se an>cipan los cambios.
•  Especificación de Requerimientos.
–  Especificación detallada de los requerimientos
funcionales del sistema.
•  Apéndices.
–  Descripción de la plataforma de Hardware del Sistema.
–  Requerimientos de la base de Datos (quizá como un
modelo ER)
•  Indice.
 Análisis de la Viabilidad del Proyecto.


•  Establecer Obje<vos de inspección.

•  Iden>ficar los problemas, las oportunidades y las normas que dieron lugar a la
solicitud del proyecto.

EJEMPLO:
•  Obje>vo de inspección.- Conocer las causas de la baja en las Ventas

•  Problema.- Agilizar las ventas en un SuperMercado

•  Oportunidades.- Manejo del crédito
•  Normas.- El pago deberá ser por medio de tarjeta de crédito
 Iden<ficación del problema y oportunidades.

•  El analista se involucra en la iden<ficación de los problemas y
puntos de oportunidad (oportunidades de mejoras) y
cumplimiento de obje<vos.

•  Esta fase es recomendable elaborar un diagrama de procesos

que muestre el flujo de las ac<vidades del sistema actual, los
problemas detectados y señalar claramente los puntos de
oportunidad y mejoras.
 Análisis de la Viabilidad del Proyecto.

•  Es determinar si resolver los problemas, aprovechar las oportunidades y cumplir las
normas reportará beneficios a la empresa.

•  Qué técnicas se u<lizarán en el Estudio de Viabilidad del Sistema (EVS)

•  Análisis coste/beneficio.
•  Diagrama en>dad/relación extendido.
•  Sesiones de trabajo.
•  Catalogación
•  Impacto en la organización.
•  Planificación
•  Diagramas de ac<vidades
•  Matrices
•  Presentaciones
 Análisis de la Viabilidad del Proyecto.

•  ¿Dónde interviene cada uno de los siguientes par>cipantes y cuáles su misión?

•  Comité de dirección: par>cipa al principio y al final del EVS. Su misión es indicar cuál debe ser el
alcance del sistema y aprobar la solución final.

•  Usuarios expertos: par>cipan en el estudio de la situación actual, la definición de requisitos y el
estudio de alterna>vas. Su obje>vo es ayudar a conocer los sistemas existentes, exponer sus
requisitos y dar su opinión en las alterna>vas de solución.

•  Especialistas en comunicaciones: par>cipan en el estudio de alterna>vas de solución. Su

obje>vo es definir los requisitos de comunicación de las dis>ntas soluciones.
 Análisis del sistema actual
•  Consiste en estudiar y analizar el sistema actual, siempre y cuando se
cuente con un sistema actual, hago uso o no de la informá>ca, dota al
analista de una comprensión mas profunda del sistema.

•  Los obje<vos:

•  Conocer el entorno de empresa del sistema.
•  Conocer las causas y los efectos subyacentes del sistema.
•  Conocer las ventajas de aprovechar las oportunidades.
•  Conocer las implicaciones de no cumplir con las normas.
 Establecer las prioridades de los usuarios

•  Es definir qué necesita el sistema y que quiere el usuario que haga.

•  Obje<vos:
•  Definir las necesidades de la empresa sobre los problemas y establecer prioridades.
•  Definir las necesidades de empresa sobre oportunidades y establecer prioridades
•  Definir las necesidades sobre normas y establecer prioridades.

•  Ac<vidades:
•  Iden<ficar las necesidades.
•  Modelizar las necesidades de sistemas.
•  Elaborar proto<pos de descubrimiento.
•  Definir prioridades entre las necesidades de empresa.
•  Modificar el ámbito y el plan de proyecto.
•  Revisar las especificaciones de las necesidades.
 La planeación de sistemas.

•  La función de planificación pretende señalar y establecer
prioridades sobre aquellas tecnologías y aplicaciones que
producirán un máximo beneficio para la organización.

•  El obje>vo de esta fase consiste en decidir junto con el equipo
humano de la empresa donde se va a implementar el sistema, los
obje<vos generales, específicos de la misma y elaborar los
esquemas generales de la manera más clara y precisa.
 Planeación de sistemas
•  Como sabemos, la planificación de los sistemas de información es la primera etapa de un
moderno ciclo de desarrollo y se puede considerar compuesta a su vez de tres subetapas:
•  Estudio de la misión y de los obje<vos de la empresa.
•  Establecer una arquitectura de la información.
•  Analizar las áreas de empresa.

•  Estudio de la misión y de los obje<vos de la empresa.

•  Para que los S.I sean verdaderamente ú<les, han de contribuir a la misión de la empresa. Para
aumentar el impacto posi>vo de las inversiones en sistemas de información, han de dirigirse a
los obje>vos, áreas y ac>vidades que contribuyan en mayor medida al cumplimiento de la
misión.
•  Análisis de los factores fundamentales para el éxito.
•  Análisis contextual. Especial referencia a la competencia.
•  Análisis de las ac>vidades sobre la base de la cadena de valor.
•  Análisis del sistema de las ac>vidades.
 Planeación de sistemas
•  Definición de una arquitectura de información .
•  La arquitectura de información se encarga del estudio, análisis, organización, disposición y
estructuración de la información en la organización, y de la selección y presentación de los datos
en los sistemas de información interac<vos.
•  Su principal obje>vo es facilitar al máximo los procesos de comprensión y asimilación de la
información, así como las tareas que ejecutan los usuarios en un espacio de información definido.
•  Durante esta etapa de definición se han de realizar una serie de ac<vidades que siguen una
determinada secuencia, que se muestra a con>nuación junto con el diccionario de planificación en
el que se archivan todos los documentos que se van generando.

Definición de un modelo de empresa

Valorar las estrategias actuales de empresa

Valorar los servicios actuales de infamación

Diccionario
de
Determinar las áreas de empresa y prioridades
planificación

Completar la nueva arquitectura de la información

Identificar futuros proyectos, revisar las conclusiones y aprobar el

plan.
 Planeación de sistemas
•  Examen de las áreas de empresa.
•  Es un examen general en un doble sen>do, abarca todo un área de empresa y el nivel de detalle
no debe ser muy elevado.

•  Las técnicas de estudio y análisis buscan conjuntamente el rediseño de los procesos para
hacerlos más eficaces y eficientes. En los úl>mos años se ha hablado de la reingeniería de
procesos o rediseño radical de los sistemas de información para mejorarlos y simplificarlos de
forma intensa.

•  Para desarrollar esta fase de reingeniería de procesos será necesario:

•  Cons>tuir un equipo de análisis mul>funcional.
•  Iden>ficar las medidas de rendimiento del área de empresa.
•  Ampliar y desarrollar los modelos de áreas de empresa.
•  Valoración del rendimiento del área de empresa y de los sistemas.
•  Establecer proyectos y prioridades.
•  Planificar proyectos de desarrollo reales.
•  Revisar las conclusiones y aprobar el plan.
 Elaboración del proyecto de desarrollo de un
sistema.
•  Se puede decir que el ciclo de vida es una
herramienta de ges<ón de proyectos- empleada
para planificar, elaborar y controlar el proyecto
de desarrollo de un sistema- y que involucra
tanto a analistas como a ingenieros de soSware,
programadores, propietarios y usuarios.
 Modelos del ciclo de vida de los sistemas de
información

•  Modelo clásico o en cascada.

•  Modelo incremental.
•  Modelo de desarrollo evolu>vo.
•  Modelo de proto>pado de requerimientos.
•  Modelo de espiral.
•  Modelo de construcción de proto>pos.
•  Modelo de síntesis automá>ca de soSware.
•  Modelo de sistemas suaves (soS)
 Modelo clásico o en cascada.
Ingeniería y Análisis del
Sistema

Análisis de los
Requisitos

Diseño

Codificación

Prueba

Mantenimiento

Ingeniería y Análisis del Sistema: Debido a que el soSware es siempre parte de un sistema
mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego
asignando algún subconjunto de estos requisitos al soSware.

Análisis de los requisitos del sodware: el proceso de recopilación de los requisitos se centra e
intensifica especialmente en el soSware. El ingeniero de soSware (Analistas) debe comprender el
ámbito de la información del soSware, así como la función, el rendimiento y las interfaces
requeridas.



 Modelo clásico o en cascada.
•  Diseño: el diseño del soSware se enfoca en cuatro atributos dis>ntos del programa: la estructura
de los datos, la arquitectura del soSware, el detalle procedimental y la caracterización de la
interfaz. El proceso de diseño traduce los requisitos en una representación del soSware con la
calidad requerida antes de que comience la codificación.

•  Codificación: el diseño debe traducirse en una forma legible para la maquina. El paso de
codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación
puede realizarse mecánicamente.

•  Prueba: una vez que se ha generado el código comienza la prueba del programa. La prueba se
centra en la lógica interna del soSware, y en las funciones externas, realizando pruebas que
aseguren que la entrada definida produce los resultados que realmente se requieren.

•  Mantenimiento: el soSware sufrirá cambios después de que se entrega al cliente. Los cambios
ocurrirán debido a que hayan encontrado errores, a que el soSware deba adaptarse a cambios
del entorno externo (sistema opera>vo o disposi>vos periféricos), o debido a que el cliente
requiera ampliaciones funcionales o del rendimiento.

Modelo incremental.
• 

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de
reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles
posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando
subconjuntos de requerimientos del sistema.

•  El modelo de desarrollo incremental provee algunos beneficios significa>vos para los proyectos:

•  Construir un sistema pequeño >ene siempre menos riesgo que construir un sistema grande.

•  Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos
planeados para los niveles subsiguientes son correctos.

•  Si un error importante es realizado, sólo la úl>ma iteración necesita ser descartada.

•  Reduciendo el >empo de desarrollo de un sistema decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.

•  Si un error importante es realizado, el incremento previo puede ser usado.

•  Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo
del próximo incremento.

 Modelo de desarrollo evolu<vo
(desarrollo por requerimientos).
•  Construye una serie de grandes versiones sucesivas de un producto. El modelo evolu>vo asume
que los requerimientos no son completamente conocidos al inicio del proyecto.

•  En el modelo evolu>vo, los requerimientos son cuidadosamente examinados, y sólo esos que son
bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen
una implementación parcial del sistema que recibe sólo estos requerimientos.

•  El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los
desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es
actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite
indefinidamente.

•  Todo lo que uno >ene que hacer es construir un subconjunto de requerimientos conocidos y
comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el
sistema sea desplegado o desarrollado.

 Modelo de proto<pado de requerimientos.
•  El proto>pado de requerimientos es la creación de una implementación
parcial de un sistema, para el propósito explícito de aprender sobre los
requerimientos del sistema.

•  Un proto>po es construido de una manera rápida tal como sea posible. Esto es
dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos
experimenten con el proto>po. Estos individuos luego proveen la
retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del
proto>po proporcionado, quienes capturan en la documentación actual de la
especificación de requerimientos la información entregada por los usuarios
para el desarrollo del sistema real.

 Modelo en espiral
•  Es un modelo evolu>vo que combina el modelo clásico con el diseño de proto>pos.
•  Incluye la etapa de análisis de riesgos.
•  Es ideal para crear productos con diferentes versiones mejoradas.
•  Este es el enfoque más realista actualmente. El modelo en espiral se divide en un numero de
ac>vidades estructurales, también llamadas regiones de tareas.

•  Generalmente, existen entre tres y seis regiones de tareas:
•  Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el
desarrollador y el cliente.

•  Planificación: las tareas requeridas para definir recursos, el >empo y otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.

•  Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones
relacionadas con el proyecto.

•  Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.

•  Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar
soporte al usuario.

•  Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la
evaluación de las representaciones del soSware creadas durante la etapa de ingeniería e
implementación durante la etapa de instalación.

 El modelo en espiral
Planificación Análisis de riesgos

Comunicación
con el cliente

Ingeniería

Evaluación del
cliente Construcción y adaptación
 Modelo de construcción de proto<pos

•  Este modelo arranca con el establecimiento de los requerimientos del sistema,

se definen los obje>vos del sistema y los requisitos conocidos con base en las
áreas de mayor prioridad e importancia para el sistema.

•  Luego se hace un diseño preliminar , sobre el cual se construye un proto>po o
modelo del sistema, compuesto a menudo de ventanas, tablas de la Base de
Datos, formatos de entrada y de salida básicos.

•  Un proto>po es una representación o modelo del producto de programación
que incorpora componentes del producto real. Por lo regular, un proto>po
>ene un funcionamiento limitado en cuanto a capacidades, confiabilidad o
eficiencia.

Modelo de construcción de
proto<pos
Recolección
refinamiento
requisitos

Producto de Diseño
ingeniería rápido

Refinamiento Construcción
del prototipo del prototipo

Evaluación
del prototipo
por el cliente
 Modelo de síntesis automá<ca de sodware

•  Se define el sistema u>lizando un lenguaje formal.

•  La implementación es automá>ca, asis>da por el Ordenador.

•  La documentación se genera de forma automá>ca.

•  El mantenimiento se realiza “por sus>tución” no mediante “parches”.

•  Dificultad en la par>cipación del usuario.

•  Diseños poco op>mizados.