Está en la página 1de 63

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

Ingeniera de software II

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

Correlativas:
Ingeniera de Software I
Prueba de Lecto-Comprensin y Traduccin de
Ingls(final)

2015

Ingeniera de Software II
La cursada constar de un proyecto que ser
desarrollado durante todo el semestre.

Ingeniera de software II

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.

Ingeniera de software II

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

Ingeniera de Software II

Teora

Ingeniera de software II

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
Ingeniera de software II

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

Ingeniera de Software II

1- Gestin o Administracin de Proyectos.

Ingeniera de software II

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
Ingeniera de software II

Es un conjunto de actividades y resultados asociados que


producen un producto de software.

2015

Ingeniera de Software II

Actividades fundamentales de los modelos de Proceso


Especificacin del software
Tcnicas de elicitacin

Ingeniera de software II

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:

Ingeniera de software II

El problema de la
comunicacin

Requerimientos

https://www.youtube.com/watch?v=93SgXeu-SeY

2015

11

Ingeniera de software II

El problema de la
comunicacin y los requisitos

2015

12

Elicitacin de Requisitos

Ingeniera de software II

2015

13

Ingeniera de software II

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
Ingeniera de software II

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

Ingeniera de software II

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
Ingeniera de software II

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
formularios y los datos existentes

Declaracin de la misin y plan estratgico de la organizacin

Ingeniera de software II

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
formularios y los datos existentes
Diagramas
Diccionario o Repositorios de proyecto

Ingeniera de software II

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)

Ingeniera de software II

Investigar el dominio

Revistas especializadas
Buscar problemas similares en internet
Consultar otras organizaciones

2015

Observacin
del ambiente de
20
trabajo

Lineamientos de la observacin:

Ingeniera de software II

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)

Ingeniera de software II

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

Ingeniera de software II

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

Ingeniera de software II

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?

Ingeniera de software II

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
Ingeniera de software II

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?

Ingeniera de software II

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

Ingeniera de software II

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

Ingeniera de software II

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

Ingeniera de software II

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)


Ingeniera de software II

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

Lluvia De Ideas (Brainstorming)

Cuantas ms ideas se sugieren, mejores resultados se


conseguirn.

Ingeniera de software II

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

Lluvia De Ideas (Brainstorming)

Descubrir hechos, Producir ideas, Descubrir soluciones

Clave para resolver la falta de consenso entre usuarios

Ingeniera de software II

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

Ingeniera de software II

2015

35

Requerimientos

Especificacin

Ingeniera de software II

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.

Ingeniera de software II

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

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

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

Ingeniera de software II

Especificacin de
requerimientos

Documento, tambin denominado SRS (ERS)y normalizado en el


estndar IEEE Std. 830-1998.
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.

Ingeniera de software II

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

Ingeniera de software II

2015

45

IEEE 1362

Ingeniera de software II

2015

46

Descripcin del sistema


Documento, tambin denominado ConOps y normalizado en el
estndar IEEE Std. 1362-1998.

Ingeniera de software II

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


estndar IEEE Std. 830-1998.

2015

47

Requerimientos del Software IEEE-830

En las Especificaciones de Requerimientos de software, se debe


evitar incluir requerimientos de diseo o de proyecto.

Ingeniera de software II

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

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

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

Consideraciones para un buen SRS


Caractersticas de un buen SRS

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


encuentra en el software.

Ingeniera de software II

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

Consideraciones para un buen SRS


Caractersticas de un buen SRS

Un SRS es priorizado por la importancia de sus requerimientos


particulares

Comprobable

Ingeniera de software II

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

Consideraciones para un buen SRS

53

El SRS se debe preparar en conjunto con las partes intervinientes


para lograr un buen acuerdo entre las partes

Evolucin de SRS

Ingeniera de software II

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

Ingeniera de software II

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

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

Seccin 2 del SRS


2 Descripcin General

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

Ingeniera de software II

Seccin 2 del SRS


2 Descripcin General

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.

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

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.

Ingeniera de software II

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:

Ingeniera de software II

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