Curso 2K3

Equipo docente: Ing. Germán Vélez

Ing. Ana Strub | Ing. Andrea Delgado
 Marco de trabajo
PROCESO DE
DESARROLLO
Pensar en el SI de soporte
Estudio de la organización SISTEMAS DE INFORMACIÓN
MODELADO DE SISTEMA DE SOFTWARE
PROCESOS DE NEGOCIO

INGENIERÍA DE SOFTWARE
Herramientas para definir SW
CONSTRUCCIÓN DE MODELOS

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 2

 “La parte más difícil de construir un sistema de software es decidir precisamente qué

construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los

requerimientos técnicos detallados... Ninguna otra parte del trabajo afecta tanto el

sistema resultante si se hace incorrectamente. Ninguna otra parte es tan difícil de

rectificar más adelante”

Brooks, Fred. No Silver Bullet - Essence and Accidents of Software Engineering.

IEEE Computer, Abril de 1987.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 3

 Mejora permanente de las técnicas de desarrollo de software
 La pregunta que nos hacemos entonces es…

¿Por qué se siguen presentando fracasos en los proyectos de hoy en día?

 Los proyectos están plagados de:
 Retrasos

 Problemas de calidad

 Sobrecostos

 CAMBIO!!!!

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 4

 Los requerimientos son la causa más común por la que fallan los
proyectos de software. [Standish Group’s CHAOS Report].

 El cambio, la incomprensión e inexactitud en los requerimientos son

las causas más comunes por las que falla un proyecto.

 La incapacidad de gestionar el cambio.

 El afán por comenzar el “trabajo en serio!!”

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 5

 Debe poder
detectarse todas las
necesidades y deseos
de un cliente
Un requerimiento es
una característica del
sistema o una Es difícil saber
descripción de algo exactamente lo que el
que el sistema es sistema debe hacer.
capaz de hacer con el
objeto de satisfacer el
propósito del mismo.
Comprender la
naturaleza de los
problemas puede ser
muy complejo,
especialmente si el
sistema es nuevo.
Para proponer y
desarrollar un sistema
de información se
debe comprender la
naturaleza del
problema.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 6

 Descripciones de
servicios o de
aquello que el
sistema es capaz
de hacer y debe
cubrir

Las mejoras Necesidades de

posibles en información
relación al sistema planteadas por el
actual usuario/cliente
Los
REQUERIMIENTOS
son características
que deben incluirse
en un nuevo sistema
considerando:

Restricciones que
Los problemas el sistema deba
observados considerar,
traducidos en contemplando las
necesidades que el necesidades o
sistema deberá condiciones
abarcar establecidas por el
usuario

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 7

 En el estándar IEEE-Std 610 (1990), se define
“requerimiento” de la siguiente manera:

(2) Una condición o capacidad

que debe cumplir o poseer un
(1) Una condición o capacidad (3) Una representación
sistema o componente de sistema
requerida por un usuario para documentada de una condición o
para satisfacer un contrato,
resolver un problema o lograr un capacidad como se define en (1)
estándar, especificación u otros
objetivo. o (2).
documentos de imposiciones
formales.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 8

 Permiten que los ANALISTAS del sistema
expliquen cómo han entendido lo que el cliente
pretende del sistema.

Indican a los DISEÑADORES y

DESARROLLADORES del sistema qué
funcionalidad, restricciones y características va a
tener el sistema resultante.

Indican al EQUIPO DE PRUEBAS qué

comprobaciones llevar a cabo para demostrar al
cliente que el sistema que se le entrega es lo que
había solicitado y cubre sus necesidades.
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 9
NECESARIO
• Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir.

CONCISO
• Un requerimiento es conciso si es fácil de leer y entender.

COMPLETO
• Un requerimiento está completo si no necesita ampliar detalles en su redacción para su comprensión.

CONSISTENTE
• Un requerimiento es consistente si no es contradictorio con otro requerimiento.

NO AMBIGUO
• Un requerimiento no es ambiguo cuando tiene una sola interpretación.

VERIFICABLE
• Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de distintos
métodos de verificación.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 10

 Es conveniente hacer una clara separación entre los diferentes niveles de descripción

Requerimientos Requerimientos
del usuario del sistema

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 11

 Documenta los deseos y necesidades del cliente y se expresa en
un lenguaje claro para él.

 Son declaraciones en lenguaje natural y en diagramas de los

servicios que se espera que el sistema provea y de las restricciones
bajo las cuales debe operar.

 Audiencias para requerimientos C (del cliente)

 La audiencia primaria es la comunidad del cliente.

 La audiencia secundaria es la comunidad del desarrollador.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 12

 Establecen de manera detallada y estructurada los servicios y restricciones
del sistema.

 El documento de requerimientos del sistema, algunas veces denominado

especificación funcional, debe ser preciso.

 Sirve como una especie de contrato entre el comprador del sistema y los
desarrolladores.

 Audiencias para requerimientos del sistema

 La audiencia primordial es la comunidad del desarrollador.
 La audiencia secundaria es la comunidad del cliente.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 13

 Requerimientos del usuario

Requerimientos del sistema

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 14

 La relación entre los dos niveles de descripción de los requerimientos y su
definición en el documento de ERS (IEEE Std. 830) se puede visualizar en el
siguiente gráfico.

ERS (IEEE Std 830)

1. Introducción
2. Descripción General Requerimientos
3. Requerimientos específicos del Sistema
Requerimientos
4. Información de soporte (Detalle de los
del Usuario/Cliente
mismos)

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 15

 Requerimiento Requerimiento
no funcional funcional

• razones de la creación del • descripción de lo que el

sistema. sistema hace.
REQUERIMIENTOS
• restricciones del ambiente DEL SISTEMA
• ¿qué información necesita ser
en el que el sistema funciona. mantenida?
• restricciones globales sobre • ¿qué necesita ser procesado?
cómo debe construirse y
funcionar el sistema.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 16

 Definen las funciones que el sistema será capaz de realizar y describen cómo
debe comportarse el sistema ante determinado estímulo.
 Describen la funcionalidad o los servicios que se espera que el sistema
proveerá, detallando las transformaciones que el sistema realiza sobre las
entradas para producir salidas.
 Refieren a lo que el sistema debe hacer.

¿Cómo modelar los requerimientos?

 Es un listado de oraciones que se expresan en verbo en infinitivo. Se utilizan
verbos de acciones que un sistema informático pueda realizar.
 Se plantean los Requerimientos Funcionales (RF) en forma:
 Requerimientos Funcionales Globales
 Requerimientos Funcionales Detallados

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 17

Para un sistema de procesamiento de ventas, Para un sistema de un videojuego, el sistema
el sistema deberá: deberá:
 Gestionar pedidos de los clientes  Generar dos tipos de personajes: los que están
 Registrar los pedidos de los clientes bajo el control del jugador y personajes
 Generar facturas de venta
“extraños” bajo el control de la aplicación.
 Permitir al jugador definir un personaje
 Administrar datos de los clientes principal.
 Registrar datos de los clientes
 Modificar datos de clientes  Mantener cualidades para cada personaje:
fuerza, velocidad, paciencia.
 Consultar clientes
 Mantener un valor para cada cualidad de cada
 Emitir reportes de ventas en un rango de fecha personaje.
dado
 Permitir que los personajes puedan
 Administrar datos de los productos que se “interactuar” cuando están en la misma área.
comercializan y su stock actual
 Registrar producto  ......
 Modificar producto
 Consultar producto
 Registrar movimientos de stock de cada producto
 ....

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 18

 Restricciones de los servicios o funciones sobre el sistema que limita la elección
de alternativas en la etapa de diseño y construcción del sistema.

 Consideran aspectos de implementación, de arquitectura, normativas y

definiciones que restringen el desarrollo del sistema.

 Características que de una u otra forma pueden limitar el sistema, como por
ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad,
portabilidad, estándares, aspectos de hardware, lenguajes de programación,
navegadores, sistemas operativos.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 19

Para un sistema de procesamiento Para un sistema de un videojuego, el
de ventas, el sistema deberá: sistema deberá:
 Operar en un entorno de web.  Operar con S.O. Windows 10.
 Definir distintos niveles de usuario y  Operar en un equipo con un mínimo
asignar permisos de acceso según el de 16 Gb de RAM.
nivel de los mismos.
 El lenguaje de implementación
 Almacenar los datos en una BD deberá ser JAVA.
Relacional SQL Server 2017 o
 ......
superior.
 ......

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 20

 Requerimientos
No Funcionales

Requerimientos Requerimientos de Requerimientos

del Producto la organización externos

Requerimientos Requerimientos Requerimientos Requerimientos Requerimientos

de eficiencia de confiabilidad de seguridad regulatorios éticos

Requerimientos Requerimientos Requerimientos Requerimientos Requerimientos

de usabilidad ambientales operacionales de desarrollo legales

Requerimientos Requerimientos Requerimientos Requerimientos

de rendimiento de espacio de contables de protección/
seguridad

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 21

 Estos requerimientos especifican el comportamiento del producto, por
ejemplo:
 Requerimientos de eficiencia o de desempeño en la rapidez de ejecución,
requerimientos de tamaño de memoria requerida, tamaño en disco necesario,
cantidad de transacciones procesadas por segundo, tiempo de respuesta, capacidad
del sistema.

 Requerimientos de confiabilidad que fijan la tasa de fallas para que el sistema sea
considerado aceptable, tiempo medio entre fallas, disponibilidad, tiempo de reinicio
después de fallas.

 Requerimientos de seguridad.

 Requerimientos de usabilidad: colores, tipos de letras diseños de pantallas o

reportes, tiempo de capacitación, velocidad de operación, necesidades de
documentación del producto.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 22

 Se derivan de las políticas y procedimientos existentes en la
organización del cliente y en la del desarrollador.
 Algunos ejemplos son:
 Requerimientos del proceso operacional que definen cómo se utilizará el
sistema.

 Requerimientos del proceso de desarrollo que establecen el lenguaje de

programación , estándares del entorno o proceso de desarrollo a utilizar.

 Requerimientos ambientales que definen el entorno de operación del sistema.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 23

 Esta clasificación cubre todos los requerimientos que se derivan de
los factores externos al sistema y de su proceso de desarrollo. Éstos
incluyen:

 Requerimientos regulatorios que definen lo que debe hacer el sistema para ser
aprobado en su uso por su regulador (por ejemplo un Banco Central).

 Requerimientos legislativos que deben seguirse para asegurar que el sistema

opere dentro de la ley.

 Requerimientos éticos para asegurar que será aceptado por el usuario y por el
público en general.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 24

 Los requerimientos pueden ser tediosos
 Los requerimientos pueden estar desorganizados
 Los requerimientos, como lo expresan los usuarios, pueden ser imprecisos,
ambiguos o erróneos
 La captura de requisitos es un proceso continuo
 Los clientes no siempre conocen sus verdaderas necesidades
 Yo entiendo los requerimientos, pero ¿Qué hace realmente el sistema?

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 25

 No queremos que
nos pase esto!

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 26

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 27
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos
 Es el proceso de descubrir, analizar, documentar
y verificar los servicios y restricciones que debe
considerar el sistema a desarrollar.

Permite una especificación de los requerimientos

completa, consistente y no ambigua….
la cual servirá como base para acuerdos comunes
entre todas las partes involucradas y en donde se
describen las funciones que realizará el sistema.
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 29
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 30
CONCEPTO
• Proceso en donde se adquiere el conocimiento del trabajo del
cliente / usuario, se busca comprender sus necesidades y se
detallan las restricciones medioambientales.
RESULTADO
• Conjunto de los requerimientos de todas las partes involucradas.

TÉCNICAS
• Entrevistas, cuestionarios, observación, análisis de documentos,
torbellino de ideas, JAD, etc.
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 31
CONCEPTO
• Esta etapa es un proceso de descripción del requerimiento.

RESULTADO
• Una forma de contrato entre usuarios y desarrolladores que define el
comportamiento funcional deseado del software (y otras propiedades como
performance, confiabilidad, etc.) sin mostrar cómo será alcanzada tal
funcionalidad
• ERS - IEEE Std. 830 (1998)

TÉCNICAS
• La técnica más utilizada en el momento es la de casos de uso, con otras
herramientas gráficas complementarias.
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 32
CONCEPTO
• Es el proceso que certifica que se ataca el problema correcto. Este
proceso final se nutre de los anteriores y realiza la integración y
validación final de lo obtenido en cada una de las etapas anteriores.

RESULTADO
• Modelo de requerimientos en línea con las expectativas de los
usuarios.
TÉCNICAS
• Revisiones de requerimientos, prototipos, generación de casos de
prueba, análisis de consistencia automático.
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 33
 Las actividades están
organizadas como un
proceso iterativo
alrededor de una
espiral, y la salida
es un documento de
requerimientos del
sistema.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 34

 Modelado
Especificación
de
Stakeholders
Requerimientos
Elicitación

Sistemas
existentes

Documentos,
reportes, Modelos de Requerimientos
manuales
Entregables
Análisis y Validación

Fuentes de
la Elicitación
UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 35
 SOMMERVILLE, Ian. Ingeniería de Software. 9na edición, Editorial Addison
Wesley, Madrid –2011
 BRAUDE, Eric. Ingeniería de software, una perspectiva orientada a objetos.
Alfaomega Grupo Editor, 2003
 LOUCOPOULOS, P., KARAKOSTAS, V. System Requeriments Engineering,
McGraw-Hill, London, 1995
 BRAMBLE, Paul. Artículo Introduction to Patterns for Writing Effective Use Cases
 Material de clase y documentos elaborados por Ing. Marcela Cattaneo, Ing. María
Irene Mac William, Ing. Iris Gastañaga.

UTN FRC – Análisis de Sistemas – 2K3 | Unidad 4: Ingeniería de requerimientos 36