ING II 2010 Clase 2 Requerimientos

INGENIERÍA DE SOFTWARE II

Requerimientos

Requerimientos

2

Especificación Análisis

DefiniciónSolicitud

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

REQUISITOS

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

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.

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

• 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

Ámbitos

Sistema

Software


ConOps

Requerimientos del software

SRS

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.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.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.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.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

1 Catalogo de Películas Cliente

2 Listado de socios Cliente

3 Registro de alquileres Cliente

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

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

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

sistema

Todas las funciones

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


• 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

Ámbitos

Sistema

Software


ConOps

Requerimientos del software

SRS

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. Unrequisito 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.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.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.4 ……

• ….

5.3.2.n Requisito funcional n


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

Referencia Titulo Autor

1 Requisitos de sistema

VCAdmin (IEEE1362)Cátedra

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.

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

SRS VCAdmin

Tipo de

usuario Administrador

Formación Uso de PC

Actividades Registro de películas, registro de

socios, alquiler de películas, emitir

listados.

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

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 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


Nombre de requisito Eliminación física del socio





Nombre de requisito Limite en la visualización de listados


Fuente del requisito ;Minuta de reunión Nro. 3


.


Nombre de requisito Registro de socio





Nombre de requisito Modificación de socio




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

NA

Drivers necesario para conectarse con la base de

datos

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

Documents

ING II 2010 Clase 2 Requerimientos