ING II 2015 Clase 1 Elicitacion y Requerimientos

Ingeniera de software II
Ao 2015
Ingeniera de Software II
Planes 2015, 2011, 2007 y 2003 Lic. en Informtica

Plan 2015, 2007 Analista Programador Universitario
Planes 2015, 2011, 2007 y 2003 Lic. en Sistemas
Correlativas:
Ingeniera de Software I
Prueba de Lecto-Comprensin y Traduccin de
Ingls(final)
2015
La cursada constar de un proyecto que ser
desarrollado durante todo el semestre.
Reglamento de cursada
El proyecto ser realizado por grupos (3 personas), y

cada grupo tendr asignado un ayudante que ser el
tutor durante todo el desarrollo.
Las consultas del proyecto sern respondidas por el

ayudante asignado, en los horarios establecidos
Dicho proyecto contar con entregas parciales de
documentos establecidos, presentados en fechas
pautadas.
Una vez corregido el trabajo, cada alumno deber
presentarse a un coloquio para aprobar la cursada.
2015
Aprobacin de la Materia
4
El final de la materia se aprobar optando entre:
rendir examen escrito en las mesas de final.
rendir dos exmenes tericos durante la cursada y

sacando 6 (seis) o mas, en cada uno (con un
recuperatorio por examen)y presentndose a un
coloquio en una mesa de final, o
Los alumnos podrn optar por la primer opcin con las

siguientes condiciones:
El alumno deber contar con 80% asistencia a las teoras.
El alumno deber presentarse a rendir los 2 parciales
tericos.
El alumno que apruebe la parte terica deber
inscribirse y presentarse para un coloquio en una mesa
de final en el trmino de NO ms de 1 ao de finalizada
la cursada segn el calendario acadmico, transcurrido
el cual la aprobacin NO tendr ms validez.
2015
Teora
Horarios
Martes 14 hs a 17 hs (Aula 5)
Mircoles de 8 hs a 11 hs (Aula 9)
Prctica
Martes 17:30 a 19:30 (AULA 7)
Jueves 8:00 a 11:00 (AULA 1)
Jueves 17:30 a 19:30 (AULA 7)
Viernes 11:00 a 13:00 (AULA 1-3)
2015
Entornos de comunicacin
6
Blog de la ctedra
http://blogs.unlp.edu.ar/ingenieria2/
Curso virtual de la ctedra

http://webunlp.unlp.edu.ar
Ingeniera de Software II 2015
2015
1- Gestin o Administracin de Proyectos.
Temas a desarrollar en la materia:

2- Diseo e Implementacin de Software.
3- Verificacin y Validacin.
4- Mantenimiento de Software.
5- Gestin de Configuracin.
6- Conceptos de Auditora y Peritaje.
2015
Qu es un proceso de software?
8
Es un conjunto de actividades y resultados asociados que

producen un producto de software.
2015
Actividades fundamentales de los modelos de Proceso

Especificacin del software
Tcnicas de elicitacin
Es una representacin
abstracta de un proceso
del software.
Ingeniera de
Software I
Especificacin de requerimientos
Desarrollo del software

Validacin del software
Evolucin del software
2015
10
Les proponemos ver los videos y analizar los inconvenientes

que se producen y que sera necesario para poder
resolverlo:
El problema de la
comunicacin
Requerimientos
https://www.youtube.com/watch?v=93SgXeu-SeY
2015
11
El problema de la
comunicacin y los requisitos
2015
12
Elicitacin de Requisitos
2015
13
Qu es la elicitacin de
requisitos?
Les proponemos ver el siguiente video, y anotar los puntos

principales que definen el proceso de elicitacin y agregar
lo que hayamos visto en Ingeniera de software 1.
El video es una entrevista que le hacen en Madrid en 2014
a
Jordi
Borja
Sanz,
en
un
seminario
de
requisitos de MTP que es el director de soluciones
tecnolgicas de MTP.
MTP es una consultora
calidad del software
especializada
en
servicios
https://www.youtube.com/watch?v=wOmGTPBAJrM
2015
14
Elicitacin de Requisitos
Es el proceso de adquirir (eliciting) [sonsacar] todo el

conocimiento relevante necesario para producir un modelo
de los requerimientos de un dominio de problema
Objetivos:
Conocer el dominio del problema para poder comunicarse con
clientes y usuarios y entender sus necesidades.
Conocer el sistema actual (manual o informatizado).
Identificar las necesidades, tanto explcitas como implcitas, de
clientes y usuarios y sus expectativas sobre el sistema a
desarrollar.
2015
15
Tcnicas de elicitacin
Investigacin y visitas al lugar
Muestreo de la documentacin, los formularios y los datos

existentes
Observacin del ambiente de trabajo
Cuestionarios
Entrevistas
Planeacin conjunta de requerimientos (JRP o JAD)
Lluvia de ideas (Brainstorming)
2015
16
Muestreo de la documentacin, los

formularios y los datos existentes
Recoleccin de hechos a partir de la documentacin

existente
Qu tipo de documentos pueden ensear algo acerca
del sistema?
Organigrama (identificar el propietario, usuarios claves)
Memos, notas internas, minutas, registros contables
Solicitudes de proyectos de sistemas de informacin
anteriores
Permiten conocer el historial que origina el proyecto
2015
Muestreo
de la documentacin, los
17
Declaracin de la misin y plan estratgico de la organizacin
Documentos que describen la funcionalidad del negocio que

est siendo analizada
Objetivos formales del departamento en cuestin
Polticas, restricciones, procedimientos operativos
Formularios de operaciones realizadas
Bases de Datos
Sistemas en funcionamiento
2015
Muestreo
de la documentacin, los
18
Diagramas
Diccionario o Repositorios de proyecto
Documentacin de sistemas anteriores
Documentos de diseo
Manuales de operacin y/o entrenamiento
Tcnicas de muestreo de documentos y archivos
2015
19
Investigacin y visitas al sitio
Patrones de soluciones (mismo problema en otra

organizacin)
Investigar el dominio
Revistas especializadas
Buscar problemas similares en internet
Consultar otras organizaciones
2015
Observacin
del ambiente de
20
trabajo
Lineamientos de la observacin:
El analista se convierte en observador de las personas y

actividades con el objeto de aprender acerca del sistema.
Determinar quin y cundo ser observado
Obtener el permiso de la persona y explicar el porqu ser
observado
Mantener bajo perfil
Tomar nota de lo observado
Revisar las notas con la persona apropiada
No interrumpir a la persona en su trabajo
2015
Ventajas
Datos confiables
El analista puede ver exactamente lo que se hace (tareas
difciles de explicar con palabras)
Observacin del ambiente de

trabajo
21
Anlisis de disposiciones fsicas, trnsito, iluminacin, ruido
Econmica en comparacin con otras tcnicas
2015
22
Desventajas
La gente se siente incmoda siendo observada
Algunas actividades del sistema pueden ser realizadas en
horarios incmodos
Observacin del ambiente de

trabajo
Las tareas estn sujetas a interrupciones
Tener en cuenta que la persona observada puede estar

realizando las tareas de la forma correcta y no como lo hace
habitualmente
2015
23
Cuestionarios
Recolectar hechos de un gran nmero de personas
Documento que permite al analista recabar informacin y

opiniones de los encuestados
Detectar un seguimiento generalizado
Detectar problemas entre usuarios
Cuantificar respuestas
2015
24
Cuestionarios
Por qu son fciles de analizar?
Permiten una respuesta rpida? Por qu?

Qu estrategia se puede utilizar para acelerar el proceso
de creacin de los cuestionarios?
Qu inconvenientes encuentra en la puesta en prctica
del cuestionario?
Qu tipos de cuestionarios conoce y cul es el objetivo de
cada uno?
2015
25
Entrevistas
Tcnica de exploracin mediante la cual el analista de

sistemas recolecta informacin de las personas a travs de
la interaccin cara a cara
Es una conversacin con un propsito especfico, que se
basa en un formato de preguntas y respuestas en general
Conocer opiniones y sentimientos del entrevistado
2015
26
Entrevistas
Qu inconvenientes encuentra en la tcnica de entrevista?
Qu ventajas tiene poder realizar el trabajo cara a cara

con el entrevistado?
Qu tipo de entrevista realizara si no es experto en la
tcnica? Por qu?
Dada la solicitud de desarrollo de un sistema de un tema

que desconoce:
como se preparara para la entrevista ?
qu tipo de tcnicas aplicara?
2015
Entrevistas
27
Debe
Evite
Vestirse adecuadamente
Ser corts
Escuchar
cuidadosamente
Suponer que una respuesta

no lleva a ningn lado
Revelar pistas
Usar jerga
Mantener el control
Revelar sesgos personales
Observar los gestos
Hablar en lugar de
escuchar
Ser paciente
Mantener al entrevistado
en calma
Mantener el autocontrol
Terminar a tiempo
Suponer cualquier cosa

acerca del tema o del
entrevistado
Uso de grabadores (seal
de debilidad de escuchar)
2015
29
Proceso mediante el cual se conducen reuniones de grupo

altamente estructurados con el propsito de analizar
problemas y definir requerimientos
Planeacin Conjunta de
Requerimiento (JRP)
Requiere de extenso entrenamiento

Reduce el tiempo de exploracin de requisitos
Amplia participacin de los integrantes

Se trabaja sobre lo que se va generando
Alguna bibliografa la menciona como JAD (Joint
Application Design)
2015
Ventajas
Ahorro de tiempo
Usuarios involucrados
Planeacin Conjunta de
Requerimiento (JRP)
30
Desarrollos creativos
Desventajas
Es difcil organizar los horarios de los involucrados
Es complejo encontrar un grupo de participantes integrados y
organizados
2015
31
Lluvia De Ideas (Brainstorming)

Tcnica para generar ideas al alentar a los participantes

para que ofrezcan tantas ideas como sea posible en un
corto tiempo sin ningn anlisis hasta que se hayan agotado
las ideas.
Se promueve el desarrollo de ideas creativas para obtener
soluciones.
Se realizan reuniones del equipo involucrado en la resolucin
del problema, conducidas por un director.
2015
32
Cuantas ms ideas se sugieren, mejores resultados se

conseguirn.
Los principios en que se basa esta tcnica son:
La produccin de ideas en grupos puede ser ms efectiva que

la individual.
Las ideas de una persona pueden hacer que aparezcan otras
por contagio.
A veces las mejores ideas aparecen tarde.
Es mejor elegir sobre una variedad de soluciones.
2015
33
Descubrir hechos, Producir ideas, Descubrir soluciones
Clave para resolver la falta de consenso entre usuarios
Incluye una serie de fases de aplicacin:
Es til combinarlo con la toma de decisiones

Ayuda a entender el dominio del problema
Encara la dificultad del usuario para transmitir
Ayuda a entender: al usuario y al analista
2015
34
Requerimientos
2015
35
Requerimientos
Especificacin
Solicitud
Definicin
Anlisis
2015
Requerimientos
36
Necesario: Su omisin provoca una deficiencia.

Conciso: Fcil de leer y entender
Completo: No necesita ampliarse
Consistente: No contradictorio con otro
No ambiguo: Tiene una sola implementacin
Verificable: Puede testearse a travs de inspecciones, pruebas,
etc.
Caractersticas
Dificultades para definir los requerimientos
No son obvios
Provienen de muchas fuentes
Estn interrelacionados
Pueden ser muchos
Pueden cambiar a lo largo del desarrollo
Son particulares para cada proyecto
Participantes
Los clientes, usuarios, gerentes de negocio, supervisores de
contrato, analistas, diseadores, verificadores
2015
Defectos en los requerimientos
37
Es muy difcil estimar los costos y recursos necesarios para

desarrollar algo que no se conoce.
Planificacin
Estimacin
No se puede confiar en la planificacin para el desarrollo de

algo que no se sabe bien como es.
Diseo
Los errores en requerimientos, las modificaciones frecuentes, las
deficiencias en restricciones o futuras evoluciones, producen
arquitecturas que ms tarde se confirmarn como errneas y
sern modificadas
Requerimientos
Estimacin
Planificacin
Diseo
Construccin
V&V
2015
Defectos en los requerimientos
38
Las deficiencias en los requerimientos obligan a programar en

ciclos de prueba y error que derrochan horas y paciencia de
programacin sobre patrones de recodificacin continua y
programacin heroica.
Construccin
Validacin
Terminado el desarrollo del sistema, si las especificaciones tienen
errores grandes o no estn reflejadas en una especificacin de
requerimientos, no ser posible validar el producto con el
cliente.
Requerimientos
Estimacin
Planificacin
Diseo
Construccin
V&V
2015
39
Buenos requerimientos
Requerimientos bien elaborados y validados con el cliente

evitan descubrir al terminar el proyecto que el sistema no era lo
que se peda.
Acuerdo entre desarrolladores, clientes y usuarios sobre el

trabajo que debe realizarse.
Acuerdo entre desarrolladores, clientes y usuarios sobre los

criterios que se emplearn para su validacin.
Resulta muy difcil demostrar al cliente que el producto
desarrollado hace lo que el pidi si su peticin no est
documentada y validada por l.
Base objetiva para la estimacin de recursos (costo, personal

en nmero y competencias, equipos y tiempo)
Las estimaciones en el fondo son clculos de probabilidad que
siempre implican un margen de error; por esta razn disponer de
la mayor informacin posible reduce el error.
2015
40
Buenos requerimientos
Ms all de funcionalidades precisas, los requerimientos

recogen atributos de calidad necesarios que en ocasiones no
son tenidos en cuenta por los desarrolladores, produciendo
sistemas con serias deficiencias de rendimiento.
Concrecin de los atributos de calidad (ergonoma,

mantenibilidad, etc.)
Eficiencia en el consumo de recursos: reduccin de la recodificacin, reduccin de omisiones y malentendidos.

Tener un conocimiento preciso de lo que hay que hacer evita la
prueba y error, repeticin de partes ya desarrolladas, etc.
2015
Tipos de requerimientos
41
Definen el comportamiento del sistema.
Requerimiento Funcionales
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el
equilibrio entre la excesiva generalidad, y el exceso de detalle
con descripciones innecesarias o redundantes.
Requerimiento No Funcionales
Definen aspectos, que sin ser funcionalidades, (tareas que el
sistema debe realizar) resultan deseables desde el punto de vista
del usuario. Tambin se pueden ver como restricciones.
Tiempos de respuesta.
Caractersticas de usabilidad.
Facilidad de mantenimiento.
etc.
2015
42
Documento, tambin denominado ConOps y normalizado en el

estndar IEEE Std. 1362-1998.
Documento dirigido a los usuarios, que describe las caractersticas
de un sistema propuesto, desde el punto de vista del usuario. La
Descripcin del Sistema es el medio de comunicacin que recoge la
visin general, cualitativa y cuantitativa de las caractersticas del
sistema; compartido por la parte cliente y desarrolladora.
Requerimientos del Software
ConOps IEEE Std1362
Descripcin del sistema
Especificacin de
requerimientos
Documento, tambin denominado SRS (ERS)y normalizado en el

Un documento SRS es la especificacin de las funciones que realiza
un determinado producto de software, programa o conjunto de
programas en un determinado entorno. El documento de
especificacin de requisitos puede desarrollarlo personal
representativo de la parte desarrolladora, o de la parte cliente; si
bien es aconsejable la intervencin de ambas partes
2015
43
Ofrece un formato y contenidos para la confeccin de las

descripciones de sistema en los desarrollos y modificaciones
de sistemas.
Descripcin del sistema - IEEE

1362
El estndar no especifica tcnicas exactas, sino que

proporciona las lneas generales que deben respetarse. Es
una gua de referencia.
Las partes esenciales de un ConOps son:
Punto 3: Descripcin del sistema existente.
Punto 4: Descripcin del sistema propuesto.
El estndar identifica los elementos que al menos debe

incluir una Descripcin del sistema. El usuario puede
incorporar otros elementos, agregando clusulas y subclusulas.
2015
44
IEEE 1362
2015
45
IEEE 1362
2015
46
Descripcin del sistema

Documento, tambin denominado ConOps y normalizado en el
Especificacin de
requerimientos
Documento dirigido a los usuarios, que describe las caractersticas

de un sistema propuesto, desde el punto de vista del usuario. La
Descripcin del Sistema es el medio de comunicacin que recoge la
visin general, cualitativa y cuantitativa de las caractersticas del
sistema; compartido por la parte cliente y desarrolladora.
Requerimientos del Software
Un documento SRS es la especificacin de las funciones que realiza

un determinado producto de software, programa o conjunto de
programas en un determinado entorno. El documento de
especificacin de requisitos puede desarrollarlo personal
representativo de la parte desarrolladora, o de la parte cliente; si
bien es aconsejable la intervencin de ambas partes
SRS IEEE Std 830
Documento, tambin denominado SRS (ERS)y normalizado en el

2015
47
Requerimientos del Software IEEE-830
En las Especificaciones de Requerimientos de software, se debe

evitar incluir requerimientos de diseo o de proyecto.
SRS IEEE 830
Los aspectos bsicos que una descripcin de requerimientos

debe cubrir son:
Funcionalidad. Descripcin de lo que el software debe hacer.

Interfaces externas. Cmo debe interactuar el software con las
personas, el hardware, o con otros sistemas.
Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos
de respuesta, tiempos de recuperacin, tiempos de
determinadas funciones.
Atributos. Consideraciones de portabilidad, correccin,
mantenibilidad, seguridad, etc.
Restricciones de diseo en la implementacin. Indicacin de las
restricciones que puedan afectar por la necesidad de
sometimiento a estndares, lenguajes, polticas de integridad de
bases de datos, lmites de recursos disponibles para el desarrollo,
sistema operativo, etc.
2015
48
IEEE 830
2015
49
IEEE 830- SRS
Brindar una coleccin de buenas prcticas para escribir

especificaciones de requerimientos de software (SRS). Se
describen los contenidos y las cualidades de una buena
especificacin de requerimientos.
Resumen - Alcance
2015
50
Consideraciones para un buen SRS
El SRS es una especificacin para un producto de software

particular. El SRS es escrito por uno o mas representantes del
equipo de desarrollo y uno o mas representantes de la parte
cliente o ambos.
Naturaleza del SRS
Ambiente del SRS

El software puede contener toda la funcionalidad del proyecto
o puede ser parte de un sistema ms grande. En el ltimo caso
habr un SRS que declarar las interfaces entre el sistema y su
software desarrollado, y pondr qu funcin externa y
requerimientos de funcionalidad tiene con el software
desarrollado.
Caractersticas de un buen SRS

Correcto, no ambiguo, completo , consistente, priorizable,
comprobable, modificable, trazable
2015
51

Un SRS es correcto si, y slo si, cada requisito declarado se

encuentra en el software.
Correcto
No ambiguo
Un SRS es inequvoco si, y slo si, cada requisito declarado
tiene slo una interpretacin.
Completo
Un SRS est completo si, y slo si, se reconoce cualquier
requisito externo impuesto por una especificacin del
sistema.
Consistente
La consistencia se refiere a la consistencia interior. Si un SRS
no est de acuerdo con algn documento del nivel superior,
como una especificacin de requerimientos de sistema,
entonces no es consistente.
2015
52

Un SRS es priorizado por la importancia de sus requerimientos

particulares
Comprobable
Priorizado
Un SRS es comprobable si, y slo si, cada requisito declarado es

comprobable. Un requisito es comprobable si, y slo si, existe
algn proceso con que una persona o mquina puede verificar
que el producto del software rene el requisito. En general
cualquier requisito ambiguo no es comprobable
Modificable
Un SRS es modificable si, y slo si, su estructura y estilo son tales

que puede hacerse cualquier cambio a los requerimientos
fcilmente, completamente y de forma consistente mientras
conserva la estructura y estilo
Trazabilidad
Claridad del origen de cada requerimiento y su trazabilidad

hacia los requerimientos futuros desarrollos. Hacia adelante y
hacia atrs
2015
53
El SRS se debe preparar en conjunto con las partes intervinientes

para lograr un buen acuerdo entre las partes
Evolucin de SRS
Preparacin conjunta del SRS
El SRS debe evolucionar conjuntamente con el software,

registrando los cambios, los responsables y aceptacin de los
mismos.
Prototipos
El uso de prototipos se utiliza frecuentemente para la definicin

de requerimientos
Diseo incorporado en el SRS
El SRS puede incorporar los atributos o funciones externos al

sistema, en particular las que describen el diseo para
interactuar entre los subsistemas.
Requerimientos incorporados en el SRS
Los detalles particulares de los requerimientos son anexados

como documentos externos (CU, Plan de proyecto, Plan de
aseguramiento de la calidad, etc.)
2015
Partes de un SRS
54
2015
55
1.1 Propsito
Se define el propsito del documento y se especifica a quin va

dirigido el documento
1.2 Alcance o mbito del sistema
Se da un nombre al futuro sistema

Se explica lo que el sistema har y lo que no har.
Se describen los beneficios, objetivos y metas que se espera
alcanzar con el futuro sistema
Seccin 1 del SRS

1 Introduccin
1.3 Definiciones, siglas y abreviaciones

Glosario
1.4 Referencias
Esta subdivisin debe proporcionar una lista completa de todas

las referencias de los documentos mencionados o utilizados
para escribir el SRS. Identificar cada documento por el ttulo,
nmero de reporte, fecha y publicacin. Tambin se deben
especificar las fuentes de las referencias de donde se
obtuvieron.
1.5 Visin Global - Resumen
Describe lo que el resto del SRS contiene

Explica cmo el SRS es organizado.
2015
56
Esta seccin del SRS debe describir los factores generales

que afectan el producto y sus requerimientos. Esta seccin
no declara los requerimientos especficos. En cambio,
mantiene una mencin general de esos requerimientos que
se definen en detalle en Seccin 3 del SRS y los hacen ms
fciles de entender.
Seccin 2 del SRS

2 Descripcin General
Esta seccin normalmente consiste en seis subdivisiones,

como sigue:
1. Perspectiva del producto
2. Funcionalidades del producto
3. Caractersticas de los usuarios
4. Restricciones
5. Suposiciones y dependencias
6. Evoluciones previsibles del sistema
2015
57
2.1. Perspectiva del producto

Si el producto es independiente y totalmente autnomo, debe declararse
que as es.
Seccin 2 del SRS

Si el SRS define un producto que es un componente de un sistema ms

grande entonces esta subdivisin debe relacionar los requerimientos de
ese sistema ms grande a la funcionalidad del software y debe identificar
las interfaces entre ese sistema y el software.
2.2. Funciones del sistema

Se debe presentar un resumen, a grandes rasgos, de las funciones del
futuro sistema.
Las funciones debern mostrarse de forma organizada, y pueden
utilizarse grficos, siempre y cuando dichos grficos reflejen las relaciones
entre funciones y no el diseo del sistema.
2.3. Caractersticas del Usuario

Se deben describir las caractersticas generales de los usuarios
intencionales del producto que incluye nivel educativo, experiencia, y la
especializacin tcnica.
2015
58
2.4. Restricciones
a) Las interfaces: del Sistema, del Usuario, del Hardware; de las
de Comunicaciones; b) Acceso y uso de la Memoria; c) Los
requerimientos de adaptacin del Sitio d) Polticas de la
empresa e) Limitaciones del hardware f) Interfaces con otras
aplicaciones g) Operaciones paralelas h) Funciones de auditora
i) Lenguaje(s) de programacin. Bases de Datos. j) Protocolos de
comunicacin k) Req. de fiabilidad l) Consideraciones acerca
de la seguridad
Seccin 2 del SRS

2.5. Suposiciones y dependencias

Se describen aquellos factores que, si cambian, pueden afectar
a los requerimientos.
2.6 Evoluciones previsibles del sistema

Se identifican requerimientos que sern implementados en
futuras versiones
2015
59
Debe contener todos los requerimientos del software a un nivel

de detalle suficiente para permitirles a los diseadores disear
un sistema para satisfacer esos requerimientos, y a los auditores
probar que el sistema satisface esos requerimientos.
Seccin 3 del SRS

3 Requerimientos especficos
A lo largo de esta seccin, cada requisito declarado debe ser

externamente perceptible por los usuarios, operadores u otros
sistemas externos.
1. Requerimientos comunes de interfaces
Descripcin detallada de todas las entradas y salidas del sistema de
software.
2. Requerimientos funcionales
Descripcin de las funcionalidades de sistema
3. Requerimientos no funcionales
Descripcin de los requerimientos no funcionales
4. Otros requerimientos
2015
60
3.1.1Interfaces de usuario
Describir los requerimientos del interfaz de usuario para el producto.
Esto puede estar en la forma de descripciones del texto o pantallas del
interfaz.
Seccin 3 del SRS

3.1Requerimientos comunes de las
interfaces
3.1.2 Interfaces de hardware

Especificar las caractersticas lgicas para cada interfaz entre el producto
y los componentes de hardware del sistema. Se incluirn caractersticas
de configuracin.
3.1.3 Interfaces de software

Indicar si hay que integrar el producto con otros productos de software.
Para cada producto de software debe especificarse lo siguiente:
Descripcin del producto software utilizado, Propsito del interfaz,
Definicin del interfaz.
3.1.4 Interfaces de comunicacin

Describir los requerimientos de interfaces de comunicacin si hay
comunicaciones con otros sistemas y cules son los protocolos de
comunicacin.
2015
61
Seccin 3 del SRS

3.2 Requerimientos funcionales
Objetivo, descripcin, secuencia exacta de operaciones,

respuesta a situaciones anormales, etc.
3.2.1 Requisito funcional 1
3.2.n Requisito funcional n

Objetivo, descripcin, secuencia exacta de operaciones,
respuesta a situaciones anormales, etc.
Sern desarrollados utilizando Historias de Usuarios
2015
62
Seccin 3 del SRS

3.3 Requerimientos no funcionales
Especificacin de los requerimientos relacionados con la carga que se

espera tenga que soportar el sistema. Por ejemplo, el nmero de
terminales, el nmero esperado de usuarios simultneamente
conectados, etc.
Todos estos requerimientos deben ser mensurables. Por ejemplo,
indicando el 95% de las transacciones deben realizarse en menos de 1
segundo, en lugar de los operadores no deben esperar a que se
complete la transaccin.
3.3.1 Requerimientos de rendimiento
3.3.2 Seguridad
Especificacin de elementos que protegern al software de accesos,

usos y sabotajes maliciosos, as como de modificaciones o destrucciones
maliciosas o accidentales. Los requerimientos pueden especificar:
Empleo de tcnicas criptogrficas, Registro de ficheros con logs de
actividad, Asignacin de determinadas funcionalidades a determinados
mdulos, Restricciones de comunicacin entre determinados mdulos,
Comprobaciones de integridad de informacin crtica.
3.3.3 Fiabilidad
Especificacin de los factores de fiabilidad necesaria del sistema. Esto se

expresa generalmente como el tiempo entre los incidentes permisibles, o
el total de incidentes permisible.
2015
63
Seccin 3 del SRS

3.3 Requerimientos no funcionales
Especificacin de los factores de disponibilidad final exigidos al

sistema. Normalmente expresados en % de tiempo en los que el
software tiene que mostrar disponibilidad.
3.3.4 Disponibilidad
3.3.5 Mantenibilidad
Identificacin del tipo de mantenimiento necesario del sistema.
Especificacin de quin debe realizar las tareas de mantenimiento,
por ejemplo usuarios, o un desarrollador. Especificacin de cundo
deben realizarse las tareas de mantenimiento. Por ejemplo,
generacin de estadsticas de acceso semanales y mensuales.
3.3.6 Portabilidad
Especificacin de atributos que debe presentar el software para
facilitar su traslado a otras plataformas u entornos. Pueden incluirse:
Porcentaje de componentes dependientes del servidor. Porcentaje
de cdigo dependiente del servidor. Uso de un determinado
lenguaje por su portabilidad. Uso de un determinado compilador o
plataforma de desarrollo. Uso de un determinado sistema operativo.
2015
64
Seccin 3 del SRS

3.4 Otros Requerimientos y 4 Apndice
Por ejemplo:
3.4 Cualquier otro requisito que no encaje en ninguna de las

secciones anteriores.
requerimientos culturales y polticos
requerimientos legales
4 Apndices
Pueden contener todo tipo de informacin relevante para la SRS
pero que, propiamente, no forme parte de la SRS.
Por ejemplo:
Casos de Uso
2015

ING II 2015 Clase 1 Elicitacion y Requerimientos

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ING II 2015 Clase 1 Elicitacion y Requerimientos

Caricato da

Copyright:

Formati disponibili

Ingeniera de software II

Planes 2015, 2011, 2007 y 2003 Lic. en Informtica

Planes 2015, 2011, 2007 y 2003 Lic. en Sistemas

El proyecto ser realizado por grupos (3 personas), y

Las consultas del proyecto sern respondidas por el

rendir examen escrito en las mesas de final.

rendir dos exmenes tericos durante la cursada y

Los alumnos podrn optar por la primer opcin con las

Curso virtual de la ctedra

1- Gestin o Administracin de Proyectos.

Temas a desarrollar en la materia:

Es un conjunto de actividades y resultados asociados que

Actividades fundamentales de los modelos de Proceso

Desarrollo del software

Les proponemos ver los videos y analizar los inconvenientes

Les proponemos ver el siguiente video, y anotar los puntos

Es el proceso de adquirir (eliciting) [sonsacar] todo el

Investigacin y visitas al lugar

Muestreo de la documentacin, los formularios y los datos

Muestreo de la documentacin, los

Recoleccin de hechos a partir de la documentacin

Permiten conocer el historial que origina el proyecto

Declaracin de la misin y plan estratgico de la organizacin

Documentos que describen la funcionalidad del negocio que

Documentacin de sistemas anteriores

Tcnicas de muestreo de documentos y archivos

Investigacin y visitas al sitio

Patrones de soluciones (mismo problema en otra

El analista se convierte en observador de las personas y

Observacin del ambiente de

Anlisis de disposiciones fsicas, trnsito, iluminacin, ruido

Econmica en comparacin con otras tcnicas

Observacin del ambiente de

Las tareas estn sujetas a interrupciones

Tener en cuenta que la persona observada puede estar

Recolectar hechos de un gran nmero de personas

Documento que permite al analista recabar informacin y

Por qu son fciles de analizar?

Permiten una respuesta rpida? Por qu?

Tcnica de exploracin mediante la cual el analista de

Qu inconvenientes encuentra en la tcnica de entrevista?

Qu ventajas tiene poder realizar el trabajo cara a cara

Dada la solicitud de desarrollo de un sistema de un tema

Suponer que una respuesta

Revelar sesgos personales

Observar los gestos

Suponer cualquier cosa

Proceso mediante el cual se conducen reuniones de grupo

Requiere de extenso entrenamiento

Amplia participacin de los integrantes

Lluvia De Ideas (Brainstorming)

Tcnica para generar ideas al alentar a los participantes

Lluvia De Ideas (Brainstorming)

Cuantas ms ideas se sugieren, mejores resultados se

Los principios en que se basa esta tcnica son:

La produccin de ideas en grupos puede ser ms efectiva que

Lluvia De Ideas (Brainstorming)

Descubrir hechos, Producir ideas, Descubrir soluciones

Clave para resolver la falta de consenso entre usuarios

Incluye una serie de fases de aplicacin:

Es til combinarlo con la toma de decisiones

Necesario: Su omisin provoca una deficiencia.

Dificultades para definir los requerimientos

Defectos en los requerimientos