UNIVERSIDAD MARIANO GALVEZ DE GUATEMALA

FACULTAD DE INGENIERIA EN SISTEMAS DE INFORMACION

INGENIERIA EN SISTEMAS DE INFORMACION

ANÁLISIS DE SISTEMAS II
UNIVERSIDAD MARIANO GALVEZ DE GUATEMALA
FACULTAD DE INGENIERIA EN SISTEMAS DE INFORMACION
INGENIERIA EN SISTEMAS DE INFORMACION

Evaluación del curso

Evaluación del curso
Primer Parcial 10 puntos
Segundo Parcial 20 puntos
Laboratorios, tares y
trabajos de investigación 20 puntos
Examen Final 50 puntos

__________
Nota Final 100 puntos
UNIVERSIDAD MARIANO GALVEZ DE GUATEMALA
FACULTAD DE INGENIERIA EN SISTEMAS DE INFORMACION
INGENIERIA EN SISTEMAS DE INFORMACION

Especificación de
Requerimientos del Software
(ERS)
Importancia de los requerimientos
Requerimiento
● “La propiedad que debe ser cumplida para
solucionar un problema del mundo real”
PMBOK.

● Condición o necesidad de un usuario para

resolver un problema o alcanzar un objetivo.
IEEE
Especificación de Requerimientos
de Software (ERS)
● Es una descripcion detallada del software
que desea ser construido.
● Incorpora requerimientos Funcionales y No
funcionales de un sistema.
o R. Funcionales. Una función es algo que hará el
sistema. Describen una interacción entre el sistema
y su ambiente.
o R. No funcionales. Describen restricciones que
limitan las opciones de solucionar el problema.
Restricciones cuantitativas o precisión.
Comunmente no impuestos por el cliente.
Características de ERS
Características que han de reunir los requisitos
para ser de alta calidad.
● Correctos, sin errores.
● Consistentes.
● No ambiguos.
● Son completos:
o Externamente completa si contiene todas las
propiedades deseadas por el cliente.
o Internamente completa si no existen referencias no
definidas.
Características de ERS
● Son realistas. Puede el sistema hacer lo que el
cliente desea.
● Describen algo necesario para el cliente.
● Verificables. Un requisito es verificable si existe
algún proceso finito de coste razonable que
pueda probar que el producto software cumple
con el requisito.
● Son rastreables. Trazables, el origen de cada
requisito está claro y se posibilita la referencia
de cada uno de estos requisitos en desarrollos
futuros o incrementos de la documentación.
Impacto de fallos en ERS
Costo del cambio de ERS
Quienes participan en la toma de
requerimientos
Participantes
Stakeholders
Stakeholders
Facilitadores del proceso de toma
de requerimientos
● Compromiso
● Buena comunicación
● Respeto
● Honestidad
Cómo obtenemos los
Requerimientos
Ingeniería de requerimientos
Comprende 3 actividades generales
Identificar las necesidades del
negocio
● Estudiar el dominio del problema
● Identificar aspectos positivos y negativos de
la situación actual
● Estudiar el modelo de negocio del cliente.
● Estudiar el entorno tecnológico del cliente
● Obtener y documentar las necesidades de
clientes y usuarios
Desarrollar los requerimientos
● Desarrollar la visión general del sistema
● Documentar los requisitos del sistema
● Definir las posibilidades de integración del
sistema
● Analizar los requisitos del sistema
● Verificar la calidad de los requisitos del
sistema
● Validar los requisitos del sistema
Gestión de los requerimientos
● Definir el ciclo de vida de los requisitos del
sistema
● Gestionar las lineas base de los requisitos
del sistema (versiones)
● Gestionar los conflictos de los requisitos
● Gestionar las peticiones de cambio
● Gestionar la trazabilidad de los requisitos del
sistema
Técnicas para la captura de
requerimientos
Elaboración de cuestionarios.
1.Recomendable para grandes poblaciones (+30 personas).
2.Recomendable como base para posterior entrevista personal.
3.Crear un marco para el análisis de resultados. (visión clara de
cómo utilizar la información)
4.Comprobar que existe información suficiente en el personal
“cuestionado”.
5.Garantizar que es comprensible (no utiliza argot técnico).
6.Probarlo antes de comenzar
7.Verificar la comprensión.
Técnicas para la captura de
requerimientos
Tipos de cuestionarios:
● Para recopilar datos estructurados. 2
Modalidades:
o Mediante Lista de cuestiones concretas y de
respuesta cerrada.–
¿Cuánto lleva operando el actual
sistema de facturación (en años)?.
o 2.Mediante índices. –
¿Importancia de estos factores
para adquirir un OS?
Técnicas para la captura de
requerimientos
Tipos de cuestionarios:
● Para recopilar información abierta
o Se formula una pregunta abierta. ¿Cuál son para
usted los factores principales en la selección de
proveedor de servicios de Internet”
o Útiles para obtener una información inicial sobre el
área.
o Importante evitar sesgos.
Técnicas para la captura de
requerimientos
Entrevistas:
● Su obejtivo es obtener toda la información
posible de la visión que el entrevistado tiene
de los requisitos.
● Depende de la habilidad del entrevistador
para crear un clima de confianza.
● Resulta útil planificar las entrevistas para
evitar sesgos (evitar que un grupo incline a
un lado el proceso).
Técnicas para la captura de
requerimientos
Llevar a cabo la entrevista:
● Preparar un marco para la entrevista
(mediante un cuestionario)
● Confirmar detalles del entrevistado
● Establecer la finalidad de la entrevista con el
entrevistado
● Organizar una lugar adecuado.
● Confirmar los detalles por escrito.
Técnicas para la captura de
requerimientos
Talleres:
● Reunión de partes interesadas.
● Sesiones intensivas y estructuradas
concentradas en uno o dos días.
● Es preciso una importante preparación
previa:
o Definir con los participantes la finalidad del taller.
o Facilitarles información histórica.
Técnicas para la captura de
requerimientos
Talleres:
● El taller ha de ser dirigido por un experto
para:
o Garantizar que todo los participantes aportan sus
puntos de vista.
o No se desvían del propósito del taller.
● Los requisitos capturados en el taller se
registran junto con todas las cuestiones y
acciones resultantes.
Técnicas para la captura de
requerimientos
Talleres:
● Se genera un informe para documentar los
resultados y base de la especificación de
requisitos.
● Tiene la ventaja de reunir a los participantes
pudiendo debatirse las cuestiones más
controvertidas y resolver así requisitos
aparentemente divergentes satisfaciendo a
las partes.
El resultado esperado
ERS
● Documento basado en un estándard o
personalizado acorde al entorno
Ejemplo del estándar IEEE 830
1. Introducción
1.1. Objetivo
1.2. Ámbito
1.3. Definiciones, Siglas y Abreviaturas
1.4. Referencias
1.5. Visión Global
2. Descripción general
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Características del usuario
2.4. Limitaciones generales
2.5. Supuestos y dependencias
2.6 Requisitos Futuros
3. Requisitos específicos
3.1 Interfaces Externas
3.2 Funciones
3.3 Requisitos de rendimiento
3.4 Atributos del Sistema
3.5 Otros Requerimientos
3. Requisitos específicos
3.1. Requisitos funcionales
3.1.1. Requisito funcional 1
3.1.1.1. Introducción
3.1.1.2. Entradas
3.1.1.3. Procedimiento
3.1.1.4. Salidas
3.2. Requisito de Interfaz externa
3.2.1. Interfaces de usuario
3.2.2. Interfaces hardware
3.2.3. Interfaces software
3.2.4. Interfaces de comunicaciones
3.3. Requisitos de ejecución
3.4. Restricciones de diseño
3.4.1. Acatamiento de estándares
3.4.2. Limitaciones hardware
3.5. Atributos de calidad
3.5.1. Seguridad
3.5.2. Mantenimiento
3.6. Otros requisitos
3.6.1. Base de datos
3.6.2. Operaciones
3.6.3. Adaptación de situación
Ejemplos
● http://www.nyu.edu/classes/jcf/CSCI-
GA.2440-
001/handouts/Assignment1SampleSolution.p
df
● http://www.va.gov/VLER/docs/BusinessReqt
Docs/VLER_RequirementsSpecificationDocu
ment_Core_20130208.pdf