Análisis y modelado de

Sistemas de Información
 Captura de
requisitos
 Competencia(s)
específica(s):

• Identificar áreas de oportunidad en una

organización, para la propuesta y diseño

de sistemas de información.

 Analizar diversas alternativas de

solución a partir de la identificación y
definición de requerimientos
especificados por el cliente.
 Captura de
requisitos
 Competencia(s)
específica(s):

• Identificar áreas de oportunidad en una

organización, para la propuesta y diseño

de sistemas de información.

 Analizar diversas alternativas de

solución a partir de la identificación y
definición de requerimientos
especificados por el cliente.
 Temario:
1.Tipos de requisitos.
2.Fuentes de datos para el análisis del sistema.
2.3 Selección y diseño de instrumentos para la
recopilación de Información.
4.Captura de requisitos candidatos.
5.Selección de metodología de desarrollo.
2.6 Modelo del negocio.
7. Modelo del dominio.
8. Validación de requerimientos.
2. 9 Definición de propuesta de solución.
 Glosario de
términos
 Requisitos
 Requerimientos
 Fuentes de datos
 Instrumentos para
recolectar información
 Modelo del negocio
 Modelo del dominio
 2.1 Tipos de requisitos

 ¿Qué es el análisis de requisitos? 

“… permite especificar las características
operacionales el software (función, datos y
rendimientos), indica la interfaz del
software con otros elementos del sistema y
establece las restricciones que debe
cumplir el software”, (Pressman,
2006)

R=Requisitos del sistema y el papel asignado al

software
 2.1 Tipos de requisitos

 ¿Qué es un
requerimiento? 

Una característica, propiedad

o comportamiento que se
desea de un sistema
2.1 Tipos de requisitos
a) Requerimientos funcionales y no
funcionales

Una característica, propiedad

o comportamiento que se
desea de un sistema
2.1 Tipos de requisitos
a.1) Requerimientos funcionales
Son declaraciones de los servicios que
debe proporcionar el sistema, de la manera
en que éste debe reaccionar a entradas
particulares y de cómo se debe comportar
en situaciones particulares. En algunos
casos, los requerimientos funcionales
declaran lo que el sistema no debe hacer.
2.1 Tipos de requisitos
1. ) Requerimientos funcionales, ejemplos

 El sistema debe permitir generar una

orden de servicio
 El sistema debe generar el número de folio
 El sistema debe administrar el catálogo de servicios
 El sistema no debe permitir eliminar un servicio
 El sistema debe permitir generar la
verificacióndede factibilidad
solicitud
 Elsistema debe el costo total de
generar servicios los
2.1 Tipos de requisitos
1. ) Requerimientos funcionales

Cuando se especifican deben

ser:
 Completos
 Consistentes

Consideran:
 Reglas de negocio
 Características
 Interfaz del usuario
2.1 Tipos de requisitos
a.2) Requerimientos no funcionales

Son restricciones de los servicios o

funciones ofrecidos por el sistema. Son
restricciones de tiempo, sobre el proceso
de desarrollo y estándares. Los
requerimientos no funcionales apenas
aplican a características o se
individuales del sistema. servicios
2.1 Tipos de requisitos
a.1) Requerimientos
funcionales
2.1 Tipos de requisitos
a.2) Requerimientos no funcionales,
ejemplos
 El sistema debe desarrollarse en PHP
 El sistema debe considerar la base de
datos en MySQL.
 El sistema debe ejecutarse en plataforma web
 El sistema debe utilizar el navegador Mozilla
 El sistema debe poseer derechos de autor.
 El sistema debe capturar una solicitud
de servicio en menos de 3 minutos.
 2.1 Tipos de requisitos
a.3) Requerimientos del
dominio

Sederivan del dominio

de aplicación del sistema,
máslas
de que específica
necesidades de s
los usuarios.
 2.1 Tipos de requisitos
a.3) Requerimientos del dominio,
ejemplos

 Todas las interfaces deberán

utilizar la
imagen institucional de acuerdo
a la plantilla v1.0
 La
estarinformación de los usuarios
protegida conforme a la
deberá
Federal de Ley
Protección Personales de
Datos
2.1 Tipos de requisitos
b) Requerimientos del usuario

Los requerimientos del usuario para un

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.
2.1 Tipos de requisitos
b) Requerimientos del usuario,
ejemplos

 El controlar todos
sistema
ingresos obtenidosá por los losdiferentes
servicios en las unidades
diferentes
adscritas al organismo.
 El sistema emitirá un reporte diario con
los ingresos por cada una de las unidades
adscritas al organismo.
2.1 Tipos de requisitos
c) Requerimientos del sistema

Losrequerimientos del
sistema establecen con detalle las
funciones, ser vicios y
restriccione operativas del
s sistema.
2.1 Tipos de requisitos
c) Requerimientos del sistema, ejemplos

 El formulario de solicitud se
guardará por 5 años ejercicio,
desde la fecha de la petición.

 El sistema mantendrá una bitácora

con los registros de las
peticiones
que se han hecho al mismo.
2.1 Tipos de requisitos
d) Especificación de la interfaz

Interfaz: Conexión o
comunicación que se da de
manera física y a nivel de
utilidad entre dispositivos o
sistemas.
2.1 Tipos de requisitos
d) Tipos de interfaces

 De procedimientos o Interfaces
de programación de aplicaciones
(API’S).
 De estructuras de datos
 Representaciones de datos
2.1 Tipos de requisitos
e) Documento de requerimientos del software

Representación oficial que deben

implementar los desarrolladores de
SW. Incluye tanto los requerimientos
del sistema como una especificación
detallada de los requerimientos del
sistema.
2.1 Tipos de requisitos
2.1 Tipos de requisitos
2.2 Fuentes de datos para el análisis del sistema

¿Qué son las

fuentes de
•
datos?
Son las entidades proveedoras de
información fiable, necesaria,
reducida, útil y consecuente con los
propósitos del sistema de
información a desarrollar.
2.2 Fuentes de datos para el análisis del sistema

Fuentes
internas
• Lasfuentes más importante de
hechos
de estudio a disposición del
analista es la gente. Los
requerimientosde
información puede ser planteado
mejor
por los usuarios de la información.
2.2 Fuentes de datos para el análisis del sistema

Fuente
s
• externa
La exploración de otros
subsistemass de
información dentro de la organización
puede ser una fuente útil de recopilación
de datos, procesamiento de datos o de
ideas y técnicas para el reporte de la
información.
2.2 Fuentes de datos para el análisis del sistema

El sistema
actual.
Es verdaderamenteraro que un analista
tenga la oportunidad de desarrollar un
sistema de información en
donde anteriormente no haya existido ninguno.
frecuencia se Con una gran cantidad
investigando
dedica y documentandode el tiempo
sistema anterior, pero un
análisis ventaja y desventajas puede ayudar
de s a y qué tan
estudiarse
determinarel sistema
cuándo anterior.
extensamente debe
2.2 Fuentes de datos para el análisis del sistema

El sistema
actual.
Las principales ventajas de analizar
el sistema anterior:
• Eficacia del sistema actual.

• Ideas de diseño.

• Reconocimiento de recursos.

• Conocimiento de conversión.

• Punto de partida común.

Las principales desventajas de
2.3 Selección y diseño de instrumentos para
la recopilación de Información.
• Cuestionarios
• Entrevistas
• Sondeos
• Encuestas
• Collage
• Dibujos
• Diagramas de flujo de datos
• Tablas de Organización
• Descripción de puestos
• Manuales Operativos.
• Representación física de las Organizaciones.
Diseño conjunto de aplicaciones
• Investigación
• Observación.
2.3 Selección y diseño de instrumentos para la
recopilación de Información.

Entrevistas

Una entrevista para

recabar
información es una
conversación dirigida con un
propósito específico que
utiliza un formato de preguntas
y
respuestas.
2.3 Selección y diseño de instrumentos para la
recopilación de Información.

Entrevistas

Se necesita obtener las opiniones

de los entrevistados y suparecer
acercadel estado del
metas
actual organizacionales ysistema,
personales y
procedimientos informales.
2.3 Selección y diseño de instrumentos para
la recopilación de Información.
Pasos para la planeación de la entrevista

1. Leer los antecedentes

2. Establecer los objetivos de
la entrevista
3. Decidir a quien
entrevistar
4. Preparar al entrevistado
5. Decidir el tipo de
preguntas
y la estructura: (Abiertas,
cerradas, pirámide, embudo,
diamante)
2.3 Selección y diseño de instrumentos para la
recopilación de Información.
2.3 Selección y diseño de instrumentos para
la recopilación de Información.

Preguntas cerradas en una entrevista

¿En promedio cuántas llamadas de atención al cliente

recibe a la semana?
• ¿Cuál de las siguientes fuentes de información es
más valiosa para Usted?
• Formularios de quejas llenados por el cliente

• Quejas recibidas por correo de los clientes que visitan

el sitio Web
• Mencione las dos prioridades para mejorar la
infraestructura de tecnología.
2.3 Selección y diseño de instrumentos para la
recopilación de Información.
Cuestionario
Encuesta Diagrama
de flujo Manual
operativo
Diseño conjunto de
aplicaciones
Muestreo
Investigación
 2.4 Captura de requisitos
candidatos
Pasos del flujo de trabajo
para la captura de
requisitos
 Enumerar los requisitos
candidatos.
 Comprender el
contexto del
sistema
 Capturar requisitos
funcionales
 Capturar requisitos no
funcionales
 2.4 Captura de requisitos
candidatos
Pasos del flujo de trabajo
para la captura de
requisitos
 Enumerar los requisitos
candidatos.
 Lista de
características con
requisitos candidatos
utilizada
para la planificación del
trabajo.
 2.4 Captura de requisitos
candidatos
Pasos del flujo de trabajo
para la captura de
Derequisitos
cada característica se registra:

- Nombre corto
- Descripción
- Estado (propuesto, aprobado, incluido, o
validado)
- Coste estimado de implementación (en
término de tipos de recursos y horas-
hombre)
- Prioridad (crítico, importante, o secundario)
- Nivel de riesgo asociado a la implementación
de la característica (crítico, significativo,
2.4 Captura de requisitos
candidatos
2.5 Selección de metodología de
desarrollo.

¿XP?
¿PUA?
¿SCRU
M?
¿DES?
2.5 Selección de metodología de
desarrollo.
XP Desarrolla el producto aplicando la
planificación, el análisis y el diseño, durante
todas las fases de desarrollo del producto.
Sugiere la creación de historias de usuario,
tarjetas CRC durante el diseño, la aplicación
de pruebas unitarias antes de la
codificación, la codificación en parejas así
c o m o la aplicación de pruebas unitarias,
que pueden ser automatizadas.
SC RU M Desarrolla p o r incrementos, basa la calidad
del pr od u ct o en el conocimiento tácit o de las
personas, tiene solapamientos en las fases
de desarrollo, define sprints p o r cierto
t i e m p o para ejecutar las tareas y alcanzar
las metas propuestas.
2.5 Selección de metodología de
desarrollo.
PU A Desarrolla en serie para lo grande e
iterativamente para lo pequeño. El equipo
entrega incrementos de S W significativos tan
rápido c o m o sea posible. En las iteraciones
considera actividades como: modelado,
implementación, pruebas, configuración y
administración, administración del ambiente.
D esar r ollo Desarrolla el p rod u cto de software bajo los
esbelto principios de: eliminar el desperdicio,
de generar calidad, crear conocimiento,
software aplazar el compromiso, entregar rápido,
respetar a las personas y o p t i m i z a r el todo.
 2.8 Validación de
requerimientos
Propósito:

Mostrar cuáles requerimientos

realmente definen el
sistema
que el cliente desea
2.8 Validación de requerimientos

Proceso de
validación:
Verificaciones de validez
Verificaciones de consistencia
Verificaciones de
completitud Verificaciones
de realismo Verificabilidad
2.8 Validación de requerimientos

Técnicas de
validación:
Revisiones de
requerimientos
Construcción de prototipos
Generación de casos de
pruebas
2.9 Definición de propuesta de solución

Documento con:

Caracterización de la
empresa
√ Nombre
√ Tipo
√ Tamaño
√ Giro
√ Misión
√ Visión
√ Valores
2.9 Definición de propuesta de solución

Documento con:

Requisitos funcionales
Requisitos no funcionales
Modelo de negocio
√ Reglas de
negocio
√ Casos de uso
Modelo de dominio
√ Diagrama de
clases
Fuentes de información

• Kendall, K. & kendall, J. (2005) Análisis y Diseño de Sistemas

de Información. Capítulos 4 y 5.

• Sommerville, I. (2005). Ingeniería del software. Madrid:

Pearson educación. Pp. 144-145.

• Reocities (2014). Análisis estructurado de sistemas de

información. Consultado en Septiembre 2014. Disponible
en:
http://www.reocities.com/SiliconValley/pines/7894/sistemas/
estructurado.html