Unidad i-requerimientos-del-software

Universidad Politécnica del Oeste “Mariscal Sucre”

INGENIERIA DE SOFTWARE II

Trayecto III. Trimestre I

© 2009 Rafael Matos.


¿PORQUÉ ESTAMOS ACA?

Ø

Ø

Ø

Queremos capacitarlos para participar en los grandes proyectos, tanto técnicos como
de gestión, de desarrollo de software que el país demanda.
Queremos DESPERTAR SU INTERES en el desarrollo de software como un
mecanismo eficiente para la administración de nuestro recurso más valioso: La
información.
Queremos que sean AGENTES DE CAMBIO para potenciar el crecimiento del
desarrollo de software en nuestro país.



¿QUÉ ES IMPORTANTE?
Ø

Es importante la participación en clase

Ø

Es importante la puntualidad

Ø

Es importante mantener nuestros celulares apagados o en modo de vibración, en
clase. -no contestarlos en el salón-

Ø

Comunicación: yrmatos@gmail.com - 0426-7054640



ORGANIZACIÓN DEL CURSO

Ø

Clases teórico-prácticas o consultas del Proyecto Práctico los Lunes de 7:00 a.m. a
9:10 a.m. y los Miércoles de 7:00 a.m. a 8:25 a.m.

Ø

Proyecto Práctico

Ø

Talleres prácticos relacionados con la materia con el objetivo de:

Ø

Entender el contexto del tema.

Ø

Debatir las ideas expuestas en el taller.

Ø

Cotejar lo que creemos saber.



EVALUACIÓN DEL CURSO
Ø

Tres Evaluaciones parciales teórico prácticos. (50%)

Ø

Un Taller práctico UML (10%).

Ø

Informe sobre calidad de Software. (10%)

Ø

Proyecto Práctico (30%)



CONTENIDO ANALÍTICO DEL CURSO

SABERES

ESTRATEGIAS

RECURSOS

EVALUACIÓN

Unidad 1: Requerimientos del Software
o ¿Qué son los requerimientos o Requisitos?
o Necesidades, objetivos y actores relacionados con los requerimientos
o Importancia de la Ingeniería de Requisitos en la práctica
o Levantamiento y Recolección de Requerimientos.

Talleres prácticos dirigidos, basados
en casos de estudios únicos e
integrales que permitan al participante
la aplicación directa y visible de los
conocimientos teóricos adquiridos
durante las actividades en aula de
encuentros.

o Técnicas más usadas: Método JAD y FPA

Unidad 2: Especificación de Requerimientos
o Textual, notación gráfica y lenguajes de representación (Lenguaje
Unificado de Modelado UML, Notación de Requerimientos de Usuario
URN).

Trabajos de investigación que
fortalezcan en el participante la
capacidad de interpretación de la
formación relacionada con la
investigación en ingeniería del
software.

Pizarra magnética
Marcadores

Evaluación continua

Material Educativo
Computarizado:
Material Instruccional,
Software Instruccional

Trabajo en grupo

Computador
Proyector Multimedia
Plataforma Tecnológica
Aula de encuentros

o Técnicas para escribir requerimientos de alta calidad. Estándares de
Documentación.
o Tipos de requerimientos: funcionales, no-funcionales,
atributos de calidad.

del dominio,


Ejercicios individuales
Participación
Casos Prácticos


CONTENIDO ANALÍTICO DEL CURSO (2)

SABERES

ESTRATEGIAS

RECURSOS

Unidad 3: Análisis de Requerimientos
o Inspección, validación, completitud, detección de conflictos
inconsistencias de requerimientos.
o Documentos de Requerimientos de Software: Creación,
Importancia.

e

usos e

o Métricas y herramientas para la ingeniería de requisitos.

Unidad 4: Modelado del Sistema
o Técnicas y métodos de modelado de sistemas.

Lecturas orientadas. El profesor
asesor elaborará un cuestionario con
preguntas que orienten al participante
en la identificación del conocimiento
relevante que debe adquirir hacia el
final de la lectura.

Exposiciones, mesas redondas y
foros de discusión acerca de las
consultas y lecturas recomendadas
realizadas por el participante.

o Modelado orientado a casos de uso, prototipo y técnicas de análisis.
o Modelado del negocio: Casos de uso del negocio, Especificación de
CUN, Actividades del negocio, Objetos del Negocio.


EVALUACIÓN


REFERENCIAS BIBLIOGRÁFICAS Y FUENTES DOCUMENTALES

Humphrey Watts S. (2001). Introducción al Proceso Software Personal. Addison Wesley. Meyer

JACOBSON Ivar. BOOCH Grady RUMBAUCH James (1999) The United Software Development Process. Rational Software Corporation. Addition
Wesley.
Larman Craig. (2003) UML y Patrones: Una introducción al análisis y diseño orientado a objetos y al proceso unificado. PEARSON – Prentice Hall.
Segunda Edición.
MEYER Bertrand, (1999).Construcción de Software Orientado a Objetos. Prentice Hall,

Pfleeger, Shari Lawrence (2002). Ingeniería de Software. Teoría y Práctica. Pearson Education, Buenos Aires.

Pressman, Roger S. (2005). Ingeniería del Software: Un enfoque práctico; Sexta edición. McGraw-Hill, Madrid.
Reifer, Donald J. (1993). SOFTWARE MANAGEMENT. IEEE Computer Society Press. Los Alamitos, CA
Sommerville, Ian (2006). Ingeniería de Software; Sexta edición. Pearson Educación, México.
Wang, Yingxu & King, Graham (2000). Software Engineering Processes. Principles and Applications. CRC Press LLC, N. W. Florida.
Wilson, Scott F. Analyzing Requirements and Defining Solution Architectures. Redmond: Microsoft Press, 1999.
Choque Ayala de Joaquin , Americo . Ingeniero de Sistemas www.unpmsm.org
Joaquin Deza de Choque, Victoria Rosa. Analista de Sistemas www.unpmsm.org
Apuntes de Clases



UN CASO HIPOTÉTICO
C:
IS1:

El sistema debe usarse en los 740 puntos ubicados en diferentes partes de la
geografía nacional.
¿Los 740 puntos de acceso en todo el país, van a tener conectividad?

C:

Si, todos van a tener banda ancha.

IS2:
C:

¿Qué tipo de arquitectura están esperando?
Nosotros hemos pensado en un sistema WEB

IS1:

¿Pero van a tener conectividad, las 24 horas?

C:
IS2:
C:

Bueno sabemos que en algunas partes es difícil y deben pensar en eso.
Puede ser una parte WEB y una no WEB.
!Por supuesto!. Una parte Cliente/Servidor y una WEB.
Sí, me parece bien, porque en realidad no hace falta que funcione todo si no
hay conexión; así que la parte cliente/servidor podría ser más pequeña que la
parte WEB.

…Tras varios minutos de discusión.
IS2:

Perdón, ¿porqué quieren un sistema WEB?



REFLEXIONES
Ø

Ø

Ø

La funcionalidad es sólo una parte de lo que el sistema puede hacer.
Para definir la arquitectura debemos CONOCER los requerimientos o atributos de
calidad, que nos hablan de las características específicas que el sistema tendrá.
Ejemplo: Flexibilidad, transportabilidad, usabilidad, etc.
Los atributos de calidad muchas veces se afectan entre sí. Por ejemplo portabilidad
vs. performance o flexibilidad vs. performance.

“Un software de calidad es aquel que posee una combinación deseada
de atributos”
IEEE Std. 1061



REALIDADES SOBRE LOS ATRIBUTOS DE CALIDAD DEL SOFTWARE
Ø

Ø

Ø

Ø

Ø

Ø

Por lo general están pobremente especificados, o no especificados (un
requerimiento que no es medible no es implementable).
En general no se analizan sus dependencias.
La importancia de los atributos varia con el dominio para el cual se construye el
software.
El ingeniero de software, generalmente no identifica las restricciones asociadas a
los atributos de calidad que identifica.
La arquitectura de un sistema es un medio para alcanzar los atributos de calidad
deseados, no el fin.
El atributo de mayor importancia suele ser la flexibilidad: Facilidad de cambios.



UNIDAD I. REQUERIMIENTOS DEL SOFTWARE
OBJETIVOS
Ø

Valorar la importancia de construir software de calidad

Ø

Caracterizar los requerimientos de software.

Ø

Identificar los problemas asociados a los requerimientos de software

Ø

Diferenciar entre el espacio del problema y el espacio de solución.

Ø

Reconocer la importancia del Modelado de Negocios y de la Ingeniería de
Requerimientos en el proceso de desarrollo de software de calidad.



¿QUÉ ES CALIDAD?

Propiedad o conjunto de propiedades inherentes a una cosa, que
permite apreciarla como igual, mejor o peor que las restantes de
su especie.
Diccionario de la Real Academia Española

Totalidad de las características de un producto o servicio que le

confieren su aptitud para satisfacer unas necesidades expresadas
o implícitas.
NORMA UNE 66-001-92 Traducción de ISO 8402 [AENOR, 1992]



ORÍGENES DE LA CALIDAD
Calidad Programada

Calidad Realizada

Calidad Necesaria



CALIDAD DE SOFTWARE

Grado con el que un sistema, componente o proceso cumple con:
–
–

Los requisitos [requerimientos] especificados.
Las necesidades o expectativas del cliente o usuario.
(IEEE Std. 610.1990) [IEEE, 1993] (Cursivas nuestras)

Concordancia del software producido con los requisitos funcionales y de
rendimiento explícitamente establecidos, con los estándares de desarrollo
documentados y con las características implícitas que se espera de todo
software desarrollado profesionalmente.
[Pressman, 1998]



FACTORES DE LA CALIDAD DE SOFTWARE (MARCO ISO 9126)

CARACTERISTICAS/
ATRIBUTOS*
FUNCIONALIDAD
§

Exactitud

§

Interoperabilidad

§

Seguridad



Cumplimiento de normas.

Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades
específicas. Las funciones son aquellas que satisfacen lo indicado o implica necesidades.

Idoneidad

§

DESCRIPCIÓN

FIABILIDAD


Recuperabilidad



Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo
condiciones establecidas durante un período de tiempo establecido.

Madurez



Tolerancia a fallos

USABILIDAD


Aprendizaje



Comprensión



Un conjuntos de atributos relacionados con el esfuerzo necesitado para el uso, y en la valoración individual de tal
uso, por un establecido o implicado conjunto de usuarios.

Operatividad

* Un atributo es una entidad la cual puede ser verificada o medida en el producto
software.



FACTORES DE LA CALIDAD DE SOFTWARE (MARCO ISO 9126)

CARACTERISTICAS/
ATRIBUTOS
EFICIENCIA


Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de
recursos necesitados bajo condiciones establecidas.

Comportamiento en el tiempo



DESCRIPCIÓN

Comportamiento de recursos

MANTENIBILIDAD


Estabilidad



Facilidad de cambio



Facilidad de análisis



Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema
software.

Facilidad de pruebas

PORTABILIDAD


Capacidad de instalación



Capacidad de reemplazamiento



Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una
plataforma a otra.

Adaptabilidad



Se estima que, del total de proyectos software grandes emprendidos, un
28% fracasan, un 46% caen en severas modificaciones que lo
Nosotros nos comprometemos a mejorar las metodologías o procesos
retrasan y un 26% son totalmente exitosos. Cuando un proyecto
de desarrollo, o crear nuevas y concientizarnos en su utilización
fracasa, rara vez es debido a fallas técnicas, la principal causa de fallos
adecuada.
y fracasos es la falta de aplicación de una buena metodología o proceso
de desarrollo.



¿QUÉ SON LOS REQUERIMIENTOS? (1)

“Una condición o capacidad que debe poseer el sistema, necesaria
para resolver un problema o alcanzar un objetivo”
Los requerimientos son el punto de acuerdo entre el
cliente
Una condiciónyoel ingenieroque software. satisfecha o poseida por un
capacidad de debe ser Este entendimiento

es necesario para sistema a fin de software que
sistema o un componente delpoder construir satisfacer un contrato,
satisfaga las necesidades de nuestro cliente.
estándar, especificación u otro documento formalmente impuesto.
(IEEE Standard Glossary of Engineering Terminology, 1990 )



¿QUÉ SON LOS REQUERIMIENTOS? (2)

“Serie de instrucciones abstractas de alto nivel de un servicio o de un
sistema, limitado a detallar en una especificación.”
(Abbott, 1986 )

Los que debe exhibir, cumplir o satisfacer un
“Propiedad requerimientos EXPRESAN lo que una aplicación osistema
sistema debe hacer para satisfacer las necesidades de
desarrollado o adaptado para resolver un problema particular”
(Sawyer y Kotonya, 2001)

sus clientes o usuarios. No intentab expresar cómo
lograr estas funciones
“Aspecto de un sistema o una descripción de aquello que el sistema
es capaz de hacer a fin de cumplir su propósito”

(Pfleeger, 1998)



CONTEXTO DE SISTEMA
El término “sistema” se refiere a:
Un sistema de software
- Software de sistema
-- Ejemplo: Sistemas operativos, compilador, interpretes, DBMS, entre otros.
- Software de desarrollo

-

- Ejemplo: Herramientas CASE, conductor de pruebas, entre otros.

-

- Aplicación de software

- Ejemplo: Aplicaciones WEB, SIG, SSD, vídeojuegos, entre otros.

-

Un sistema de hardware-software
- Ejemplo: Celulares, , controladores de procesos, relojes digitales, GPS, entre otros.

-

Un sistema de negocios
Se refiere al dominio de aplicación donde un sistema de software o H/S opera.

Sistema de
Negocios

Ejemplos:
-- El sistema contable de una empresa
-

Sistema H/S

- El vehículo donde opera el GPS.
-- El proceso industrial controlado por un controlador automático
-

Sistema de
Software



¿QUÉ DEFINEN LOS REQUERIMIENTOS?
Los requerimientos definen:
1. Lo que el sistema debe hacer
• Las funciones que debe ejecutar.
• Los datos que debe capturar y almacenar
• La información que debe producir

2. Las interacciones usuarios-sistema y sistema-sistema
• La interfaz gráfica usuario-sistema (GUI)

• La interfaz de la aplicación con otros sistemas.

3. Las restricciones bajo las cuales el sistema debe operar
• La plataforma de operación del sistema.
• La tecnología de información que debe utilizar el sistema.

4. Los atributos de calidad que el sistema debe satisfacer
• Estándar ISO 9126



CASO DE ESTUDIO
Un sistema de comercio electrónico para monedas antiguas.
ü

ü

ü

ü

ü

RAFMA, C.A. es una empresa especializada en la compra y venta de monedas antiguas
de todo el mundo, con más de 10 años en el mercado.
Durante su existencia, RAFMA ha conformado una de las más completas colecciones de
monedas antiguas a nivel mundial.
Para operar RAFMA envía catálogos impresos de su colección a clientes selectos en
todo el mundo, por los cuales deben cancelar $10.

Los pedidos se hacían por correo electrónico y las monedas eran despachadas por
correo courier a los clientes.
Como estrategia para fortalecer el negocio RAFMA decidió cambiar su modelo de
negocios por uno basado en comercio electrónico, para lo cual se contrató el desarrollo
de la aplicación web: oldcurrency.com



CASO DE ESTUDIO
Un sistema de comercio electrónico para monedas antiguas (oldcurrency.com).

Algunos requerimientos

ü

ü

Oldcurrency.com es una aplicación que permite la comercialización de
monedas antiguas de y desde cualquier parte del mundo.
La aplicación debe permitir:

•

Hojear el catálogo de monedas antiguas disponible.

•

Buscar una moneda de acuerdo a criterios específicos.

•

Visualizar una moneda específica.

•

Comprar una moneda.

•

Recibir información sobre la moneda de preferencia de los
usuarios.



CLASIFICACIÓN DE LOS REQUERIMIENTOS (1)
Explícitos:
Los requerimientos establecidos explícitamente se reflejan en el documento de
Especificación de Requerimientos del Sistema (ERS)
–
–

–

Requerimientos funcionales: Funciones a realizar por el software.
Requerimientos no funcionales: Requerimientos depermiten
Los estándares y las normas de desarrollo seguridad, rendimiento,
interfaz,que se consiga una alta calidad técnica. las opciones de solucionar el
etc. Describen restricciones que limitan

problema. Restricciones cuantitativas o precisión.
Pseudorequerimientos: Impuestos por el cliente que restringen la
implementación del sistema

Implícitos:
Los requerimientos implícitos no aparecen en la ERS, pero si no se cumplen con ellos la
calidad del software queda en entredicho.



CLASIFICACIÓN DE LOS REQUERIMIENTOS (2)
Según Wiegers, 2003

Requerimiento

Funcional

De
Negocios

Del Usuario

Del Sistema

De
Comportamiento

No Funcional

Restricción

Atributo de
Calidad

De Interfaz


Regla de
Negocio


REQUERIMIENTOS FUNCIONALES (1)
Requerimientos del Negocio

Requerimientos de Usuarios

Se expresan desde la perspectiva de la
empresa

ü

• Describen porque la empresa o el cliente desea
desarrollar el sistema.
• Expresan que objetivos, metas o necesidades la
empresa espera alcanzar con el uso del sistema.
ü

Se expresan desde la perspectiva del
usuario.

ü

• Describen las necesidades que los usuarios
tienen y las tareas que los usuarios deben
realizar con el sistema o aplicación.
• Expresan lo que el usuario será capaz de
hacer con el sistema.

Ejemplos:
• La empresa RAFMA, C.A. quiere abrir su
mercado a cualquier usuario interesado en la
adquisición de monedas antiguas.
• La aplicación oldcurrency.com deberá contribuir a
abrir el mercado e incrementar el volumen de
ventas anuales de monedas antiguas.

ü

Se modelan mediante casos de uso.

ü

Ejemplos:
• Hojear los catálogos de monedas antiguas.
• Visualizar un moneda.
• Comprar una moneda



REQUERIMIENTOS FUNCIONALES (2)
Requerimientos del Sistema
Son de alto nivel para productos que
tienen componentes H/S.
sistema H/S que contiene la aplicación.
Asumen que la el software es parte de un
sistema mayor.

ü

ü

ü

Requerimientos de Comportamiento
desarrollador.

ü

• Se denominan también requisitos funcionales
propiamente dicho.
• Describen los servicios que el sistema presta a
todos los usuarios directos.
• Expresan que hace el sistema bajo ciertos
eventos (su comportamiento).

Ejemplos:
• La aplicación oldcurrency.com deberá enviar
un mensaje electrónico cada vez que
RAFMA, C.A. disponga de una moneda
antigua de su interés.

ü

Ejemplos:
• El sistema oldcurrency.com, deberá permitirle al
cliente efectuar el pago de su pedido en línea,
usando cualquier tarjeta de crédito.
• El sistema deberá permitirle al usuario visualizar
la moneda o monedas seleccionadas por el
usuario de los contenidos en el catálogo de
monedas.



REQUERIMIENTOS NO FUNCIONALES (1)
Restricciones

Atributos de Calidad

Expresan las limitaciones que se le
imponen al desarrollo del sistema.
Describen aspectos tales como:

ü

ü

• Plataforma de desarrollo y operación.
• Uso de estándares, prácticas, métodos de
desarrollo.
• Tiempo máximo de desarrollo.
• Costo máximo de desarrollo.
ü

Ejemplos:
• oldcurrency.com deberá ser una aplicación
web que debe ser desarrollado con las
siguientes herramientas:

Expresan las propiedades de calidad
que el sistema debe satisfacer.

ü

•
•
•
•

ü

El rendimiento que la aplicación debe tener.
La confiabilidad que debe poseer.
La seguridad que debe proveer.
La utilidad que debe garantizar.

Ejemplos:
• oldcurrency.com, deberá tener una confiabilidad
mayor a 95%.
• oldcurrency.com deberá ser fácil de usar..

• Plataforma LAMP: Linux, Apache, MySql y
PHP.
• Tiempo máximo de desarrollo 6 meses.
• Costo máximo de desarrollo 50.000 Bs.



REQUERIMIENTOS NO FUNCIONALES (2)
Reglas de Negocio

De Interfaz

Expresan todas las regulaciones que la
aplicación deberá acatar, entre otras:

ü

• Regulaciones
gubernamentales
(Leyes,
decretos, providencias, etc.)
• Regulaciones de la empresa (Políticas,
normas, procedimientos, estrategias, etc.)
• Regulaciones propias de la aplicación
(Estándares, metodología que debe seguirse,
algoritmos o clases que deben usarse).
ü

Expresan las características de la
interacción del usuario con el sistema.
Se dividen en:

ü

ü

• Requerimientos de interfaz gráfica (GUI).
• Describen las propiedades generales de la
interfaz gráfica que permitirá la interacción
entre el usuario y el sistema.

• Requerimientos de interfaces con otros
sistemas.
• Describen con qué o cómo la aplicación
interactuará con otras aplicaciones de
software o sistemas de hardware.

Ejemplos:
• oldcurrency.com deberá desarrollarse usando
la metodología RUP.
• Un cliente puede descargar gratuitamente las
actualizaciones de un catálogo adquirido por
el, durante los dos primeros meses a partir de
la publicación de la actualización.

ü

Ejemplos:
• oldcurrency.com deberá ser implementada
usando una interfaz web.
• Oldcurrency.com, deberá interactuar con el
sistema de pagos online paypal.



DIFERENCIAS ENTRE LOS TIPOS DE REQUERIMIENTOS
Requerimientos Funcionales
ü

Requerimientos No Funcionales

Establecen:

ü

• Los objetivos de negocio respecto al sistema.
• Los servicios que el sistema debe proporcionarle
al sistema.
ü

ü

ü

Determinan la funcionalidad del sistema.
Determinan lo que el sistema deberá
hacer, es decir:
• Su comportamiento.
• Su interacción con los usuarios y su dominio de
aplicación (negocio)
• Sus respuestas a eventos.

ü

No
están
relacionados
con
la
funcionalidad o comportamiento del
sistema.
Restringen el diseño del sistema (la
solución)
Describen:
• Las restricciones que se le imponen al
sistema.
• Los atributos de calidad que el sistema debe
satisfacer.
• Las reglas de negocio que el sistema debe
respetar o implementar.
• Las interfaces con otros sistemas.



CARACTERÍSTICAS DE REQUERIMIENTOS DE ALTA CALIDAD
Los Requerimientos deben ser:
ü

Completos. Todo lo que el software tiene que hacer está recogido en el conjunto de
requerimientos, es decir, deben describir toda la funcionalidad que el sistema deberá
implementar.

ü

No ambiguos. Cada requerimiento debe tener una sola interpretación. debiendo poder
expresarse de una manera sencilla, clara y sin ambiguedades usando:
- Lenguaje natural (español).
- Lenguajes gráficos (UML)
- Lenguajes formales (Notación Z).

ü

Relevantes. Importancia para el sistema software a implementar.

ü

Traceables. Cada acción de diseño debe corresponderse con algún requerimiento del
cliente (resuelve un problema de este).

ü

Verificables. Preferiblemente deben expresarse de manera cuantitativa, usando métricas
que faciliten su verificación.



CARACTERÍSTICAS DE REQUERIMIENTOS DE ALTA CALIDAD

Los Requerimientos deben ser:
ü

Correctos. Cada requerimiento establecido debe representar algo requerido por el usuario
para el sistema que se construye y ser validado por este.

ü

Consistentes. Ningún requerimiento puede estar en conflicto con otro. Tipos de
inconsistencias:
ü

Términos conflictivos: Si dos términos usan en contextos diferentes para la misma
se
cosa.

ü

Características en conflicto: Si en dos partes de la ERS se pide que el producto muestre
comportamientos contradictorios.

ü

Inconsistencia temporal: Si dos partes de la ERS piden que el producto obedezca
restricciones de tiempo contradictorias.



EJEMPLOS DE REQUERIMIENTOS

1. Hasta 15 objetos se dibujarán dentro de la misma ventana. Si excede el número
se utilizará una ventana diferente.”
2. El sistema tendrá una interfaz de usuario sencilla de utilizar.
3. Los usuarios deben escribir su contraseña en un tiempo menor de 15 segundos

desde que escribieron su nombre de usuario.
4. El tiempo de respuesta para todos los comandos será menor de 0.1 segundos.
El tiempo de respuesta para el comando ‘DELETE’ será menor de 5 segundos.
5. El sistema tendrá un tiempo de respuesta aceptable.



¿PORQUÉ DETERMINAR REQUERIMIENTOS?
1. El software normalmente está integrado por muchos componentes. En la mayor
parte de los casos, es difícil para el ingeniero de software entender todos estos
componentes al mismo tiempo.
2. El costo de cambiar los requerimientos crece a medida que avanza el proyecto.
Reparar un requisito omitido o mal especificado se ha establecido, en forma
proporcional, como sigue:.
ü

$1 durante la fase de diseño.

ü

$2 durante la fase del diseño detallado.

ü

$3 durante la codificación.

ü

$5 durante la prueba de unidades.

ü

$20 durante la validación.

ü

$100 después que el sistema ha entrado en producción.



PROBLEMAS AL DETERMINAR REQUERIMIENTOS

1. El usuario o cliente no siempre sabe lo que quiere del sistema.
- Al inicio del proyecto, no sabe que esperar del sistema.
- Los requerimientos suelen surgir a medida que el usuario se familiariza con la
TIC
y el sistema de información.
2. El usuario no tiene tiempo para participar en el proyecto.
- Evita participar en el proyecto.

- No está consciente de la importancia de su participación.
- No ve el sistema como algo que le pertenece.
3. Problemas de Comunicación.
- El cliente o el usuario no entiende el lenguaje informático de los analistas.
- Los analista no entienden el lenguaje del dominio de la aplicación.



PROBLEMAS AL DETERMINAR REQUERIMIENTOS (2)
4. Los requerimientos pueden interpretarse de diferente manera.
- El analista entiende y especifica de manera diferente los requerimientos del
cliente.
- El diseñador interpreta de otra manera los requisitos especificados por el
5. analista.
Requerimientos mal definidos.
- No reflejan las necesidades reales de los usuarios del sistema.
- Son inconsistentes.

- Son incompletos.
- No son factibles.



SOLUCION A LOS PROBLEMAS DE LOS REQUERIMIENTOS
1. Entender la naturaleza del software.
- La naturaleza del software
requerimientos.
2. Entender el Espacio del Problema.

promueve

cambios

frecuentes

en

- Modelar el negocio antes de identificar y especificar requerimientos.
3. Utilizar un proceso de desarrollo bien definido y probado..

4. Utilizar prácticas reconocidas (mejores prácticas)
- Incorporar al cliente en el desarrollo del sistema (activamente).
- Modelar los requerimientos usando notaciones gráficas estandarizadas.
- Gestionar los requisitos.
5. Emplear personal especializado
- Analistas de negocios.
- Analistas de requerimientos.


los


ESPACIO DEL PROBLEMA – ESPACIO DE LA SOLUCION (1)
1. Los métodos tradicionales de desarrollo de software subestiman la importancia
del problema y su análisis, debido a que:
- Se centran en la solución y sus requisitos.
- No alinea la solución al negocio.
2. La separación del espacio del problema y el de la solución es crucial en toda
ingeniería.

3. La ingeniería de sistemas físicos establece una clara separación entre ambos
espacios (problema y solución)..
4. Las necesidades ocurren en el espacio del problema.
5. Los requerimientos tienen lugar en el espacio de la solución.



ESPACIO DEL PROBLEMA – ESPACIO DE LA SOLUCION (2)
ü Todo software ha de tener una
alcance funcional.

ES
PA
CI
O
DE
PR
O
BL
E
M
A

MUNDO
REAL

ü El diseñador debe establecer los
límites del problema.

ES RELEVANTE DEFINIR
CLARAMENTE EL DOMINIO

ü Lo que está dentro de los límites
(dominio)
forma
parte
del
problema
ü Lo que está fuera de los límites

no forma parte del problema .
ü El dominio del problema es la
parte del mundo, que para el fin
del software a construir, interesa
al diseñador.

DOMINIO = ESPACIO DEL PROBLEMA



INGENIERIA DE REQUERIMIENTOS

Modelado del Negocio (MN)

INGENIERÍA DE SOFTWARE

Ingeniería de Requerimientos (IR)

MN

Estudia el Espacio del
Problema en Ingeniería
de Software

Está
asociada
al
problema de los requerimientos y al Espacio
de la Solución.

IR



ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (1)
NECESIDADES Y REQUERIMIENTOS
• Los requerimientos funcionales de un sistema expresan necesidades de
información:
- ¿Qué información requieren los usuarios para ejecutar sus procesos de
negocio?.
- ¿Qué actividades de un proceso de negocio requieren ser automatizadas?

• Los requerimientos de una aplicación dependen de los procesos de negocio
que la aplicación soporta (cómo y porqué lo hace).
la

- Si los procesos de negocio no se conocen, la identificación de necesidades y
especificación de requerimientos no tienen fundamentación alguna.

• Una buena práctica de la IR es modelar los procesos de negocio antes de
definir sus requisitos.
- Se puede hacer mediante la elaboración de un pequeño modelo.



• El Modelado de Negocios (MN) es un proceso a través del cual se representa el
dominio de una aplicación.
• Es el mecanismo por el cual un negocio trata de generar ingresos y/o
beneficios. Es un resumen de cómo una organización planifica servir a sus
clientes.
• En aplicaciones empresariales el MN representa diferentes aspectos del
dominio de la aplicación.

- El dominio es denominado SISTEMA DE NEGOCIOS.
• El MN identifica y representa aspectos del sistema de negocios, tales como:
- Objetivos de la organización.
- Procesos de Negocio y sus actividades.
- Reglas de Negocio.
- Objetos del Negocio.
- Actores y su organización.
• El producto del MN son los MODELOS DE NEGOCIO.



• El Modelo de Negocios de una empresa, es una representación simplificada de
la lógica de negocio que describe lo que un negocio ofrece a sus clientes,
cómo llega a ellos, y cómo se relaciona con ellos
• Un Modelo de Negocios es un documento compuesto por un conjunto de submodelos.
- Cada sub-modelo describe uno o más elementos organizacionales.

Modelo de

El Problema

Negocios

Sub-modelos

Objetivos

Procesos
de
Negocio

Objetos de
Negocio

Actores

Requerimientos Funcionales

Reglas de
Negocio

Eventos

Requerimientos No Funcionales

La Solución



• En la fase de Ingeniería de Requerimientos, el Modelo de Negocios es
usado para:
- Entender el proceso de negocio actual y establecer sus problemas de
información.
- Descubrir las necesidades que los usuarios tienen.
- Se analiza cada proceso para determinar que información requiere.

- Facilitar la definición y especificación de requerimientos funcionales.
que se

- Los diagramas de actividades permiten identificar aquellas acciones
desean automatizar.

- Caracterizar el nuevo proceso de negocios y su flujo de trabajo.



ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (1)
• La Ingeniería de Requerimientos (IR) es una sub-disciplina de la Ingeniería
de Software, encargada del estudio de los requerimientos para
automatizar sistemas.
• La IR estudia:
- Los problemas de los requerimientos.
- Las soluciones que pueden contribuir a resolver estos problemas.

• La IR se encarga de establecer:
-

Principios

-

Modelos

-

Métodos

-

Mejores prácticas

-

Técnicas y

Herramientas automatizadas que contribuyan a mejorar la definición y
especificación de los requerimientos.

-




• La aplicación de la IR al desarrollo de un sistema conduce a:
- Encontrar y definir las necesidades que tienen los interesados de la
aplicación.

- Transformar la definición de necesidades en una descripción
completa y ´ precisa de requerimientos denominada: Especificación de
Requerimientos de Software (ERS).
- Lograr un entendimiento común, entre usuarios y desarrolladores, de los
requerimientos que debe satisfacer el sistema.




tiene

El Proceso: ¿Cómo hacerlo?

tres

elementos

El Equipo: ¿Quiénes lo hacen?

El Producto: ¿Qué se hace?

La Ingeniería de Requerimientos
fundamentales que son:



EL PRODUCTO

¿Qué produce la Ingeniería de Requerimientos?
• Su producto principal es el DOCUMENTO DE REQUERIMIENTOS.
- Contiene el conjunto de requerimientos que debe satisfacer el
sistema
• El Documento de Requerimientos (DR) es un documento manual o

electrónico que describe y comunica de manera sencilla y comprensible
los requerimientos para:
- Los Clientes, usuarios y gerentes.
- Desarrolladores del sistema



EL PRODUCTO

• El DOCUMENTO DE REQUERIMIENTOS debe describir:
- Los servicios y funciones que debe ofrecer el sistema.
- Las restricciones bajo las cuales deberá operar el sistema.
- Las propiedades o atributos de calidad que deberá caracterizar al
sistema.

• Normalmente el documento se divide en dos partes:
- Documento de Definición de Requerimientos (DDR)
- Documento de Especificación de Requerimientos (DER)



EL PRODUCTO

Documento de Definición de
Requerimientos (DDR)
• Describe los requerimientos de alto •
nivel desde la perspectiva de los

clientes y/o usuarios.
•
• Está orientado a los clientes y/o
•
usuarios.
•
• Los requerimientos se describen en
lenguaje natural (español)

Documento de Especificación de
Requerimientos (DDR)
Describe
detalladamente
los
requerimientos contenidos en el DDR.
Está orientado a los desarrolladores.
Tiene un carácter técnico.
Los requerimientos se describen en un
lenguaje o notación técnica.
- Ejemplo: UML, SADT, ER



El PRODUCTO

Existen varios estándares y modelos (plantillas o patrones) que
ayudan a elaborar el DR.
• El estándar IEEE 830-1993
-

Propuesto por el Institute of Electrical and Electronics

Engineers
(IEEE)
-

Agrupa los documentos DDR y DER en un solo documento.

-

Es también un estándar ANSI

• La plantilla Volere.
- Permite documentar cada requerimiento mediante un formato
especial.



El Producto
El estándar IEEE-830-1993
I.

Introduccción

2. Funciones del producto

1. Propósito

3. Características del usuario

2. Alcance

4. Restricciones

3.
Definiciones,
abreviaturas.

acrónimos

4. Referencias

5. Suposiciones y dependencias

y

6. Distribución de requisitos

III.

5. Estructura del documento

II.

Requerimientos específicos
1. Requerimientos de interfaz

Descripción general

2. Clases/Objetos

1. Perspectivas del producto

3. Requisitos de desempeño

- Interfaces del sistema

4. Restricciones de diseño

- Interfaces del usuario

5. Atributos de calidad del sistema

- Interfaces de H/S

6. Otros requisitos

- Interfaces de comunicación
- Restricciones de memoria
- Operaciones

IV.

Apéndices

V.

Indice

- Requisitos de adaptación del sitio.



EL PRODUCTO

Identificador del
Tipo de Requisito:
Caso de Uso:
Requisito:
45
Funcional
4.2.1
Descripción
:

Calcular el promedio diario, mensual y anual ingresos por concepto de venta de monedas
antíguas de cada una de las casa sucursales de RAFMA en los cinco continentes.
Justificación del
requisito

Es necesario elaborar los reportes de ingresos diarios, mensuales y anuales de venta de
monedas antíguas de cada sucursal.
Fuente (que interesado lo propone)
Unidad en la que se origina:
Pedro Pérez
Departamento de Ventas
Criterios de Validación

Los valores obtenidos se compararan con los obtenidos en años pasados para determinar si
hay inconsistencias.
Grado de satisfacción del usuario:
Grado de insatisfacción del interesado:
3
5
Dependencias (qué requisitos dependen Conflictos (qué requisitos son
de este):
incompatibles con este)
35, 56

Documentos de Soporte:
Historico de cambios:
Manual de Ventas
15/07/2010
Proyecto:

Analista: Rafael Matos
oldcurrency.com

Plantilla Volere



La Ingeniería de Requerimientos consta de cinco grandes procesos:
Capturan, organizan,
filtran y documentan
los requisitos
Obtención
de
Requisitos

Análisis
de
Requisitos

Especificación
de
Requisitos

Procesos Técnicos

Validación de Requisitos

Procesos de Gestión
Gestión de Requisitos
Controlan y apoyan a
los procesos técnicos



EL PROCESO DE OBTENCIÓN DE REQUERIMIENTOS

‒ Denominada también Captura de Requerimientos
‒ Consiste en la búsqueda y recolección de requerimientos
‒ Sus actividades principales son:
• Establecimiento de objetivos y descripción del problema.

• Identificación de actores o interesados (stakeholders). Entidades externas que
interactúan con el sistema
• Adquisición de conocimientos sobre el dominio de la aplicación.
• Organización del conocimiento
• Recolección de los requerimientos que tienen los interesados, es decir, Identificación de
escenarios. Descripción concreta, enfocada e informal de una sola característica del
sistema desde el punto de vista de un solo actor.




ACTORES
1. Dueños del Sistema. Para cualquier sistema de información grande o pequeño
habrá 1 o mas dueños del sistema, los dueños del sistema tienden a estar
interesados en: ¿cuánto costara el sistema?, ¿cuál será el costo/beneficio?,
¿cuándo recuperaran la inversión y cómo la recuperaran?, etc.… Este grupo es
quien paga por el sistema.

2. Supervisores del contrato. Sugieren hitos de control y cronogramas que
disciplinan el desarrollo del sistema.
3. Clientes y usuarios. Deben comprender y trasmitir adecuadamente los
requerimientos, para del sistema. Existen internos y externos.
4. Los Gerentes de Negocios, para calibrar el impacto de construir y utilizar el
sistema.




ACTORES
4. Los Diseñadores. Usarán los requerimientos como base del desarrollo.
5. Los verificadores. Encargados de las sesiones de prueba destinadas a asegurar
Un agente de cambio se puede definir como
que el sistema cumple los requerimientos.

alguien que sirve de catalizador para el cambio,
cambio coopera con los
6. Analistasdesarrolla un plan para especialista yque estudia los problemas y
de Sistemas. Es un el
demás una facilitar el cambio.
necesidades de paraorganización para determinar como las personas, datos,

procesos y la tecnología de la información pueden en conjunto mejorar un
negocio.
El analista desempeña diversos roles, en ocasiones varios de ellos al mismo tiempo.
Los tres principales roles del analista de sistemas son el de consultor, exporto en soporte
técnico y agente de cambio.




ADMINISTRACION DE LA CAPTURA DE REQUERIMIENTOS
1.

FUENTES
a.

Revisión de Documentos.

b.

Personas con puntos de vista necesarios.

2.

MÉTODOS Y TÉCNICAS
a.

Cuestionarios

b.

Entrevistas

c.

Talleres

d.

Prototipos

h. Reutilización de requisitos

e.

JAD

i.

Uso de Modelo de Negocios

f.

FPA

j.

Ingeniería de Reverso

g. Observación directa

k. Torbellino de ideas
l.

Análisis de documentos




ADMINISTRACION DE LA CAPTURA DE REQUERIMIENTOS - FUENTES

Revisión de Documentos
‒

Es imprescindible cuando:
•
•

‒

El sistema se instalará en infraestructuras existentes.
Suplemento de funcionalidad ya disponible.

Documentación a analizar:

•

Sobre las prácticas existentes de los usuarios.

•

Sobre procedimientos de soporte.

•

Sobre componentes técnicos.

•

Sobre el modelo lógico

•

Sobre los modelos de procesos y datos

•

Sobre requisitos existente




ADMINISTRACION DE LA CAPTURA DE REQUERIMIENTOS - FUENTES

Personas.
Identificar personas con puntos de vista precisos para representar el
conjunto de los requerimientos:

Es 1. Direccióncontar con más de una persona por cada punto de vista.
importante General

2.
3.
4.
5.
6.
7.

Usuarios finales y dirección
Clientes
Proveedores
El equipo operativo
El equipo de mantenimiento
Asesoría jurídica u otros expertos.



EL PROCESO DE ANALISIS DE REQUERIMIENTOS

‒

Consiste en analizar los requerimientos recolectados durante el proceso de
Obtención con el fin de:
• Determinar y resolver posibles conflictos entre requisitos.
• Refinar los requisitos obtenidos, establecer prioridades.
• Establecer acuerdos entre los usuarios y desarrolladores sobre los requerimientos
que se pueden implementar.

‒

Las Actividades principales de esta etapa son:
• Refinamiento y clasificación de requerimientos

§

Verificar necesidad, consistencia, completitud y factibilidad.

• Negociación de requerimientos

§

Discutir, priorizar y acordar requisitos.

• Modelar requisitos

§

Elaborar los modelos funcional, estructural y dinámico de la aplicación.

• Construir un prototipo de la interfaz gráfica



EL PROCESO DE ANALISIS DE REQUERIMIENTOS
TECNICAS UTILIZADAS

‒
‒

Análisis de los procesos de negocio.
Análisis Orientado a Objetos.
•
•
•
•

‒

Modelado de funciones mediante Diagramas de Casos de Uso.
Modelado de Flujo de Trabajo a través de Diagramas de Actividad
Modelado de la Estructura de la Aplicación usando Diagramas de Clase

Modelado de la Dinámica de la Aplicación mediante Diagramas de Secuencia.

Análisis Estructurado de Sistemas.
• Modelado de procesos mediante Diagramas de Flujo de Datos (DFD)
• Modelado de Transiciones empleando Diagramas de Estado
• Modelado de Entidades por medio de Diagramas Entidad Relación (DER)

•
•

Prototipos.
Técnicas de Negociación.



EL PROCESO DE ANALISIS DE ESPECIFICACIÓN DE REQUERIMIENTOS

‒
‒
‒

Consiste en la documentación de los requerimientos.
Está relacionado con la estructura, calidad y verificabilidad del Documento de
Requisitos (El producto)
Premisa:
• “La documentación de requerimientos es la presentación fundamental para el

manejo exitoso de estos” [Kotonya y Sommerville, 2000]

‒

Actividades.
• Selección del estándar de documentación
• Documentación de los requerimientos del cliente.
• Documentación de los requerimientos del desarrollador



EL PROCESO DE ANALISIS DE ESPECIFICACIÓN DE REQUERIMIENTOS
TECNICAS UTILIZADAS

‒

Uso de estándares de documentación de requisitos
•
•
•
•

‒

IEEE 830-1998
IEEE P1233/D3
ISO/IEC 12119-1994
IEEE 1362-1998

Indicadores de Calidad

• Modelo de Calidad del Software (Marco ISO 9126)

‒

Lenguajes y Notaciones
• Lenguajes de Modelado Gráfico
§
Lenguaje Orientado a Objetos (UML)
§

Lenguajes Estructurados: DFD, ER.

§

Lenguajes Dinámicos: Redes de Petri, Diagramas de estado



EL PROCESO DE VALIDACIÓN DE REQUERIMIENTOS

‒

‒

Consiste en examinar los productos elaborados durante la Ingeniería de
Requerimientos para determinar si son descripciones válidas y aceptables de
los requisitos del sistema que se desea construir.
Productos de la IR que se validan en este proceso.
• Lista de requerimientos recolectados
• Modelos de requerimientos

§

Modelo funcional, estructural y dinámico

• Prototipos
• Documentos de Requisitos
•

Documento de Definición de Requerimientos

•

Documento de Especificación de Requerimientos




‒

Los productos de la IR se validan para determinar si sus requisitos son:
• Correctos
§
Satisfacen las necesidades reales de los usuarios
• Completos
§

Incluyen todos los requisitos que los usuarios necesitan

• Consistentes
§
No hay conflicto entre los requerimientos
• Cumplen con los estándares establecidos
• Precisos
§
No hay requerimientos ambiguos
• Libres de errores




Actividades y Técnicas utilizadas
• Revisión Técnica
§
§

Inspección de modelos
Inspección de documentos

• Validación de Prototipos
§

Evaluación de prototipos de interfaces gráficas

• Definición de criterios de aceptación
§

Establecer los criterios que los usuarios emplearán para aceptar el sistema



EL PROCESO DE GESTIÓN DE REQUERIMIENTOS

‒

Esta relacionado con
• La planificación de las actividades de IR
• El manejo de los cambios
§

Control de cambios de requerimientos

• El manejo de las relaciones entre requerimientos
§

Establecer los criterios que los usuarios emplearán para aceptar el sistema

• El manejo de las dependencias entre el documento de requerimientos y otros
documentos producidos en el desarrollo del sistema
§

Seguimiento o trazabilidad de requerimientos



EL PROCESO DE GESTIÓN DE REQUERIMIENTOS

‒

Actividades y Técnicas utilizadas:
• Planificación y Control de Proyectos
• Gestión de Cambios
• Gestión de Almacenamiento de Requerimientos
§

Identificación de Requerimientos

§

Uso de procesadores de texto

§

Uso de bases de datos de requerimientos

• Rastreo o trazabilidad de Requisitos



EL EQUIPO DE REQUERIMIENTOS

¿Quiénes participan en el proceso de Ingeniería de Requerimientos?
• En la elaboración del Documento de Requerimientos participan un
conjunto de interesados o actores.
• Para garantizar el éxito del proceso IR, el conjunto de actores debe
estar debidamente organizado y estructurado.
• A este conjunto organizado de actores se le conoce como Equipo de

Requerimientos



EL EQUIPO DE REQUERIMIENTOS

Responsabilidades y Funciones del Equipo de Requerimientos
• Seleccionar el modelo de procesos apropiados para ejecutar el
proceso de IR.
• Adaptar el modelo de proceso de la IR a las características del
proyecto y la empresa.
• Planificar el proceso de requerimientos.

• Elaborar el Documento de Requerimientos siguiendo el proceso.
• Mantener actualizado el Documento de Requerimientos.
• Hacerle seguimiento a los requerimientos (mantener la trazabilidad)
• Proporcionar soporte técnico al equipo de desarrollo del sistema en
relación a los requermientos.


Unidad i-requerimientos-del-software

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

Similar to Unidad i-requerimientos-del-software

Similar to Unidad i-requerimientos-del-software (20)

Unidad i-requerimientos-del-software