ieee 830 standard 12nov2005
TRANSCRIPT
![Page 1: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/1.jpg)
NORMA IEEE 830 PARA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE
Noviembre de 2005
![Page 2: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/2.jpg)
Antes de describir la norma IEEE 830...
![Page 3: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/3.jpg)
Una vez que se ha detectado algún problema que afecte a la calidad del producto/servicio, o a la satisfacción del cliente...
conviene analizar si puede resolverse mediante algún tipo de tecnología de información y telecomunicaciones (TIT):
•Hardware•Software•Redes (LAN, MAN, WAN, VPN, web, alámbricas, inalámbricas, etc.)
![Page 4: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/4.jpg)
Cómo saber si el problema puede resolverse con TIT
¿La causa del problema está relacionada con...– almacenamiento de datos?– procesamiento de datos?– transferencia de datos?
Si el problema puede resolverse por medios más baratos sin necesidad de invertir en TIT, ¿para qué gastar en TIT?
![Page 5: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/5.jpg)
Si el problema se relaciona con almacenamiento, procesamiento o transferencia de datos, conviene definir los requerimientos específicos (necesidades) que tengamos
Al definir claramente los requerimientos que deseamos que satisfaga un software, se facilitan: – La estimación de su costo – La estimación del tiempo para diseñarlo/programarlo– La decisión sobre desarrollarlo nosotros, subcontratar
o comprar– La búsqueda de algún proveedor que pueda
programarlo/venderlo
![Page 6: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/6.jpg)
Definir los requerimientos de un software puede parecer algo sencillo, pero es común que el usuario/cliente o el desarrollador cometan errores u omisiones importantes
Muchos problemas en los proyectos de software se deben a una inadecuada especificación de requerimientos
![Page 7: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/7.jpg)
Para definir los requerimientos de un software, podemos apoyarnos en una norma que nos guía para hacer las preguntas pertinentes: IEEE 830
Esta norma le sirve tanto al usuario/cliente como al desarrollador
![Page 8: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/8.jpg)
IEEE 830Recommended Practice for
Software Requirements
SpecificationsSRS
![Page 9: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/9.jpg)
El propósito principal de esta norma es ayudarnos a elaborar un documento muy útil: el SRS
Es esencialmente una guía para redacción
![Page 10: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/10.jpg)
IEEE 830
Quién la hizo: Software Engineering Standards Committee, del IEEE Computer Society
IEEE (Institute of Electric and Electronic Engineers, en E.U.A.)
Cuándo: 1998
¿Es de uso obligatorio? NO
![Page 11: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/11.jpg)
IEEE 830 Quién la puede usar:
– Un cliente/usuario que vaya a definir requerimientos (características) de un software que necesite
– Un desarrollador (interno/externo) que haga software “a la medida” mediante proyecto
– Un desarrollador que haga software “de paquete” que se venda masivamente
![Page 12: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/12.jpg)
IEEE 830 sirve para que... Un cliente describa claramente lo que quiere
Un proveedor entienda claramente lo que el cliente quiere
Se establezcan bases para un contrato de desarrollo (o de compra-venta)
Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos)
![Page 13: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/13.jpg)
IEEE 830 sirve para que... Se tenga una base o referencia para validar o
probar el software solicitado
Se facilite el traspaso del software a otros clientes/usuarios
Se le puedan hacer mejoras (o innovaciones) a ese software
![Page 14: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/14.jpg)
CONSIDERACIONES PARA REDACTAR EL SRS
Su naturaleza Su ambiente Características deseables del documento Preparación conjunta del SRS Evolución del documento Prototipos Diseño “implícito” en el SRS Requerimientos de proyecto “implícitos”
![Page 15: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/15.jpg)
Naturaleza del SRS
El SRS es una especificación para un producto de software en particular, ya sea un sólo programa, o un conjunto de programas, que realicen ciertas funciones en un ambiente específico
A veces el usuario no sabe si necesitará un solo programa o más de uno
![Page 16: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/16.jpg)
NATURALEZA DEL SRS Frecuentemente, el usuario sólo conoce las
necesidades pero no el tipo de solución más conveniente
El SRS puede escribirse por uno o más representantes del proveedor, uno o más del cliente, o por ambos
Lo más recomendable es que haya representantes de ambas partes
El usuario/cliente puede redactar un borrador inicial y después revisarlo con el proveedor
![Page 17: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/17.jpg)
NATURALEZA DEL SRS (cont.) Funcionalidades deseadas Interfaces externas Desempeño
Atributos (seguridad, portabilidad, mantenibilidad, etc.)
Restricciones de diseño impuestas a la implementación (estándares técnicos propios o internacionales, lenguaje de progr., sistema operativo, límites de recursos, políticas internas).
![Page 18: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/18.jpg)
AMBIENTE DEL SRS
El SRS es la fuente principal para hacer el plan detallado de un proyecto de software
Un SRS puede referirse a los requerimientos deseados de todos los componentes de un sistema grande, o a componentes (módulos) individuales del mismo
![Page 19: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/19.jpg)
AMBIENTE DEL SRS
Si se hacen SRS por separado para varios módulos, tiene que mantenerse la consistencia en los documentos
Si un software necesita interactuar con otro, tienen que especificarse los requerimientos de esa interacción (interfaces), definiendo sus funcionalidades y el nivel de desempeño deseado
![Page 20: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/20.jpg)
CARACTERÍSTICAS DE UN BUEN SRS Correcto No ambiguo Completo Consistente Ordenado con base en importancia y/o
estabilidad Verificable Modificable Rastreable
![Page 21: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/21.jpg)
Correctez
El SRS es correcto si los requerimientos escritos son aquellos que el software deberá cumplir
No hay un método para saber si el SRS es correcto; lo importante es que se pida lo que realmente se necesita
![Page 22: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/22.jpg)
No ambiguo
Un SRS es no ambiguo si cada requerimiento establecido en él tiene una sóla interpretación posible, tanto por el cliente/usuario como por el desarrollador
En casos donde alguna palabra pudiera tener múltiples significados, se debe incluir su definición precisa en un glosario que se adicione al SRS. – Ejemplos: planta, obra, maestro, carga, flecha
![Page 23: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/23.jpg)
No ambiguo (cont.)
Problema: El usuario/cliente y el desarrollador generalmente tienen diferentes perfiles profesionales, y por ello describen los requerimientos en diferente forma
Problema: Las descripciones que pudieran ser más claras para el desarrollador, podrían ser difíciles de entender para el usuario, y viceversa.
![Page 24: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/24.jpg)
No ambiguo (cont.)
El lenguaje natural es inherentemente ambiguo; por ello, es conveniente que el SRS sea revisado por un tercero que no haya participado en la redacción
Se han creado lenguajes formales para especificación de requerimientos de software, que se basan en reglas matemáticas y lógicas para evitar la ambigüedad (como la Notación Z, ISO/IEC Z Standard 13568:2002)
![Page 25: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/25.jpg)
Ejemplo de uso de Notación ZRAdd Birthday
Birthday Book
name?: NAME
date?: DATE
result!: REPORT
(name? known
birthday’= birthday {name? Date?}
result!= ok) V
(name? known
birthday’ = birthday
result != already_known)
![Page 26: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/26.jpg)
No ambiguo (cont.)
Métodos de representación de requerimientos:– Basados en objetos: identificar clases de objetos
similares (alumno, empleado, producto, etc.).– Basados en procesos (compras, ventas, cobranza)– Basados en conductas (la conducta de un robot)
![Page 27: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/27.jpg)
COMPLETO El SRS es completo si incluye:
– Todos los requerimientos significativos sobre funcionalidades, desempeño, restricciones de diseño, atributos, o interfaces externas
– Las respuestas que debería dar el software a todas las posibles entradas de datos en todas las situaciones posibles (entradas aceptables o no aceptables: validación)
– Especificación de unidades de medida (si son aplicables)
– En caso de que el SRS tenga diagramas o tablas informativas, hay que darles número o identificación
![Page 28: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/28.jpg)
CONSISTENTE Los diversos requerimientos escritos tienen que
ser compatibles entre sí; no debe haber contradicciones ni conflictos entre ellos.
Para lograr la consistencia deben evitarse los siguientes conflictos:– En características especificadas de objectos del
mundo real– De lógica o de tiempo entre dos actividades– Referencia a un mismo objeto del mundo real pero
usando diferentes palabras para el mismo objeto
![Page 29: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/29.jpg)
ORDENADO POR GRADO DE IMPORTANCIA O ESTABILIDAD Cada requerimiento especificado debe tener
alguna identificación (número, letra, secuencia alfanumérica) para indicar su grado de importancia o de estabilidad
Algunos requerimientos son más importantes que otros
Al “rankearlos” se puede dar a cada requerimiento la atención que se merece
![Page 30: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/30.jpg)
ORDENADO POR GRADO DE IMPORTANCIA O ESTABILIDAD Grado de estabilidad: número de cambios que
se podrían esperar para un requerimiento, debido a eventos futuros que afecten a la organización, las responsabilidades, y las personas que usarán el software
Grado de necesidad: – Esencial– Condicional– Opcional
![Page 31: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/31.jpg)
VERIFICABLE Un requerimiento es verificable si existe algún
método rentable mediante el cual se pueda analizar si el software cumple ese requerimiento.
Ejemplo: – “La respuesta del programa deberá darse dentro de
los 20 seg posteriores a la apertura de la válvula VX389, y debe responder correctamente en el 60% de los casos”
Contraejemplo (algo no verificable):– “El programa tiene que funcionar bien”
![Page 32: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/32.jpg)
VERIFICABLE (cont.) Si no existe algún método para saber si el
software cumple o no un requerimiento, entonces ese requerimiento debe ser revisado o eliminado.
![Page 33: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/33.jpg)
MODIFICABLE
Es modificable si la estructura y estilo de redacción permiten la realización de cambios en forma fácil, completa y consistente
Para esto es recomendable:– Incluir índice, tabla de contenido y tabla de
referencias cruzadas– Cada requerimiento debe aparecer sólo una vez (la
redundancia propicia errores de inconsistencia)– Poner cada requerimiento separado de los demás
![Page 34: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/34.jpg)
RASTREABLE Cada requerimiento debe identificarse con
algún número, letra o secuencia alfanumérica Un SRS es rastreable si el origen de cada
requerimiento es claro, y si facilita el seguimiento de cada requerimiento a lo largo del proyecto de software
Dos tipos de rastreabilidad:– Hacia atrás: en cada requerimiento se menciona
explícitamente su fuente documental– Hacia delante: los documentos que se deriven del
SRS deben usar las identificaciones de requerimientos como fueron dadas en el SRS
![Page 35: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/35.jpg)
RASTREABLE (cont.) La rastreabilidad hacia delante facilita las
actividades de diseño, codificación, y modificación del software.
![Page 36: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/36.jpg)
PREPARACIÓN CONJUNTA DEL SRS
El desarrollo de un software solamente debería iniciar cuando el cliente y el proveedor estén de acuerdo acerca de lo que el software deberá hacer
![Page 37: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/37.jpg)
EVOLUCIÓN DEL SRS Un SRS puede necesitar cambios mientras el
software está en etapas de diseño o de desarrollo
Los cambios pueden estar motivados por: deficiencias, errores, omisiones o imprecisiones en el documento original
Cada requerimiento debe documentarse tan completo como sea posible, aún si pudiera necesitar cambios posteriormente
![Page 38: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/38.jpg)
EVOLUCIÓN DEL SRS
Los cambios en los requerimientos tienen que documentarse con el propósito de: identificarlos, controlarlos, rastrearlos, y reportarlos
Tanto el cliente como el proveedor deben designar a su respectivo responsable de autorizar (o rechazar) cambios en los requerimientos
![Page 39: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/39.jpg)
CREACIÓN DE PROTOTIPOS
Un prototipo es un pequeño programa parecido al software solicitado que sirve de ejemplo, muestra o modelo para que el cliente vaya especificando sus requerimientos en forma progresiva junto con el desarrollador
![Page 40: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/40.jpg)
CREACIÓN DE PROTOTIPOS
El prototipo es útil para:
– Que el cliente/usuario vea y describa más fácilmente las funcionalidades que desea
– Prever aspectos de la conducta del sistema, haciendo que el SRS sea más completo y preciso
– Reducir la cantidad de cambios durante las etapas de diseño o desarrollo
![Page 41: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/41.jpg)
CREACIÓN DE PROTOTIPOS (cont.)
Un prototipo puede ayudar al usuario a definir detalles específicos de la interfaz humana o de las funcionalidades que requiera
Puede facilitarle al desarrollador el diseño y la programación del software
![Page 42: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/42.jpg)
DISEÑO “IMPLÍCITO” EN EL SRS Aunque el SRS no constituye un documento de
diseño, implícitamente está diciéndole a los desarrolladores lo que se espera que ellos diseñen – Establece restricciones
El SRS tiene que especificar las funcionalidades que se aplicarán sobre ciertos datos para producir resultados en cierto lugar para determinados usuarios
![Page 43: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/43.jpg)
Lo que generalmente no necesita escribirse en el SRS
Cómo se deben organizar los módulos del software
Cómo se deben asignar funcionalidades específicas a cada módulo
Cómo será el flujo de datos o el control de ejecución de los módulos
Elección de estructuras de datos que se usarán dentro del código
![Page 44: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/44.jpg)
Sin embargo… Algunas situaciones especiales pueden inducir
requerimientos estrictos de diseño
Ejemplo: las restricciones de seguridad contra ataques en Internet pueden requerir que:– Algunas funcionalidades del software se localicen
en módulos (programas) separados– Sólo se permita una comunicación limitada entre
ciertos módulos– Se verifique la integridad de datos para variables
críticas
![Page 45: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/45.jpg)
Más ejemplos de restricciones en diseño
Requerimientos físicos (ej. peso en el shuttle) Requerimientos de desempeño Uso de estándares de desarrollo de software Estándares de aseguramiento de la calidad del
software Los requerimientos se establecen siempre
desde el punto de vista del usuario/cliente
![Page 46: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/46.jpg)
REQUERIMIENTOS DE PROYECTO “IMPLÍCITOS”
El SRS se enfoca en el software como producto, no en su proceso de creación
Implícitamente establece restricciones sobre la planeación y administración del proyecto correspondiente
![Page 47: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/47.jpg)
REQUERIMIENTOS DE PROYECTO “IMPLÍCITOS” (cont.) El SRS da origen a otros documentos (por
separado) relacionados con el ciclo de vida de un software– Estimación de costos (¿cómo calcularlos?)– Fechas de entrega– Reportes de avances– Métodos de desarrollo– Aseguramiento de la calidad– Criterios de validación y verificación– Procedimientos de aceptación
![Page 48: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/48.jpg)
CONTENIDO Y ORGANIZACIÓN TÍPICOS DE UN SRS
![Page 49: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/49.jpg)
Contenido y organización típicos de un SRS
( Del documento )
( Del software )
![Page 50: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/50.jpg)
CONTENIDO DE UN SRS SECCIÓN 1: INTRODUCCIÓN
– Debe incluir una descripción general del SRS, mostrando lo siguiente:
1.1 Propósito del documento
1.2 Alcance
1.3 Definiciones, acrónimos, y abreviaturas
1.4 Referencias
1.5 Descripción general del documento
![Page 51: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/51.jpg)
CONTENIDO DE UN SRS
1.1 Propósito del documento: aquí se tiene que:
Explicar para qué se usará el documento
Especificar a qué tipo de lectores está destinado (usuarios, clientes, analistas, programadores, etc.)
![Page 52: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/52.jpg)
CONTENIDO DE UN SRS
1.2 Alcance – Aquí se tiene que: Identificar por su nombre genérico (y
específico) el producto(s) de software que se estén requiriendo; por ejemplo: sistema de administración de inventario, generador de reportes, sistema manejador de bases de datos marca SúperX, etc.)
Explicar lo que el software hará, y, si fuera necesario aclararlo, también lo que no se espera que haga
![Page 53: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/53.jpg)
CONTENIDO DE UN SRS
1.2 Alcance – Aquí se tiene que: Describir para qué se aplicará el software,
incluyendo sus beneficios relevantes, objectivos, y metas
Ser consistente con las disposiciones que se hayan dado en especificaciones de mayor nivel jerárquico (si existen); por ejemplo, las de algún sistema de mayor jerarquía
![Page 54: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/54.jpg)
CONTENIDO DE UN SRS
1.3 Definiciones, acrónimos, y abreviaturas Dar las definiciones de todos los términos,
acrónimos (siglas) y abreviaturas que sean pertinentes para el adecuado entendimiento del SRS
Esta información puede ofrecerse mediante referencias a uno o más apéndices del SRS o referencias hacia otros documentos (manuales de la organización, procedimientos de aseguramiento de calidad, hojas de registro, etc.)
![Page 55: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/55.jpg)
CONTENIDO DE UN SRS
1.4 Referencias Ofrecer una lista completa de todos los
documentos a los que se haga referencia en el SRS
Identificar cada documento mediante su título, número de reporte (si es aplicable), fecha, y organización que lo publicó
Especificar las fuentes de las cuales pueden obtenerse los documentos referenciados
Esta información puede ofrecerse haciendo alusión a un apéndice o hacia otro documento
![Page 56: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/56.jpg)
CONTENIDO DE UN SRS
1.5 Descripción gral. del documento Describir lo que contienen las secciones
restantes del documento Explicar cómo está organizado
![Page 57: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/57.jpg)
CONTENIDO DE UN SRS SECCIÓN 2: DESCRIPCIÓN GRAL. DEL
SOFTWARE
Aquí no se establecen los requerimientos específicos, sino que se describe el fondo general que da lugar a los requerimientos, los cuales se definen detalladamente hasta la sección 3 del SRS; ésto los hace más fáciles de entender.
![Page 58: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/58.jpg)
CONTENIDO DE UN SRS SECCIÓN 2: DESCRIPCIÓN GRAL. DEL
SOFTWARE– Usualmente se incluyen estas 6 subsecciones:
2.1 Perspectiva del software
2.2 Funciones del software
2.3 Características del usuario
2.4 Restricciones
2.5 Suposiciones y dependencias
2.6 Posposición de requerimientos
![Page 59: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/59.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software– Describir el software en perspectiva con otros
software relacionados: similitudes y diferencias – Si el software es independiente y totalmente auto-
contenido, eso tiene que decirse aquí. – Si se está requiriendo un software que formará
parte de un sistema más grande, se tiene que describir la relación de los requerimientos del sistema grande con las funcionalidades del software requerido y debe identificarse cómo se comunicarán ambos
![Page 60: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/60.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)
– Para describir las relaciones entre el software requerido y el sistema grande, pueden ser útiles los diagramas de bloques
– En los diagramas de bloques se pueden mostrar los componentes principales del sistema grande y su relación jerárquica (y de flujo de datos) con el software requerido
![Page 61: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/61.jpg)
Ejemplo de diagrama de bloques: Sistema para Inscripciones
Estudiante Cursos solicitados
Módulo para Verificardisponibilidad
1.0
Cursos autorizados
Módulo para Inscribiralestudiante
2.03.0Módulo paraNotificarinscripción
Registro
Carta de confirmación
Archivo deestudiantes
Archivo decursos
Cursos disponibles
Datos estudiante
Inscripción a curso
Detalles de curso
Basado en Laudon & Laudon. Sistemas de Información Gerencial.Prentice-Hall. México, 2002.
![Page 62: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/62.jpg)
Ejemplo de diagrama de bloques: Sistema para Inscripciones
3.0Módulo paraNotificarinscripción
Basado en Laudon & Laudon. Sistemas de Información Gerencial.Prentice-Hall. México, 2002.
Este podría ser un software que estamos requiriendo, que formaría parte del sistema grande
![Page 63: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/63.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)– Describir las condiciones (restricciones) dentro de
las cuales deberá funcionar el software:
2.1.1 Interfaces de sistema (*)
2.1.2 Interfaces de usuario
2.1.3 Interfaces de hardware
2.1.4 Interfaces de software
2.1.5 Interfaces de comunicaciones
2.1.6 Restricciones de memoria
2.1.7 Operaciones
2.1.8 Requerimientos de adaptación a un lugar
(*) ¿Qué es una interfaz?
![Page 64: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/64.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software (cont.)
2.1.1 Interfaces de sistema: lo que hay entre los diversos módulos del sistema
– Enumerar cada interfaz de sistema– Descripción de la interfaz del software para
hacerlo compatible con el sistema
![Page 65: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/65.jpg)
Veamos los módulos...
Estudiante Cursos solicitados
Módulo para Verificardisponibilidad
1.0
Cursos autorizados
Módulo para Inscribiralestudiante
2.03.0Módulo paraNotificarinscripción
Registro
Carta de confirmación
Archivo deestudiantes
Archivo decursos
Cursos disponibles
Datos estudiante
Inscripción a curso
Detalles de curso
![Page 66: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/66.jpg)
Estudiante Cursos solicitados
Módulo para Verificardisponibilidad
1.0
Cursos autorizados
Módulo para Inscribiralestudiante
2.03.0Módulo paraNotificarinscripción
Registro
Carta de confirmación
Archivo deestudiantes
Archivo decursos
Cursos disponibles
Datos estudiante
Inscripción a curso
Detalles de curso
¿Qué hay entre los
módulos?
![Page 67: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/67.jpg)
I.S.
Lo que hay entre los módulos...
Módulo para Verificardisponibilidad
1.0
Cursos autorizados
Módulo para Inscribiralestudiante
2.03.0Módulo paraNotificarinscripción
Registro
Basado en Laudon & Laudon. Sistemas de Información Gerencial.Prentice-Hall. México, 2002.
I.S.
I.S. significa Interfaz de sistema
![Page 68: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/68.jpg)
Lo que hay entre los módulos...
• Lo que hay entre los módulos es flujo de información; por lo tanto se tiene que especificar qué información alimenta a cada uno de los módulos que sean requeridos
• Hay que especificar cómo es esa información (numérica, alfanumérica, rango de valores posibles, unidades de medida, etc.)
![Page 69: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/69.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software2.1.2 Interfaces de usuario: lo que estará entre el
usuario y el software– Definir las características de :
Ventanas Colores Formatos y tamaños de letra Menús Íconos, botones Contenido de los reportes impresos Interfaz mediante A.S.R. y/o síntesis de voz Realidad virtual Otras interfaces usuario/máquina (electrodos)
![Page 70: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/70.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software2.1.3 Interfaces de hardware: qué hardware usará el
software para entrada/salida de información, incluyendo:
Características de configuración (número de puertos de comunicación, instruction sets, etc.).
Qué dispositivos de hardware serán soportados por el software,y én qué forma serán soportados
Protocolos de transferencia de datos entre dispositivos
Ejemplo: un sistema para administración de inventarios puede requerir el uso de scanners especiales para leer códigos de barras
![Page 71: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/71.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software2.1.4 Interfaces de software: qué otros software se
necesitarán para que el software requerido pueda funcionar, por ejemplo:
Sistemas operativos: Windows, Linux, AIX, Solaris, etc. Sistemas manejadores de bases de datos: Oracle, Sybase,
MySQL, DB2, etc. Intérpretes de lenguajes (como PERL) Shells para sistemas expertos (como Sictus Prolog) Paquetes comerciales para ejecutar programas que usan
redes neuronales (como MatLab)
También los programas para que el software pueda interactuar con los demás módulos
![Page 72: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/72.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software2.1.5 Interfaces de comunicación:
Qué tecnología de redes se usará para comunicar a las computadoras en las cuales se usará el software:
– Nombre genérico de la tecnología: LAN, WAN, MAN, VPN, WWW, WiFi, etc.
– Topología de la red: anillo, estrella, bus– Protocolos de comunicación: Ethernet, TCP/IP, ATM,
FrameRelay, PPP– Tipo de cableado: fibra óptica, par trenzado, coaxial
![Page 73: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/73.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software2.1.6 Restricciones de memoria
Se debe especificar si existe o no algún límite en cuanto a la memoria (tanto primaria como secundaria) que podrá tener disponible el software para ser ejecutado
Memoria primaria: la RAM (Random Access Memory)
Memoria secundaria: disco, cinta
![Page 74: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/74.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software2.1.7 Operaciones
Especificar los diferentes modos de operación del software por parte del usuario, por ejemplo:
– Operaciones “normales” versus especiales (inscribir alumno versus respaldo de archivos)
– Operaciones interactivas y actividades que no requieran atención del usuario
– Operaciones iniciadas por el usuario versus operaciones que se activen automáticamente
![Page 75: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/75.jpg)
CONTENIDO DE UN SRS
2.1 Perspectiva del software2.1.8 Adaptación a un lugar específico
– Definir los requerimientos respecto a datos o secuencias de inicialización del software que sean específicas para un lugar, una misión o un modo operacional específico
– Especificar las características relacionadas con el lugar o la misión que deban ser modificadas para adaptar el software a una instalación específica
![Page 76: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/76.jpg)
CONTENIDO DE UN SRS
2.2 Funciones del producto
Sumario de las funciones principales; por ejemplo, para el caso de un software de contabilidad se mencionría el mantenimiento de cuentas de cliente, el registro de sus transacciones, la preparación de facturas, pero sin mencionar los detalles requeridos de esas funciones.
![Page 77: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/77.jpg)
CONTENIDO DE UN SRS
2.3 Características de los usuarios
Describir sus características respecto a: Nivel educativo Experiencia profesional Capacidades técnicas.
Esta descripción ayuda a comprender los motivos que dan origen a los requerimientos.
![Page 78: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/78.jpg)
CONTENIDO DE UN SRS
2.4 RestriccionesInformación sobre posibles limitantes que
deberán respetar los diseñadores, como:
a) Políticas regulatorias aplicables
b) Limitaciones en el hardware (p.ej. velocidad del microprocesador)
c) Interfaces hacia otras aplicaciones
d) Funcionamiento en paralelo
e) Funciones de auditoría de software
![Page 79: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/79.jpg)
CONTENIDO DE UN SRS
2.4 Restricciones (cont.)
f) Protocolos de comunicaciones de redes
g) Requiremientos de confiabilidad
h) Criticidad de la aplicación
i) Consideraciones sobre seguridad física y lógica
![Page 80: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/80.jpg)
CONTENIDO DE UN SRS
2.5 Suposiciones y dependencias
Cada uno de los factores que afecten a los requiremientos especificados.
Estos factores no son restricciones de diseño para el software, sino >>>>>>but are, rather, any changes to them that can affect
the requirements in the SRS. For example, an assumption may be that a speciÞc operating system will be
available on the hardware designated for the software product. If, in fact, the operating system is not avail-
able, the SRS would then have to change accordingly.
![Page 81: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/81.jpg)
CONTENIDO DE UN SRS
2.6 Distribución (apportioning) de requerimientos
Aquí se dice cuáles son los requerimientos que pueden atenderse hasta versiones futuras del sistema
![Page 82: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/82.jpg)
Organización de los requerimientos específicos (Sección 3)Para lograr un mejor entendimiento de los
requerimientos, conviene organizarlos con base en alguno de los siguientes criterios:
Por modo de operación del sistema Por clase de usuario Por objetos Por características Por estímulos Por respuestas Por jerarquía funcional
![Page 83: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/83.jpg)
Organización de los requerimientos específicos (Sección 3) Por modo de operación del sistema
– P. ej. si se desea un sistema de control para una planta industrial, sus modos de operación podrían ser: modo de entrenamiento, modo normal, y modo de emergencia
– Hay que definir las funcionalidades del sistema para cada tipo de modo
– Usar las plantillas A.1 o A.2, la primera si los diversos modos de operación requieren diferentes interfaces; la segunda si requieren diferentes tipos de desempeño
![Page 84: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/84.jpg)
Organización de los requerimientos específicos (Sección 3)
Por clase de usuario
– Algunos sistemas ofrecen diferentes conjuntos de funciones para cada tipo de usuario. P. ej., un sistema de sucursal bancaria ofrece diferentes funciones para el personal de cajas, para los ejecutivos de cuenta o para el gerente
– Usar plantilla A.3
![Page 85: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/85.jpg)
Organización de los requerimientos específicos (Sección 3) Por objetos
– “Objetos” son entidades del mundo real que tienen una representación dentro del sistema. P. ej. un sistema de monitoreo de pacientes incluye pacientes, sensores, enfermeras, habitaciones, médicos, medicinas, etc.
– Para cada objeto se define un conjunto de atributos y funcionalidades (denominadas servicios o métodos).
– Usar plantilla A.4
![Page 86: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/86.jpg)
Organización de los requerimientos específicos (Sección 3)
Por características– Una característica es una funcionalidad del sistema
que puede requerir una secuencia de entradas de datos para producir un resultado o una acción
– Ej. en la programación de los circuitos de un aparato telefónico, las características son: llamada local, transferencia de llamada, y llamada en conferencia (conference call)
– Cada característica se describe generalmente como una secuencia de pares de estímulo-respuesta
– Usar plantilla A.5
![Page 87: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/87.jpg)
Organización de los requerimientos específicos (Sección 3)
Por estímulos– >>>
![Page 88: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/88.jpg)
Organización de los requerimientos específicos (Sección 3)
Por respuestas– >>>
![Page 89: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/89.jpg)
Organización de los requerimientos específicos (Sección 3) Por jerarquía funcional
– Cuando ninguna de las plantillas resulta útil, la funcionalidad general del sistema puede organizarse en una jerarquía de funciones, ya sea con base en entradas comunes, salidas comunes, o accesos comunes a los datos
– Se pueden usar diagramas de flujo de datos y diccionarios de datos para mostrar las relaciones entre las diversas funciones, entre los diversos datos, y entre las funciones y los datos
– Usar plantilla A.7
![Page 90: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/90.jpg)
![Page 91: Ieee 830 Standard 12nov2005](https://reader034.vdocuments.co/reader034/viewer/2022042512/557213df497959fc0b9339c8/html5/thumbnails/91.jpg)
¿Preguntas o comentarios?