Trabajo con estudiantes

1. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 11
Universidad Tecnológica de SantiagoUniversidad Tecnológica de Santiago
Recinto DajabónRecinto Dajabón
Cátedra de Análisis de SistemasCátedra de Análisis de Sistemas
Especificación de losEspecificación de los
Requerimientos de los UsuariosRequerimientos de los Usuarios

2. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 22
1)Loqueelusuario
necesita
3)Loqueletransmitióal
profesional
2)Loqueelusuario creecree
necesitar
El Problema de los Requerimientos

3. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 33
4)Loqueelprofesional
entendió
6)Loquealfinalresultó
5)Loqueseentregóal
principio
El Problema de los Requerimientos

4. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 44
Introducción
Laefectividadyflexibilidaddeunsistemaestá
extrechamenterelacionadaalacorrecta
comprensióndelas necesidades delos clientes
y/ousuarios delsistema, hayuncomponenteclaveentodo
procesodedesarrollo, quejuegaunpapelcentral, llamado....
ESPECIFICACIÓN DEREQUERIMIENTOS

5. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 55
¿ Qué es un Requerimiento?
(Definición IEEE-Std-610 - 1990)
Condición o capacidad que necesita el usuario para
resolverun problema o alcanzarun objetivo.
Condición o capacidad que debe satisfacero poseerun
sistema o un componente de un sistema para satisfacer
un contrato, un standard, una especificación u otro
documento formalmente impuesto.
Representación documentada de una condición o
capacidad como las expresadas anteriormente.

6. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 66
Requerimientos: Categorías
En general, caen en dos grandes categorías:
orientado al mercado
específico para un cliente

7. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 77
Requerimientos
Orientados al Mercado
Bocetados e informales
Técnicas más de manufactura que de Ingeniería de
Software
Especificación en forma de presentación comercial
“Cliente” no fácilmente identificable
Se basan en Consultores para aspectos deseables
Enfoque poco estructurado.

8. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 88
Requerimientos
Específicos para un cliente
Voluminosos y más “formales”
Uso de técnicas de Ingeniería de Software
Largas especificaciones
Uso del conocimiento del dominio
Proyectos basados en personal propio
Método estructurado siguiendo un enfoque
particular

9. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 99
Requerimientos:
Una Perspectiva Organizacional
La contribución de los SIa las organizaciones
 Automatizarreduciendo costos de proceso
 Informara los tomadores de decisiones
 Transformarla organización
Prerequisitos
 Visión del negocio y la organización
 Alineación de los SIcon la estrategia corporativa
El desarrollo de los SItiene que vercon:
 Necesidades de los involucrados
 Requerimientos del usuario y estrategia de negocios

10. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1010
De la automatización de la
rutina a los procesos críticos
La especificación de requerimientos debe atendera:
 mejorarla gestión del cambio
 integrarvisiones dentro de la empresa
 vincularla estrategia empresaria con los SI
ERcomo camino para gerenciarel cambio:
 comprensión conceptual del status actual
 definición del cambio
 implementación del cambio
 integración de esta nueva implementación

11. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1111
Requerimientos:
Una Perspectiva del Software
Los errores en la definición de requerimientos resulta
en un mantenimiento costo de los sistemas de
software.
Surge la Ingeniería de Requerimientos como un sub-
campo de la Ingeniería de Software

12. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1212
Importancia de los requerimientos
Premisa
Hacerun mejortrabajo definiendo y especificando software no
sólo vale la pena sino que tambien es posible y ventajoso en
costo
Soporte:
Cuanto más tarde en el ciclo de vida se detecta un error, más
cuesta repararlo
Muchos errores permanecen latentes y no son detectados
hasta bastante después de la etapa en que se cometieron
Los errores de requerimientos son comúnmente: hechos,
incorrectos, omisiones, inconsistencias y ambigüedades
Los errores en los requerimientos pueden detectarse

13. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1313
errores
corregibles
errores no
corregibles
funciones
correctas
errores
ocultos
especificación
correcta
especificación
incorrecta
diseño
correcto
diseño basado en
especificación
incorrecta
diseño
incorrecto
Especificación de
Requerimientos
Diseño
Implementación
Testing
PROBLEMA REAL
programas basados
en diseño
incorrecto
programas
correctos
errores de
programación
programas basados
especificación
incorrecta
Diseño correcto
Errores
corregibles
Catarata de Errores de Mizuno

14. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1414
Impacto de los errores en la etapa de
requerimientos
El software resultante puede no satisfacera los
usuarios
Las interpretaciones múltiples de los requerimientos
pueden causardesacuerdos entre clientes y
desarrolladores
Es imposible que a través del testeo el software
satisfaga sus requerimientos
Puede gastarse tiempo y dinero construyendo el
sistema erróneo

15. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1515
Evolución de Requerimientos
ComprensiónComprensión
inicial delinicial del
problemaproblema
ComprensiónComprensión
inicial delinicial del
problemaproblema
Cambios en laCambios en la
comprensión delcomprensión del
problemaproblema
Cambios en laCambios en la
comprensión delcomprensión del
problemaproblema
RequerimientosRequerimientos
inicialesiniciales
RequerimientosRequerimientos
inicialesiniciales
RequerimientosRequerimientos
CambiadosCambiados
RequerimientosRequerimientos
CambiadosCambiados
TiempoTiempo

16. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1616
Clases de Requerimientos
Requerimientos Durables: son relativamente estables,
derivan de las actividades centrales del negocio, los
cuales se relacionan directamente con el dominio del
sistema.
Requerimientos Volátiles: son aquellos que tienen
probabilidad de cambiardurante el desarrollo del
sistema o después que el sistema se haya puesto en
producción.

17. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1717
Clasificación de Requerimientos
Volátiles
Mutables: los requerimientos cambian debido al entorno en el
cual la organización opera.
Emergentes: surgen con la comprensión de los clientes del
sistema, durante su desarrollo. El diseño puede relevarnuevos
requerimientos.
Consecuentes: resultan de la introducción del sistema de
computación, cambiando los procesos del negocio y abriendo
nuevas formas de trabajo que generan nuevos requerimientos
De Compatibilidad: dependen de un sistema o proceso en
particulardentro del negocio, si cambian, los requerimientos
relacionados deberán cambiar.

18. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1818
Especificación de Requerimientos
La documentación de Requerimientos para la
construcción de Software es la actividad que
tradicionalmente se ha llamado Especificación de
Requerimientos.
La Especificación de Requerimientos representa
ambos: un modelo de lo que se necesita y una
definición del problema bajo consideración.

19. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 1919
Especificación de Requerimientos
Focaliza el proceso comunicacional en la comprensión
a cerca del dominio, el negocio y el sistema
propuesto.
Puede serparte de un arreglo contractual.
Puede usarse para la evaluación del producto final, y
tenerun rol crucial en las pruebas de aceptación del
sistema.
Razones para esforzarse en su desarrollo....

20. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2020
Especificación de Requerimientos
Una nueva visión para su desarrollo...
Especificación
de
Requerimientos
Requerimientos
Funcionales
Requerimientos
Empresariales
Requerimientos
No Funcionales
Evaluación

21. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2121
Requerimientos Funcionales
Relacionados con la descripción del comportamiento
fundamental de los componentes del software.
Las funciones son especificadas en términos de
entradas, procesos y salidas.
Una vista dinámica podría consideraraspectos como el
control, el tiempo de las funciones (de comienzo a
fin) y su comportamiento en situaciones
excepcionales.

22. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2222
Requerimientos No Funcionales
Juegan un papel crucial en el diseño y desarrollo
del sistema de información.
Pueden definirse como consideraciones o
restricciones asociadas a un servicio del sistema.
Suele llamarse también requerimientos de calidad
o no comportamentales en contraste con los
comportamentales.
Pueden ser tan críticos con los funcionales.

23. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2323
Dificultades asociadas a los
Requerimientos No Funcionales
No hay reglas ni lineamientos para determinarcuando
se obtuvo una solución óptima.
Tiene buenas y malas soluciones, no soluciones
correctas e incorrectas
Problemas relacionados con requerimientos no
funcionales pueden sersíntomas de problemas
mayores.
Hay dos atributos que deben poseer: deben ser
objetivos y testeables.

24. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2424
Requerimientos No Funcionales: Tipos
Performance
requirements
Space
requirements
Usability
requirements
Efficiency
requirements
Reliability
requirements
Portability
requirements
Interoperability
requirements
Ethical
requirements
Legislative
requirements
Implementation
requirements
Standards
requirements
Delivery
requirements
Safety
requirements
Privacy
requirements
Product
requirements
Organizational
requirements
External
requirements
Non-functional
requirements
Requerimientos
No Funcionales
Requerimientos
del Producto
Requerimientos
Organizacionales
Requerimientos
Externos
Requerimientos
Legales
Requerimientos
de Estándares
Requerimientos
de Entrega
Requerimientos
de Entrega
Requerimientos
de Usabilidad
Requerimientos
de Seguridad
Requerimientos
de Privacidad
Requerimientos
De Espacio
Requerimientos
De Performance
Requerimientos
Eticos
Requerimientos
de Portabilidad
Requerimientos
Interoperatibidad
Requerimientos
de Confiabilidad
Requerimientos
de Eficiencia

25. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2525
Ingeniería de Requerimientos
“Es el proceso sistemático de desarrollar
requerimientos a través de un proceso
cooperativo e iterativo de analizar el
problema, documentar las observaciones
resultantes en una variedad de formatos de
representación y chequear la precisión de la
comprensión obtenida”

26. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2626
Características del proceso
Representación, aspecto social y aspecto cognitivo
De una formulación informal a una especificación
formal
Proceso no determinístico y no lineal
Elicitar, especificar y validar requerimientos, no son
actividades predominantemente técnicas
Típica actividad de resolución de problemas.

27. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2727
Aspectos principales de la Ingeniería de
Requerimientos
Comprenderel problema
Describirel problema
Acordarsobre la naturaleza del
problema

28. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2828
Validación
Especificación
Elicitación
RASTREABILIDAD HACIA DELANTE Y HACIA ATRASRASTREABILIDAD HACIA DELANTE Y HACIA ATRAS
Propuesta de la Ingeniería de
Requerimientos

29. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 2929
ElicitaciónElicitación
Especifica
ción
Especifica
ción
ValidaciónValidación
UsuarioUsuario
Dominio
del
Problema
Dominio
del
Problema
Feedback del usuario
Requerimientos
del usuario
Modelos
a
validar por
el usuario
Especificación
de
Requerimientos
Modelos de
Requerimientos
Conocimiento
Necesidad de
más conocimiento
Resultados de
la validación
Conocimiento
del dominio
Conocimiento
del dominio
Interacción entre Procesos de la
Ingeniería de Requerimientos

30. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3030
Productos entregables
Modelos ...
Del dominio del problema
De los requerimientos funcionales
De los requerimientos no funcionales

31. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3131
Elicitación: Propósito
Ganarconocimiento relevante del
problema, para produciruna
especificación rigurosa del software
necesario para resolverel problema.
Al final del proceso el analista podría
ser un “experto” en el dominio del
problema.

32. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3232
Elicitación: Entradas
Fuentes del conocimiento del dominio:
• Expertos del dominio
• Literatura sobre el dominio
• Software existente en el dominio
• Software similar en otros dominios
• Standards nacionales e internacionales
• Otros “involucrados”

33. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3333
Elicitación: Actividades
Tareas a encarar por el analista:
• Identificar fuentes de conocimiento
• Adquirir el conocimiento
• Decidir sobre la relevancia de un
conocimiento
• Comprender la significación del
conocimiento y su impacto

34. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3434
Elicitación: Actividades
Técnicas más usadas :
Entrevistas
Torbellino de Ideas
Escenarios
Reuso de conocimiento
Análisis de Documentación
Observación
Análisis de Objetivo / Meta

35. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3535
Elicitación: Productos
Es un proceso de creación de modelos
El analista comienza con modelos
mentales con conocimiento dependiente
del domino
Al avanzar, los modelos son más
orientados al software
No se produce ningún modelo formal
Sucesión de modelos mentales del
dominio del problema

36. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3636
Especificación: Propósito
Acuerdo usuarios-desarrolladores
sobre el problema a resolver
Pauta para el desarrollo de un sistema
de software

37. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3737
Especificación: Entradas
Conocimiento sobre el dominio
del problema
Lo provee el proceso de elicitación

38. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3838
Especificación: Actividades
Análisis y asimilación del
conocimiento de los requerimientos
Síntesis y organización del
conocimiento en un modelo de
requerimientos coherente y lógico

39. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 3939
Especificación: Productos
Se producen una variedad de modelos:
modelos orientados al usuario, que
especifican comportamiento,
características no funcionales, etc.
modelos orientados al desarrollador,
que especifican propiedades
funcionales y no funcionales del
software y restricciones

40. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4040
El Problema...
A partirdel Modelo de requerimientos
se puede establecerque no contiene
definiciones contradictorias, pero...
Un modelo correcto de requerimientos
no es necesariamente el modelo de
requerimientos correcto.
No existen los REQUERIMIENTOS de los
requerimientos
El peligro está en hacerel esfuerzo de
analizarel problema erróneo.

41. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4141
Causas de los errores
Dificultades en la elicitación de los
requerimientos del usuario.
Dificultad en establecerun esquema de
comprensión común entre analista y
usuario.

42. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4242
Validación: Propósito
Certifica la consistencia del
modelo (de requerimientos) con
las intensiones de clientes y usuarios
Ayuda a hacerel artefacto correcto
La necesidad aparece cuando se
modifica el modelo actual
Se aplica también a los modelos
intermedios

43. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4343
Validación: Entradas
Todo modelo está sujeto a validación,
porlo tanto cada modelo es input
El conocimiento sobre el dominio del
problema debe servalidado
Algunas partes del modelo formal

44. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4444
Validación: Actividades
Interacción entre analistas, clientes del
sistema y usuarios en el dominio del
problema.
Similara formularuna nueva teoría
científica y posteriormente testearla
Caracterizada por:
 preparación del experimento
 ejecución del experimento y
análisis de los resultados

45. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4545
Validación: Técnicas
Prototipos
Animación
Enfoque de Sistemas
Expertos

46. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4646
Prototipos
Proceso de construcción y evaluación de modelos de
trabajo de un sistema para aprenderde ciertos aspectos
del sistema requerido y/o su solución potencial.
Técnica común de la ingeniería.
En Ingeniería de Software: es el paradigma de producir
software tan rápido y económicamente como sea posible
en alguna etapa del desarrollo.
Un modelo es considerado un prototipo si:
• es posible obtenerinformación sobre el comportamiento
y performance del sistema que se “prototipea”
• construirel prototipo debería serun proceso rápido

47. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4747
Tipos de prototipos
Prototipo de comportamiento, es un modelo en caja
negra del sistema que muestra como responde a los
estímulos. En un modelo funcional
Prototipo estructural, muestra como el sistema
“prototipeado” cumplirá con este comportamiento.
Es un modelo de caja de cristal que muestra la
estructura interna y la organización del sistema.
Modela los requerimientos no funcionales

48. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4848
Animación
Visión gráfica múltiple de un proceso en acción.
Se representan gráficamente los principales objetos y se
interactúa con ellos (tiempo real)
En el contexto de desarrollo de IS es un enfoque que
provee un ambiente visual para validary ejecutar
simbólicamente especificaciones conceptuales (en
términos de modelos de entidades, reglas y procesos) de
un IS.
“En el contexto de especificaciones conceptuales, visualización involucra
la animación del comportamiento de un sistema y una interfase visual que
refleja los resultados de eventos bajo la componente gráfica -cuando es
apropiado la textual- de la especificación”

49. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 4949
Animación: Características
Ventaja sobre prototipos: no impone
decisiones de diseño muy tempranas
Provee una indicación de la dinámica del
sistema mediante una recorrida
Permite determinarrelaciones causales
escondidas en la especificación

50. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5050
Enfoque de sistemas expertos
Algunas herramientas CASEreciben el
calificativo de sistemas expertos porel
conocimientos de algunos aspectos del proceso
que ellos corporizan. Este puede ser:
• conocimiento del método, conocimiento de cómo aplicar
un método de RE
• conocimiento del dominio, conocimiento sobre el
dominio el cual se supone se modeló

51. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5151
Modos de acción de un
Sistema Experto
Comportamiento de un sistema experto
en RV
expertoexperto, lleva a cabo el proceso de
validación,
asistenteasistente, asiste al analista en la validación
aprendizaprendiz, ejecutarlas actividades de bajo
nivel de la validación

52. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5252
Validación: Salidas
Modelo de requerimientos en línea con
las expectativas de los usuarios
No significa que el modelo sea correcto
Compromiso entre lo deseado y lo
posible y factible

53. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5353
Validación
Interacción con otros procesos
•LLa validación está presente en todos los procesos
de la IR, la dispara:
nuevo conocimiento sobre el dominio
del problema (elicitación)
formulación de un modelo de
requerimientos (especificación)
La validación se requiere en las etapas
de análisis y síntesis (pues debe
chequearse la corrección de la
información)

54. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5454
Verificabilidad de los Requerimientos
Los requerimientos deberían ser
escritos de manera tal que puedan ser
objetivamente verificables.
El problema con el requerimientos es
el uso de términos vagos.
El ratio de errores debería ser
cuantificado.

55. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5555
Medidas de los Requerimientos
PropiedadPropiedad MedidaMedida
VelocidadVelocidad • Transacciones / Segundo Procecesadas
• Tiempo de Respuesta de Evento / Usuario
• Tiempo de barrido de la pantalla
TamañoTamaño • K Bytes
• Número de chips de RAM
Facilidad de UsoFacilidad de Uso • Tiempo de capacitación
• Número de entornos de ayuda
ConfiabilidadConfiabilidad • Tiempo medio entre fallas
• Probabilidad de indisponibilidad
• Ratio de Ocurrencia de Fallas
• Disponibilidad
RobustezRobustez • Tiempo de reinicio después de fallas
• Porcentaje de Eventos que causan fallas
• Probabilidad de corrupción de datos durante una falla.
PortabilidadPortabilidad • Número de Sistemas destino
• Porcentaje de definiciones dependientes del destino

56. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5656
Propiedades Deseables para la
Especificaicón de Requerimientos
Consistencia Interna
No ambigüedad
Consistencia Externa
Minimalidad
Completitud
Rastreabilidad

57. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5757
Indice del Standard de IEEEpara la
Especificación de Req. de Software
1. Introducción
1.1. Propósito
1.2. Alcance
1.3. Definiciones, acrónimos y abreviaturas
1.4. Referencias
1.5. Overview
2. Descripción general
2.1. Perspectiva del producto
2.2. Funciones del producto
2.3. Características del usuario
2.4. Restricciones generales
2.5. Supuestos y dependencias
3. Requerimientos específicos
Apéndices

58. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5858
1.Introducción
1.1. Propósito
Delinearel propósito de la SRS y especificara quién se
dirige
1.2. Alcance
Identificarlos productos de SW, explicarque hará y
que no hará cada uno, describirla aplicación
1.3. Definiciones, acrónimos y abreviaturas
Incluirlas definiciones de los términos, acrónimos y
abreviaturas requeridas para interpretarla SRS.
1.4. Referencias
Proveeruna lista completa de todos los documentos
referenciados
1.5. Overview
Describirqué contiene el resto de la SRS y explicar
cómo está organizada la SRS

59. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 5959
2.Descripción General
Describe los factores generales que afectan al producto y a los
requerimientos, facilita su comprensión
2.1. Perspectiva del producto
– Relación con otros productos o proyectos
– Productos independientes
– Componentes de un sistema o de un proyecto:
– Hardware y equipamiento periférico
– Diagrama de bloques
– Restricciones de diseño
2.2. Funciones del producto
– Resumen de las funciones que ejecutará el software.
– Comprensibilidad
– Diagrama de bloques
– No establece requerimientos específicos,

60. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 6060
2.Descripción General - II
2.3. Características del usuario
– Características generales del usuario
– Restricciones impuestas porlos interactuantes
– Requerimientos específicos o restricciones sobre la solución
2.4. Restricciones generales
– Límites al desarrollador
– Requerimientos específicos o restricciones sobre la solución
2.5. Supuestos y dependencias
– Factores que afectan los requerimientos
– Restricciones de diseño
– Cambios quepueden afectarlos requerimientos en la SRS.

61. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 6161
Descripción General - III
2.4. Restricciones generales
Límites a las opciones para diseñarel sistema:
• Políticas regulatorias
• Limitaciones de hardware
• Interfases con otras aplicaciones
• Operaciones paralelas
• Funciones de auditoría
• Funciones de control
• Requerimientos de lenguajes de alto nivel
• Protocolos de “signal handshake” (ej: XON/XOFF)
• Criticalidad de la aplicación
• Consideraciones de seguridad (Safety and Security)

62. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 6262
3.Requerimientos específicos
El sectormayory más importante de la SRS
Presentación y conceptualización del
desarrollo de los requerimientos
El contexto de la ingeniería de
requerimientos.

63. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 6363
Requerimientos específicos - I
3.1. Requerimientos funcionales
3.1.1. Requerimientos funcionales 1
3.1.1.1.Introducción
3.1.1.2.Inputs
3.1.1.3.Procesos
3.1.1.4.Outputs
.....
3.1.n. Requerimientos funcionales n
3.2. Requerimientos de interfase externa
3.2.1. Interfases del usuario
3.2.2. Interfases del hardware
3.2.3. Interfases del software
3.2.4. Interfases de comunicaciones
3.3. Requerimientos de performance
3.4. Restricciones de diseño
3.4.1. Cumplimiento de standards
3.4.2. Limitaciones de Hardware
....

64. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 6464
Requerimientos específicos - II
3.5. Atributos
3.5.1. Disponibilidad
3.5.2. Seguridad
3.5.3. Mantenibilidad
3.5.4. Transferibilidad/conversión
...
3.6. Otros requerimientos
3.6.1. Base de Datos
3.6.2. Operaciones
3.6.3. Adaptación del lugar

65. Ingeniería de RequerimientosIngeniería de RequerimientosJudith MelesJudith Meles 6565
Bibliografía
 Loucopoulos, P., Karakostas, V., System
Requirements Engineering, McGraw-Hill,
1995, London.
 Sommerville, Ian, Software Engineering
5Th Edition, Addison Wesley, 1995