Flores 1

Victor Flores Ros A01213040 Leopoldo Len Vzquez A01213222 Juana Julieta Noguez Monroy 20 de Septiembre de 2012 830 Software Requirements Specification IEEE

Propsito. En esta seccin se deber Delinear el propsito de la SRS y especificar a que publico intencional va dirigido el SRS. Se debe aclarar cual es el objetivo principal de este proyecto.

Alcance. En esta subseccin se debe: Identificar el producto de software(s) que se produce por su nombre (por ejemplo, Host DBMS, generador de reportes, etc); Aclarar que es el producto, que har y que no har Describir el uso del software que se especifique, incluidos los beneficios, objetivos, y metas. Sea consistente con las declaraciones similares en las especificaciones de nivel superior, si es que existen.

Definiciones, siglas y abreviaciones. Esta seccin provee las definiciones de todos los trminos, acrnimos y abreviaturas requeridas para interpretar apropiadamente el SRS. Esta informacin puede ser proporcionada por referencia a uno o ms apndices en el SRS o por referencia a otros documentos. Referencias. Lista completa de todas las referencias de los documentos en otra parte en el SRS Identificar cada documento por ttulo, # de reporte, fecha y publicacin de la organizacin Especificar las fuentes de las referencias de donde se obtuvieron

Flores 2

Apreciacin global

Describir lo que el resto del SRS contiene Explicar como esta organizado el SRS

Seccin 2 Se describen los factores generales que afectan al producto y sus requisitos, no se declaran requisitos especficos. En su lugar, proporciona un fondo para los requisitos que se definen en detalle en la Seccin 3 del SRS

Perspectiva del producto Esta subdivisin del SRS debe poner el producto en perspectiva con otros productos relacionados. Si el producto es independiente y totalmente autnomo, que debe indicarse aqu. Si el SRS define un producto que es un componente de un sistema ms grande, como frecuentemente ocurre, entonces esta subdivisin debe relacionar los requisitos de sistema mayor que a la funcionalidad del software y debe identificar las interfaces entre este sistema y el software. Un diagrama de bloques que muestra los componentes principales del sistema ms grande, interconexiones, y caras externas puede ser til. Esta seccin tambin debe describir cmo funciona el software en el interior de diversas limitaciones. Por ejemplo, estas limitaciones pueden incluir: Las interfaces del sistema las interfaces de usuario las interfaces de hardware las interfaces de software las interfaces de comunicacin la memoria, operaciones los requisitos de adaptacin

Funciones del producto Esta subdivisin del SRS debe proporcionar un resumen de las principales funciones que el software va a realizar. A veces la funcin de resumen que es necesario para esta parte puede ser tomado directamente de la seccin de la especificacin de alto nivel (si existe) que asigna a funciones particulares del producto de software. 1

Flores 3

Las funciones deben organizarse de una manera que hace que la lista de funciones sea comprensible para el cliente o para cualquier otra persona al leer el documento por primera vez. Mtodos textuales o grficos se puede utilizar para mostrar las diferentes funciones y sus relaciones. Tal diagrama no est destinada a mostrar un diseo de un producto, sino que simplemente muestra la relacin lgica entre las variables.

Caractersticas del usuario. Describe las caractersticas generales de los usuarios previstos del producto nivel de educacin experiencia especializacin tcnica

Restricciones. Esta subdivisin del SRS debe proporcionar una descripcin general de todas las otras cosas que limitarn las opciones. Estos incluyen: Las polticas reguladoras: las limitaciones del hardware (por ejemplo, requisitos de la seal de sincronizacin) Interfaces a otras aplicaciones el funcionamiento en paralelo las funciones de auditora Funciones de control de orden superior los requisitos lingsticos de la seal protocolos de intercambio de protocolos (por ejemplo, XONXOFF, ACK-NACK) los requisitos de fiabilidad criticidad de la aplicacin la seguridad y consideraciones de seguridad.

Atenciones y dependencias Se debe listar cada uno de los factores que afectan los requisitos declarados en el SRS. Estos factores no son las restricciones del diseo en el software, ms bien son cualquier cambio a ellos, pudiendo afectar los requisitos en el SRS Prorratear los requisitos Se debe identificar los requisitos que puedan demorarse hasta las versiones futuras de los sistemas.

Flores 4

Seccin 3 Requisitos especficos (Seccin 3 del SRS) Esta seccin del SRS debe contener todos los requisitos del software a un nivel de detalle suficiente para permitirles a los diseadores disear un sistema para satisfacer esos requisitos, y a los auditores a probar que el sistema satisface esos requisitos. Estos requisitos deben incluir por lo menos una descripcin de cada entrada (el estmulo) en el sistema, cada salida (la contestacin) del sistema, y todas las funciones realizadas por el sistema en la salida a una entrada o en el apoyo de la salida. Esta es la parte ms grande y ms importante del SRS, los principios siguientes aplican: Los requisitos especficos deben tener referencias cruzadas a documentos ms actuales que los relacionan. Todos los requisitos deben ser singularmente identificables. Debe prestarse la atencin debida a organizar los requisitos para aumentar al mximo la legibilidad.

Interfaces externas sta debe ser una descripcin detallada de todas las entradas y salidas del sistema del software. Debe incluir ambas entradas/salidas y debe estructurarse como sigue: el nombre de artculo; la descripcin de propsito; la fuente de entrada o destino de salida; el rango vlido, exactitud, y/o tolerancia; las unidades de medida; tiempos; las relaciones a otras entradas/salidas; el formato de pantalla /organizacin; el formato de ventanas/organizacin; los formatos de los datos; los formatos de los comandos; fin de mensajes.

Funciones Los requisitos funcionales deben definir las acciones fundamentales que deben tener lugar en el software, aceptando y procesando las entradas, procesando y generando las salidas. stos generalmente se listan como "debe" declaraciones que empiezan con "El sistema debe."

Flores 5

stos incluyen: verificar la validez sobre las entradas la secuencia exacta de las operaciones las contestaciones a las situaciones anormales, incluyendo o overflow o facilidades de comunicacin o manejo de errores y recuperacin El efecto de parmetros e) la relacin de salidas a las entradas, incluyendo o las secuencias de entrada/salidas o las frmulas de entrada y su conversin a la salida

Puede ser apropiado dividir los requisitos funcionales en subprocesos. Requisitos del desarrollo. Esta subdivisin debe especificar los requerimientos estticos y dinmicos que se pusieron en el software o en la interaccin humana con el software en conjunto. El nmero de terminales a ser apoyadas; El nmero de usuarios simultneos ser apoyados; La cantidad y tipo de informacin que se manejara.

A veces se identifican los requisitos estticos bajo una seccin separada titulada la Capacidad Requisitos del banco de datos lgicos Esto debe especificar los requisitos lgicos para cualquier informacin que ser puesta en un banco de datos. Los tipos de informacin usadas por varias funciones; la frecuencia de uso; accediendo las capacidades; las entidades de los datos y sus relaciones; las restricciones de integridad; requerimientos en la retencin de datos.

Restricciones del diseo. Esto debe especificar las restricciones del diseo que pueden imponerse por otros estndares, las limitaciones del hardware, etc.,

Flores 6

Aceptacin de las normas Esta subdivisin debe especificar los requisitos derivados de estndares existentes o regulaciones. el formato del reporte; los nombres de los datos; los procedimientos de contabilidad; los lineamientos de la Auditora. Atributos del software del sistema. Hay varios atributos del software que puede servir como los requisitos. Es importante que los atributos se especifiquen para que su logro pueda verificarse objetivamente. Fiabilidad Esto debe especificar que los factores exigieron establecer la fiabilidad requerida del sistema del software al momento de la entrega. Disponibilidad Esto debe especificar que los factores exigieron garantizar un nivel de disponibilidad definido para el sistema como un punto de control, la recuperacin y al iniciar. Seguridad Esto debe especificar los factores que protegen el software del acceso accidental o malvolo, uso, modificacin, destruccin o descubrimiento. Utilice ciertas tcnicas de encriptamiento; Tenga Log de entrada o histricos de datos; Asigne ciertas funciones a mdulos diferentes; Restrinja las comunicaciones entre algunas reas del programa; La integridad de datos se verifique para variables crticas. Mantenimiento Esto debe especificar atributos de software que relaciona a la facilidad de mantenimiento del propio software. Puede haber algn requisito con toda seguridad de modularidad, interfaces, la complejidad, etc. no deben ponerse los requisitos aqu. Portabilidad Esto debe especificar atributos de software que relaciona a la facilidad de poner el software a otro servidor y/o sistemas operativos.

Flores 7

el Porcentaje de componentes con cdigo cliente-servidor; el Porcentaje de cdigo del cliente-servidor; el Uso de un idioma porttil probado; el Uso de un compilador particular o subconjunto de lenguajes; el Uso de un sistema operativo particular.

Organizar los requisitos especficos. Por algo los requisitos detallados de los sistemas triviales tienden a ser extenso. Por esta razn, se recomienda que sean cuidadosos de organizar stos de una manera ptima para que sean entendibles. Modo del sistema Algunos sistemas se comportan diferentes dependiendo del modo de operacin. Dependiendo de ste modelo es como se utilizar. Clases de usuario Algunos sistemas proporcionan juegos diferentes de funciones a las clases diferentes de usuarios. Por ejemplo, un sistema de mando de ascensor presenta las capacidades diferentes a los pasajeros, obreros de mantenimiento y bomberos. Al organizar esta seccin por la clase del usuario, el contorno en A.3 debe usarse. Objetos Los objetos son entidades del mundo real que tienen una contraparte dentro del sistema. Al poner los objetos puede compartir atributos y servicios. stos se agrupan como las clases. Rasgo Un rasgo es un servicio externamente deseado por el sistema que puede exigir a una secuencia de entradas efectuar el resultado deseado. Cada rasgo generalmente se describe en una secuencia de estmulo contestacin. Estmulo Algunos sistemas pueden organizarse mejor describiendo sus funciones por lo que se refiere a los estmulos. Contestacin Algunos sistemas pueden organizarse mejor describiendo todas las funciones en el apoyo de la generacin de una contestacin. Jerarqua Funcional

Flores 8

Cuando ninguno de los esquemas orgnicos anteriores demuestra ser til, la funcionalidad global puede organizarse en una jerarqua de funciones organizada por cualesquier entradas comunes, rendimientos comunes o el acceso de los datos interiores comn. Los datos fluyen pueden usarse diagramas y diccionarios de datos para mostrar las relaciones entre las funciones y datos. Comentarios adicionales Hay muchas anotaciones, mtodos y herramientas de apoyo automatizadas disponibles para ayudar en la documentacin de requisitos. La mayor parte, su utilidad es una funcin de organizacin. Por ejemplo, al organizar por el modo, mquinas de estado finitas o los mapas estatales pueden demostrar utilidad; al organizar por el objeto, el anlisis objeto-orientado puede demostrar utilidad; al organizar por el rasgo, las secuencias de estmulo-contestacin pueden demostrar utilidad y al organizar por la jerarqua funcional, los datos fluyen segn los diagramas y los diccionarios de datos pueden demostrar tambin utilidad. Comentario: Es importante la claridad con la que se exponen las partes y requisitos necesarios para una SRS. Como en cualquier trabajo, el cliente juega un papel fundamental para el xito de un proyecto, y es importante que se nos ensee a cmo ser ms claros con nuestros clientes, lo que mejorar la comunicacin, el entendimiento del software y reduccin de errores. Tambin es importante como un gran organizador para los mismos desarrolladores del software. Es importante de igual manera el cmo ser la relacin con la persona que interacte con el sistema de software. Se hace un nfasis importante en la legibilidad de nuestros diseos, programas, prototipos, esquemas, cdigo e inclusive explicaciones y comunicacin con el cliente; como ya se mencion todo esto es fundamental para el xito del proyecto Obras Consultadas 12 Copyright 1998 IEEE. Todos los derechos reservados. Autorizado con licencia limitada para usar: Tec de Monterrey. Consultado el septiembre 17,2012 en 16:49:11 UTC de IEEE Xplore. Se aplican restricciones.