INGENIERÍA DE SOFTWARE II

Requerimientos
Requerimientos

Solicitud
Definición

Especificación Análisis
Requerimientos
Características
• Necesario: Su omisión provoca una deficiencia.
• Conciso: Fácil de leer y entender
• Completo: No necesita ampliarse
• Consistente: No contradictorio con otro
• No ambiguo: Tiene una sola implementación
• Verificable: Puede testearse a través de inspecciones, pruebas, etc.
Dificultades para definir los requerimientos
• No son obvios
• Provienen de muchas fuentes
• Están 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,
diseñadores, verificadores
Defectos en los requerimientos
Estimación
• No es posible estimar los costos y recursos necesarios para desarrollar algo que
no se conoce.
Planificación
• No se puede confiar en la planificación para el desarrollo de algo que no se sabe
bien como es.
Diseño
• Los errores en requisitos, las modificaciones frecuentes, las deficiencias en
restricciones o futuras evoluciones, producen arquitecturas que más tarde se
confirmarán como erróneas y serán modificadas.

REQUISITOS

Estimación Planificación Diseño Construcción V&V

Defectos en los requerimientos
Construcción
• Las deficiencias en los requisitos obligan a programar en ciclos de
prueba y error que derrochan horas y paciencia de programación sobre
patrones de “recodificación continua” y “programación heroica”.
Validación y verificación
• Terminado el desarrollo del sistema, si las especificaciones tienen errores
grandes o no están reflejadas en una especificación de requisitos, no será
posible validar el producto con el cliente.

REQUISITOS

Estimación Planificación Diseño Construcción V&V

Buenos requerimientos
Acuerdo entre desarrolladores, clientes y usuarios sobre el
trabajo que debe realizarse.
• Unos requisitos bien elaborados y validados con el cliente evitan descubrir al
terminar el proyecto que el sistema no era lo que se pedía.

Acuerdo entre desarrolladores, clientes y usuarios sobre los

criterios que se emplearán para su validación.
• Resulta muy difícil demostrar al cliente que el producto desarrollado hace lo que el
pidió si su petición no está documentada y validada por él.

Base objetiva para la estimación de recursos (costo, personal en

número y competencias, equipos y tiempo)
• Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de
ser meras apuestas. Las estimaciones en el fondo son cálculos de probabilidad que
siempre implican un margen de error; por esta razón disponer de la mayor
información posible reduce el error.
Buenos requerimientos
Concreción de los atributos de calidad (ergonomía,
mantenibilidad, etc.)
• Más allá de funcionalidades precisas, los requisitos recogen atributos de calidad
necesarios que en ocasiones son desconocidos por los desarrolladores, produciendo
finalmente sistemas sobredimensionados o con serias deficiencias de rendimiento.

Eficiencia en el consumo de recursos: reducción de la re-

codificación, reducción de omisiones y malentendidos.
• Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error,
repetición de partes ya desarrolladas, etc.
Tipos de Requerimientos
Requerimiento Funcionales
• Definen el comportamiento del sistema.
• Describen las tareas que el sistema debe realizar.
• Al definir un requisito funcional es importante mantener el equilibrio entre la
excesiva generalidad, insuficiencia de detalle o ambigüedad, y el exceso de
detalle con precisiones o 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.
Generalmente comprenden atributos de calidad:
• Tiempos de respuesta.
• Características de usabilidad.
• Facilidad de mantenimiento.
• etc.
Especificación de requerimientos
Descripción del sistema
Sistema ConOps
Ámbitos
Requerimientos del software
Software
SRS

Descripción del sistema

• Documento, también denominado ConOps y normalizado en el estándar IEEE Std. 1362-
1998.
• Documento dirigido a los usuarios, que describe las características de un sistema propuesto,
desde el punto de vista del usuario. La Descripción del Sistema es el medio de comunicación
que recoge la visión general, cualitativa y cuantitativa de las características del sistema;
compartido por la parte cliente y desarrolladora.

Requerimientos del Software

• Documento, también denominado SRS (ERS)y normalizado en el estándar IEEE Std. 830-1998.
• Un documento SRS es la especificación de las funciones que realiza un determinado producto
de software, programa o conjunto de programas en un determinado entorno. El documento de
especificación de requisitos puede desarrollarlo personal representativo de la parte
desarrolladora, o de la parte cliente; si bien es aconsejable la intervención de ambas partes
Descripción del sistema - IEEE 1362
 Ofrece un formato y contenidos para la confección de las
descripciones de sistema en los desarrollos y modificaciones de
sistemas.
 El estándar no especifica técnicas exactas, sino que proporciona las
líneas generales que deben respetarse. No es por tanto un modelo
final, sino una guía de referencia sobre la que cada organización
debe desarrollar sus propias prácticas y procedimientos para
preparar y actualizar su documentación con las descripciones de los
sistemas.
 Las partes esenciales de un ConOps son:
 Punto 3: Descripción del sistema existente.
 Punto 4: Descripción del sistema propuesto.
 El estándar identifica los elementos que al menos debe incluir una
Descripción del sistema. El usuario puede incorporar otros elementos,
agregando cláusulas y sub-cláusulas.
IEEE 1362
IEEE 1362
IEEE 1362 ConOps

1 - Resumen - Alcance
• Define el formato y contenido de un documento de descripción de
sistemas. Desde el punto de vista del usuario
2 - Referencias
• Artículos en los que se basa el estándar

3 - Definiciones
• Análisis, restricciones, contrato, cliente, usuarios, etc.

4- Elementos de un Documento ConOps

4- Elementos de un Documento ConOps

4.1- Alcance
• El contenido de este apartado debe proporcionar una breve introducción del documento, su
relación con otros posibles documentos, su finalidad y los destinatarios de la información
que contiene.
4.1.1- Identificación
• Identificación del sistema, proporcionando su nombre y abreviatura (si procede).

4.1.2 - Visión general del documento

• Explicación del propósito, audiencia, y consideraciones de seguridad o privacidad del
documento.
• Generalmente, el propósito del documento suele ser uno de los siguientes:
• Comunicar las necesidades y expectativas del cliente
• Comunicar el entendimiento del proyecto
• Obtener acuerdos entre las partes implicadas (personal representante de la parte cliente,
personal del equipo de desarrollo, etc.)
4- Elementos de un Documento ConOps

4.1.3- Visión general del sistema

• Resumen del propósito del sistema o subsistema propuesto (al cual se aplica la descripción del
sistema).
4.2 – Documentos referenciados
• Relación de los documentos a los que se hace referencia en los requisitos del sistema, indicando,
según proceda: el código del documento, título, ruta, revisión, fecha y origen.
4.3 – Sistema Actual
4.3 – Sistema Actual
4.3.1 Antecedentes
• Visión general del sistema o situación actual, incluyendo objetivos, alcance.

4.3.2 Políticas y restricciones operacionales

• Relación de políticas o restricciones de cualquier índole impuestas sobre el sistema o
situación actual.
4.3.3 Descripción del sistema o situación actual
• Descripción detallada del sistema o situación actual y de su funcionamiento. Enumeración y
descripción de funciones, características y capacidades del sistema o situación actual.
4.3.4 Tipos de usuarios
• Relación de los tipos de usuario. Un tipo de usuario se distingue por el modo en el cual un
usuario interactúa con el sistema.
• Factores como la responsabilidad, habilidades, competencias, etc. distinguen a los distintos
tipos de usuarios
4.3 – Sistema Actual

4.3.5 Mantenimiento / soporte

• Descripción de las necesidades de mantenimiento, reparación, almacenamiento,
distribución, sistemas de copias de seguridad, sistemas de emergencia, etc.
4.3.6 Necesidad y naturaleza de los cambios
• Descripción de las carencias, defectos o debilidades del sistema o situación actual y
que motivan al desarrollo de un nuevo sistema o, a una modificación del existente.
• De no existir un sistema anterior (ni tan siquiera manual), en este apartado y
subapartados deben quedar reflejadas las justificaciones que llevan al cambio.

4.3.7 Descripción de los cambios deseados

• Enumeración de las capacidades, funciones, procesos, etc. que deben generarse o
modificarse para satisfacer las nuevas necesidades.
• Los cambios deben basarse en el sistema descrito en el punto 3.3. Si no existe un
sistema anterior, en este apartado se enumeran las capacidades requeridas del nuevo
sistema.
4.4 Sistema Propuesto
4.4.1 Antecedentes
• Visión general del sistema propuesto, incluyendo: misión, objetivos, alcance

4.4.2 Políticas y restricciones operacionales

• Relación de políticas o restricciones de cualquier índole aplicables al sistema
propuesto.
4.4.3 Descripción del sistema propuesto
• Descripción detallada del sistema propuesto y de su funcionamiento.

4.4.4 Tipos de usuarios

• Relación de los tipos de usuario. Un tipo de usuario se distingue por el modo en el
cual un usuario interactúa con el sistema.
• Factores como la responsabilidad, habilidades, competencias, etc. distinguen a los
distintos tipos de usuarios
4.4 Sistema Propuesto

4.4.5 Mantenimiento / soporte

• Descripción de las necesidades de mantenimiento, reparación,
almacenamiento, distribución, sistemas de copias de seguridad.
4.4.6 Futuras evoluciones
• Descripción de las previsiones de evolución que se tienen previstas para el
sistema (si se tiene).
• Esta información resulta útil para el personal involucrado en el desarrollo
del nuevo sistema, y podrá preparar la arquitectura del sistema para
asimilar cambios futuros con el menor impacto.
4.4.7 Cambios considerados pero no incluidos
• Identificación de cambios considerados pero no incluidos en el sistema
propuesto y el motivo por el que no han sido incluidos.
IEEE 1362 ConOps
5 Resumen de mejoras
• Resumen de los beneficios proporcionados por el sistema propuesto.

6 Información adicional
• Cualquier información adicional que facilite la comprensión del documento
en sí.
Elementos de un Documento ConOps

“VCAdmin” - Sistema de administración de

Video Club

El presente documento tiene como finalidad

comunicar las necesidades y expectativas del
cliente y obtener el acuerdo entre los
representantes del cliente y el personal del
equipo de desarrollo
El contenido del mismo se considera de
carácter confidencial y su divulgación se
considerara un incumplimiento a las clausulas
contractuales.
Elementos de un Documento ConOps

El propósito del sistema es asistir en la gestión

de películas, socio y alquileres de películas

1 Catalogo de Películas Cliente

2 Listado de socios Cliente
3 Registro de alquileres Cliente
Sistema Actual
NA

El video club no cuenta con un sistema

informático para su administración, y éxito del
negocio hace necesaria la instalación del un
sistema para facilitar la gestión del mismo.

Agregar, eliminar y modificar películas para

alquilar (esencial)
Agregar, eliminar y modificar información de
los socios (esencial)
Registrar el Alquiler de una película a un socio
(esencial)
Sistema Propuesto El objetivo del VCAdmin, es llevar la gestión de
las películas socio y alquileres del video club.

El sistema tendrá tres niveles de usuarios

El sistema se podrá ejecutar al mismo tiempo en
tres equipos conectados en red con acceso al
servidor de datos.
Los equipos en los que se ejecutaran el sistema es
una computadora con sistema operativo Windows
XP o superior.
La información almacenada será guardada en
una base de datos SQL Server cuya licencia de
uso es responsabilidad del cliente

El sistema permitirá realizar el registro,

modificación de los datos del socio, el registro
modificación de los datos de las películas, las
eliminaciones lógicas de los socios y las películas
en el caso que posean alquileres, las eliminaciones
físicas en el caso que no posean alquileres,
registrar el alquiler de una película por un socio, y
de ser necesario anular un alquiler. Además el
sistema emitirá por pantalla y opcionalmente por
impresora los listados de películas activas, socios
activos, películas alquiladas, socios que adeudan
películas.
Sistema Propuesto
Tipo de usuario Administrador
Responsabilidad Acceso total
Formación Uso de PC
Actividades Registro de películas, registro de socios, alquiler
de películas
Interacción con el Todas las funciones
sistema

El sistema será instalado en tres equipos, por de la empresa

desarrolladora. Luego de la finalización del periodo de
garantía, el cliente podrá contrata un abono de
mantenimiento mensual o llamar al soporte técnico cuando
lo considere necesario

En el futuro los socios podrán consultar y reservar las

películas a través de un sitio web

El sistema provee la administración de las cuentas corrientes

de los socios, pero no serán incluidas en esta etapa del
proyecto
Especificación de requerimientos
Descripción del sistema
Sistema ConOps
Ámbitos
Requerimientos del software
Software
SRS

Descripción del sistema

• Documento, también denominado ConOps y normalizado en el estándar IEEE Std. 1362-
1998.
• Documento dirigido a los usuarios, que describe las características de un sistema propuesto,
desde el punto de vista del usuario. La Descripción del Sistema es el medio de comunicación
que recoge la visión general, cualitativa y cuantitativa de las características del sistema;
compartido por la parte cliente y desarrolladora.
Requerimientos del Software
• Documento, también denominado SRS (ERS)y normalizado en el estándar IEEE Std. 830-
1998.
• Un documento SRS es la especificación de las funciones que realiza un determinado producto
de software, programa o conjunto de programas en un determinado entorno. El documento
de especificación de requisitos puede desarrollarlo personal representativo de la parte
desarrolladora, o de la parte cliente; si bien es aconsejable la intervención de ambas partes
Requerimientos del Software IEEE-830

SRS – IEEE 830

• Un documento SRS es la especificación de las funciones que realiza un determinado producto
de software, programa o conjunto de programas en un determinado entorno.
• El documento de especificación de requisitos puede desarrollarlo personal representativo de
la parte desarrolladora, o de la parte cliente; si bien es aconsejable la intervención de
ambas partes.
• Las especificaciones de requisitos de software deben evitar incluir requisitos de diseño o de
proyecto.

Los aspectos básicos que una descripción de requisitos debe cubrir son:
• Funcionalidad. Descripción de lo que el software debe hacer.
• Interfaces externos. Cómo debe interactuar el software con las personas, el sistema de
hardware, o con otros sistemas (software y hardware).
• Rendimiento. Indicación de la velocidad, disponibilidad, tiempos de respuesta, tiempos de
recuperación, tiempos de determinadas funciones.
• Atributos. Consideraciones de portabilidad, corrección, mantenibilidad, seguridad, etc.
• Restricciones de diseño en la implementación. Indicación de las restricciones que puedan
afectar por la necesidad de sometimiento a estándares, lenguajes, políticas de integridad de
bases de datos, límites de recursos disponibles para el desarrollo, sistema operativo, etc.
IEEE 830
IEEE 830
Partes de un SRS
1 - Resumen - Alcance
• Brindar una colección de buenas prácticas para escribir especificaciones
de requerimientos de software (SRS). Se describen los contenidos y las
cualidades de una buena especificación de requerimientos
2 - Referencias
• Artículos en los que se basa el estándar

3 - Definiciones
• Contrato, cliente, desarrolladores, usuarios, etc.

4- Consideraciones para producir un buen SRS

• Naturaleza, Ambiente, Características, Preparación conjunta, Evolución,
Prototipación, Diseño integrado, Requerimientos integrados
4 - Consideraciones para producir un buen SRS

4.1 - Naturaleza del SRS

• El SRS es una especificación 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
4.2 - Ambiente del SRS
• El software puede contener toda la funcionalidad del proyecto o puede
ser parte de un sistema más grande. En el último caso habrá un SRS que
declarará las interfaces entre el sistema y su software desarrollado, y
pondrá que función externa y requisitos de funcionalidad tiene con el
software desarrollado.
4.3 - Características de un buen SRS
• Correcto, no ambiguo, completo , consistente, priorizable, comprobable,
modificable, trazable
4.3 Características de un buen SRS

4.3.1 - Correcto
• Un SRS es correcto si, y sólo si, cada requisito declarado se encuentra
en el software
4.3.2 - No ambiguo
• Un SRS es inequívoco si, y sólo si, cada requisito declarado tiene sólo
una interpretación.
4.3.3 - Completo
• Un SRS está completo si, y sólo si, se reconoce cualquier requisito
externo impuesto por una especificación del sistema.
4.3.4 - Consistente
• La consistencia se refiere a la consistencia interior. Si un SRS no está
de acuerdo con algún documento del nivel superior, como una
especificación de requisitos de sistema, entonces no es correcto.
4.3 Características de un buen SRS

4.3.5 - Priorización
• Un SRS es priorizado por la importancia de sus requerimientos particulares

4.3.6 - Comprobable
• Un SRS es comprobable, si y sólo si, cada requisito declarado es comprobable. Un
requisito es comprobable si, y sólo si, existe algún proceso con que una persona o
máquina puede verificar que el producto del software reúne el requisito. En
general cualquier requisito ambiguo no es comprobable

4.3.7 - Modificable
• Un SRS es modificable si, y sólo si, su estructura y estilo son tales que puede
hacerse cualquier cambio a los requisitos fácilmente, completamente y de forma
consistente mientras conserva la estructura y estilo

4.3.8 - Trazabilidad
• Claridad del origen de cada requerimiento y su trazabilidad hacia los
requerimientos futuros desarrollos. Hacia adelante y hacia atrás
4 - Consideraciones para producir un buen SRS

4.4 - Preparación conjunta del SRS

• El SRS se debe preparar en conjunto con las partes intervinientes para lograr un
buen acuerdo entre las partes
4.5 - Evolución de SRS
• El SRS debe evolucionar conjuntamente con el software, registrando los cambios, los
responsables y aceptación de los mismos.
4.6 - Prototipos
• El usos de prototipos se utiliza frecuentemente para la definición de requisitos
4.7 - Diseño incorporado en el SRS
• El SRS puede incorporar los atributo o funciones externos al sistema, en particular
las que describen el diseño para interactuar entre los subsistemas.
4.8 - 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.)
5 Partes de un SRS
5.1 Introducción (Sección 1 del SRS)
5.1.1 Propósito
• Se define el propósito del documento y se especifica a quien va dirigido el documento

5.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
5.1.3 Definiciones, siglas y abreviaciones
• Glosario

5.1.4 Referencias
• Esta subdivisión debe proporcionar una lista completa de todas las referencias de los documentos
mencionados o utilizados para escribir el SRS. Identificar cada documento por el título, número de reporte,
fecha, y publicación. También se deben especificar las fuentes de las referencias de donde se obtuvieron.
5.1.5 Visión Global - Resumen
• Describe lo que el resto del SRS contiene
• Explica cómo el SRS es organizado.
5.2 Descripción Global(Sección 2 del SRS)

 Esta sección del SRS debe describir los factores generales

que afectan el producto y sus requisitos. Esta sección no
declara los requisitos específicos. En cambio, mantiene una
mención general de esos requisitos que se definen en
detalle en Sección 3 del SRS y les hacen más fácil entender.
 Esta sección normalmente consiste en seis subdivisiones, como
sigue:
1. Perspectiva del Producto
2. Funcionalidades del Producto
3. Características de los Usuario
4. Restricciones
5. Suposiciones y dependencias
6. Evoluciones previsibles del sistema
5.2 Descripción Global(Sección 2 del SRS)

5.2.1. Perspectiva del producto

• Si el producto es independiente y totalmente autónomo, debe declararse que así
es.
• Si el SRS define un producto que es un componente de un sistema más grande
entonces esta subdivisión debe relacionar los requisitos de ese sistema más grande
a la funcionalidad del software y debe identificar las interfaces entre ese sistema
y el software.
• Un diagrama del bloque que muestra los componentes mayores del sistema más
grande, las interconexiones, y las interfaces externas pueden ser útiles.
5.2.2. Funciones del sistema
• Se debe presentar un resumen, a grandes rasgos, de las funciones del futuro
sistema. Por ejemplo, para un programa de contabilidad, este punto debe indicar
que “el sistema va a soportar el mantenimiento de cuentas, el estado de las
cuentas y va a facilitar la facturación”, sin mencionar el enorme detalle que cada
una de estas funciones requiere.
• Las funciones deberán mostrarse de forma organizada, y pueden utilizarse
gráficos, siempre y cuando dichos gráficos reflejen las relaciones entre funciones y
no el diseño del sistema.
5.2.3. Características del Usuario
• Acá se deben describir las características generales de los usuarios intencionales
del producto que incluye nivel educativo, experiencia, y la especialización técnica.
5.2 Descripción Global(Sección 2 del SRS)

5.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 requisitos de adaptación
del Sitio d) Políticas de la empresa e) Limitaciones del hardware f) Interfaces con
otras aplicaciones g) Operaciones paralelas h) Funciones de auditoría i)
Lenguaje(s) de programación. Bases de Datos. j) Protocolos de comunicación k)
Requisitos de fiabilidad l) Consideraciones acerca de la seguridad
5.2.5. Suposiciones y dependencias
• Se describen aquellos factores que, si cambian, pueden afectar a los requisitos.
• Por ejemplo, los requisitos pueden presuponer una cierta organización de ciertas
unidades de la empresa, o pueden presuponer que el sistema correrá sobre cierto
sistema operativo. Si cambian dichos detalles en la organización de la empresa, o
si cambian ciertos detalles técnicos, como el sistema operativo, puede ser necesario
revisar y cambiar los requisitos.
5.2.6 Evoluciones previsibles del sistema
• Se identifican requerimientos que serán implementados en futuras versiones
5.3 Requisitos específicos (Sección 3 del SRS)

Debe contener todos los requisitos del software a un nivel de detalle

suficiente para permitirles a los diseñadores diseñar un sistema para
satisfacer esos requisitos, y a los auditores a probar que el sistema
satisface esos requisitos.
A lo largo de esta sección, cada requisito declarado debe ser
externamente perceptible por los usuarios, operadores u otros sistemas
externos.
1. Requisitos comunes de interfaces
1. Descripción detallada de todas las entradas y salidas del sistema de
software.
2. Requisitos funcionales
1. Descripción de las funcionalidades de sistema
3. Requisitos no funcionales
1. Descripción de los requerimientos no funcionales
4. Otros requisitos
5.3.1Requisitos comunes de los interfaces

5.3.1.1Interfaces de usuario
• Describir los requisitos del interfaz de usuario para el producto. Esto puede estar
en la forma de descripciones del texto o pantallas del interfaz. Por ejemplo
posiblemente el cliente ha especificado el estilo y los colores del producto.
Describa exacto cómo el producto aparecerá a su usuario previsto.
5.3.1.2 Interfaces de hardware
• Especificar las características lógicas para cada interfaz entre el producto y los
componentes de hardware del sistema. Se incluirán características de
configuración.
5.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: Descripción del producto
software utilizado, Propósito del interfaz, Definición del interfaz: contiendo y
formato
5.3.1.4 Interfaces de comunicación
• Describir los requisitos del interfaces de comunicación si hay comunicaciones con
otros sistemas y cuales son las protocolos de comunicación.
5.3.2 Requisitos funcionales
5.3.2.1 Requisito funcional 1
• Objetivo, descripción, secuencia exacta de operaciones, respuesta a situaciones
anormales, etc.
5.3.2.2 Requisito funcional 2
• Objetivo, descripción, secuencia exacta de operaciones, respuesta a situaciones
anormales, etc.
5.3.2.3 Requisito funcional 3
• Objetivo, descripción, secuencia exacta de operaciones, respuesta a
situaciones anormales, etc.
5.3.2.4 ……
• ….
5.3.2.n Requisito funcional n
• Objetivo, descripción, secuencia exacta de operaciones, respuesta a situaciones
anormales, etc.
Serán desarrollados utilizando C.U. en un documento aparte
5.3.3 Requisitos no funcionales
5.3.3.1 Requisitos de rendimiento
• Especificación de los requisitos relacionados con la carga que se espera tenga que soportar
el sistema. Por ejemplo, el número de terminales, el número esperado de usuarios
simultáneamente conectados, número de transacciones por segundo que deberá soportar el
sistema, etc.
• Todos estos requisitos deben ser mesurables. 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 transacción”.
5.3.3.2 Seguridad
• Especificación de elementos que protegerán al software de accesos, usos y sabotajes
maliciosos, así como de modificaciones o destrucciones maliciosas o accidentales. Los requisitos
pueden especificar:
• Empleo de técnicas criptográficas, Registro de ficheros con “logs” de actividad, Asignación
de determinadas funcionalidades a determinados módulos, Restricciones de comunicación
entre determinados módulos, Comprobaciones de integridad de información crítica.
5.3.3.3 Fiabilidad
• Especificación 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.
5.3.3 Requisitos no funcionales
5.3.3.4 Disponibilidad
• Especificación de los factores de disponibilidad final exigidos al sistema.
Normalmente expresados en % de tiempo en los que el software tiene que mostrar
disponibilidad.
5.3.3.5 Mantenibilidad
• Identificación del tipo de mantenimiento necesario del sistema. Especificación de
quien debe realizar las tareas de mantenimiento, por ejemplo usuarios, o un
desarrollador. Especificación de cuando debe realizarse las tareas de
mantenimiento. Por ejemplo, generación de estadísticas de acceso semanales y
mensuales.
5.3.3.6 Portabilidad
• Especificación 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 código
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.
5.3.4 Otros Requerimientos y 5.4 Apéndice

5.3.4 Cualquier otro requisito que no encaje en

ninguna de las secciones anteriores.
• Por ejemplo:
• Requisitos culturales y políticos
• Requisitos Legales

5.4 Apéndices
• Pueden contener todo tipo de información relevante para la SRS pero
que, propiamente, no forme parte de la SRS.
• Por ejemplo:
• Casos de Uso
• Planificación de Proyecto
SRS VCAdmin
El propósito del presente documento es
presentar una descripción detallada del
sistema de administración de un video
club. Sus características, sus interfaces,
su funcionalidad y las condiciones en las
cuales operara.
El documento está dirigido a los
desarrolladores del sistema y será
consensuado y aprobado por los
representantes de video club

Se desarrollara un sistema para la

administración de las películas, socios y
alquileres de un video club denominado
“VCAdmin”
SRS VCAdmin
ABM: Alta, Baja y Modificación de registro en una
base de datos
Casos de Uso: Descripción detallada de una
funcionalidad del sistema
CU: Casos de Uso
SRS: Documento de Especificación de Requisitos
“VCAdmin: Sistema de administración de Video
Club
Referencia Titulo Autor
1 Requisitos de sistema Cátedra
VCAdmin (IEEE1362)
2 IEEE 830 SRS IEEE

En el presente documento se describen

detalladamente las funcionalidades a desarrollar
en al sistema VCAdmin.
En Principio se realiza una descripción general del
producto, incluyendo un resumen de las
funcionalidades más importante, descripción de los
usuarios, las restricciones y evolución del sistema,
entre otros. Luego se realizara la descripción
detallada de los requerimientos funcionales y no
funcionales y por ultimo en el apéndice se
anexaran los CU del sistema.
SRS VCAdmin
El sistema será independiente y autónomo,
no requiere realizar operaciones con
sistemas externos

El sistema permitirá:
Administrar socios: Se permitirá al
administrador y a los empleados de nivel II
agregar, eliminar y modificar los datos de
un socio
Administrar Películas: Se permitirá al
administrador y a los empleados de nivel II
agregar, eliminar y modificar los datos de
las películas

Tipo de
usuario Administrador
Formación Uso de PC
Actividades Registro de películas, registro de
socios, alquiler de películas, emitir
listados.
SRS VCAdmin
El sistema correrá sobre Windows XP o superior
El sistema requiere de un servidor de datos SQL
Server 2005
Se utilizara Delphi como lenguaje de
programación

El sistema funciona solamente con SQL Server

2005 pero los desarrolladores deslindan
cualquier responsabilidad sobre la instalación y
puesta a punto de motor de base de datos.
En el caso que el cliente no disponga de un SQL
Server 2005 o su licencia de uso, la
responsabilidad del los desarrolladores solo
alcanza la asistencia técnica para la adquisición
del mismo.

La información almacenada en la base de datos

a través de VCAdmin, quedara estructurada
para que en el futuro los socios puedan consultar
y reservar películas a través de la web
.

SRS VCAdmin
Número de requisito RF 01
Nombre de requisito Registro de socio
Tipo Requisito Restricción
Fuente del requisito Documento IEEE 1362 Video Club
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Número de requisito RF 02
Nombre de requisito Modificación de socio
Tipo Requisito Restricción
Fuente del requisito Documento IEEE 1362 Video Club
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Número de requisito RF 03
Nombre de requisito Eliminación lógica del socio
Tipo Requisito Restricción
Fuente del requisito Documento IEEE 1362 Video Club
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Número de requisito RF 04
Nombre de requisito Eliminación física del socio
Tipo Requisito Restricción
Fuente del requisito Documento IEEE 1362 Video Club
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional

Número de requisito RF 05
Nombre de requisito Limite en la visualización de listados
Tipo Requisito Restricción
Fuente del requisito ;Minuta de reunión Nro. 3
Prioridad del requisito Alta/Esencial Media/Deseado Baja/ Opcional
SRS VCAdmin
El sistema se deberá podes acceder con acceso
directos de teclado (F2,F3,F4, etc.) a las
principales funciones.
Cuando se visualizan los socio la interface
deberá presentar, en el sector superior en forma
de grilla los socios y al seleccionar uno en el
panel inferior los alquileres que realizo el socio.
Si se presiona enter sobre el socio, debe mostrar
en una nueva ventana los datos personales del
socio.
Cuando se visualizan las películas la interface
deberá presentar en el sector superior en forma
de grilla las películas y al seleccionar uno en el
panel inferior los detalles de la misma.

NA

Drivers necesario para conectarse con la base de

datos

NA
SRS VCAdmin

Requisitos funcionales

RF 01 Registro de socio
RF 02 Modificación de socio
RF 03 Eliminación lógica del socio
Continúa….

Seran desarrollados utilizando C.U. en un documento aparte

SRS VCAdmin
El sistema permitirá cargar un registro (socio,
película, etc) en menos de un minuto.
El 95% de las transacciones el motor de base de
datos las ejecutará en menos de un segundo.
La visualización del listado de películas por
pantalla no deberá exceder de los 30 segundos.

Los usuarios que acceden al sistema tendrán su

nombre de usuario y contraseña. La contraseña
caducara cada 30 días y no puede repetirse por un
año.
La información en la base de datos se guardará
cifrada.

El sistema garantiza menos de 10 errores por cada

1000 transacciones realizadas
SRS VCAdmin

Como se trata de un sistema local que corre

en una intranet privaba, la disponibilidad del
mismo será la que disponga el administrador
de red.

El cliente podrá contrata un abono de

mantenimiento mensual o llamar al soporte
técnico cuando lo considere necesario

NA
SRS VCAdmin
El sistema debe mantener los proceso de
trabajos definidos por el video club.

Se anexa Documento de CU