Actividad de la unidad 2

1. E L V I S M U Ñ O Z | V - 2 6 8 9 4 2 0 7
INGENIERÍA DE
REQUERIMIENTOS

2. ¿QUÉ SON LOS REQUERIMIENTOS?
Los requerimientos para un sistema son descripciones de lo
que el sistema debe hacer: el servicio que ofrece y las
restricciones en su operación. Tales requerimientos reflejan las
necesidades de los clientes por un sistema que atienda cierto
propósito, como sería controlar un dispositivo, colocar un
pedido o buscar información.
Al proceso de descubrir, analizar, documentar y verificar estos
servicios y restricciones se le llama ingeniería de
requerimientos (IR).

3. REQUERIMIENTOS FUNCIONALES
• Los requerimientos funcionales de un sistema,
son aquellos que describen cualquier actividad
que este deba realizar, en otras palabras, el
comportamiento o función particular de un
sistema o software cuando se cumplen ciertas
condiciones.
• Por lo general, estos deben incluir funciones
desempeñadas por pantallas específicas,
descripciones de los flujos de trabajo a ser
desempeñados por el sistema y otros
requerimientos de negocio.

4. REQUERIMIENTOS NO FUNCIONALES
• Se trata de requisitos que no se
refieren directamente a las funciones
específicas suministradas por el
sistema ,sino a las propiedades del
sistema como rendimiento, seguridad,
disponibilidad.
• Se originan en la necesidad del
usuario, debido a restricciones
presupuestarias, políticas
organizacionales, la necesidad de
interoperabilidad con otros sistemas de
software o hardware, entre otros

5. ATRIBUTOS DE
CALIDAD
Hewlett-Packard (HP) desarrolló un
conjunto de atributos de la calidad
del software a los que se dio el
acrónimo FURPS: funcionalidad,
usabilidad, confiabilidad,
rendimiento y mantenibilidad. Los
atributos de calidad FURPS
representan el objetivo de todo
diseño de software:
• Funcionalidad
• Usabilidad
• Confiabilidad
• Rendimiento
• mantenibilidad

6. ADQUISICIÓN Y ANÁLISIS
Actores:
Sommerville y Sawyer definen actores como “cualquier persona que se beneficie en forma directa o indirecta
del sistema en desarrollo”.
Cada participante tiene un punto de vista diferente respecto del sistema, obtiene distintos beneficios cuando
éste se desarrolla con éxito y corre distintos riesgos si fracasa el esfuerzo de construcción.
Necesidades:
Diseñar y construir un elegante programa de
cómputo que resuelva el problema equivocado
no satisface las necesidades de nadie.
Por eso es importante entender lo que el
cliente desea antes de comenzar a diseñar y a
construir un sistema basado en computadora.
Objetivos:
El objetivo de los requerimientos de ingeniería es
proporcionar a todas las partes un entendimiento
escrito del problema.
Esto se logra por medio de varios productos del trabajo:
escenarios de uso, listas de funciones y de
características, modelos de requerimientos o
especificaciones.

7. FASES
En esta etapa la función primordial del analista en
todo momento es reconocer los elementos del
problema tal y como los percibe el usuario.
RECONOCIMIENTO DEL PROBLEMA
El modelo servirá de pilar para el diseño del
software y como base para la creación de una
especificación del software.
MODELIZACIÓN
La documentación del análisis de requerimientos y
manuales, permitirán una revisión por parte del
cliente, la cual posiblemente traerá consigo
modificaciones en las funciones del sistema por lo
que deberán revisarse el plan de desarrollo y las
estimaciones previstas inicialmente.
REVISIÓN
En esta etapa el analista debe centrarse en el flujo
y estructura de la información, definir las funciones
del software, determinar los factores que afectan
el desarrollo de nuestro sistema y descubrir las
restricciones del diseño.
EVALUACIÓN Y SÍNTESIS
Esto más adelante permitirá llegar a determinar si
se ha llegado a comprender el software, en los
casos que se lleguen a modelar se pueden dejar
plasmados manuales.
ESPECIFICACIÓN

8. RECOLECCIÓN DE REQUERIMIENTOS
(TÉCNICAS)
• Mediante ellas se obtiene una gran cantidad de
información adecuada a través del usuario.
• Pueden ser usadas para obtener una visión general
del dominio del problema.
• Son flexibles y permiten combinarse con otras
técnicas.
ENTREVISTAS
• Representan los requerimientos desde el punto de
vista del usuario.
• Permiten representar más de un rol para cada
afectado.
• Identifica nuevos requerimientos , dentro de un
conjunto de requerimientos.
CASOS DE USO
• La producción de ideas en grupos puede ser más
efectiva que la individual.
• Aflora una gran cantidad de ideas sin ataduras.
BRAINSTORMING
• Ahorra tiempo, elimina retrasos del proceso y
mejora la calidad del sistema.
• Evita que los requerimientos sean demasiado
específicos o demasiados vagos.
• Evita funcionalidad sobredimensionada.
JAD