SlideShare una empresa de Scribd logo

Ieee 830

ALEX MERINO
ALEX MERINO
ALEX MERINOESTUDIANTE en NINGUNA

Ieee 830

1 de 91
Descargar para leer sin conexión
NORMA IEEE 830
PARA
ESPECIFICACIÓN DE
REQUERIMIENTOS DE
SOFTWARE
Antes de describir la
norma IEEE 830...
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.)
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?
   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
   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
Publicidad

Recomendados

IEEE 830 1998: Software Requirements Specification (Especificación de requisi...
IEEE 830 1998: Software Requirements Specification (Especificación de requisi...IEEE 830 1998: Software Requirements Specification (Especificación de requisi...
IEEE 830 1998: Software Requirements Specification (Especificación de requisi...Jesús Navarro
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosJuan Carlos Olivares Rojas
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareAdes27
 
Diccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónDiccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónYaskelly Yedra
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 CapasFani Calle
 

Más contenido relacionado

La actualidad más candente

Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitosinmacu_
 
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientosIDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientosFranklin Parrales Bravo
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosnenyta08
 
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?Software Guru
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioSergio Sanchez
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientosTensor
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosCesar Prado
 
Requerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no FuncionalesRequerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no Funcionalessullinsan
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosFranklin Parrales Bravo
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosSergio Sanchez
 
Origen del Modelo OSI y su impacto en als estructuras de redes
Origen del Modelo OSI y su impacto en als estructuras de redesOrigen del Modelo OSI y su impacto en als estructuras de redes
Origen del Modelo OSI y su impacto en als estructuras de redesKim Sorel Rush
 
Integridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosIntegridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosDrakonis11
 
Indagación de los requerimientos
Indagación de los requerimientosIndagación de los requerimientos
Indagación de los requerimientosUCATEBA
 

La actualidad más candente (20)

Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitos
 
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientosIDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
IDR Unidad 1: Introducción y proceso de Ingeniería de requerimientos
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
 
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De Negocio
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
Ingeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientosIngeniería de requisitos e ingeniería de requerimientos
Ingeniería de requisitos e ingeniería de requerimientos
 
Requerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no FuncionalesRequerimientos Funcionales y no Funcionales
Requerimientos Funcionales y no Funcionales
 
IDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientosIDR Unidad 2: Elicitación de requerimientos
IDR Unidad 2: Elicitación de requerimientos
 
Taller de Base de Datos - Unidad 7 Conectividad
Taller de Base de Datos - Unidad 7 ConectividadTaller de Base de Datos - Unidad 7 Conectividad
Taller de Base de Datos - Unidad 7 Conectividad
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 
Diagrama de Componentes
Diagrama de ComponentesDiagrama de Componentes
Diagrama de Componentes
 
Origen del Modelo OSI y su impacto en als estructuras de redes
Origen del Modelo OSI y su impacto en als estructuras de redesOrigen del Modelo OSI y su impacto en als estructuras de redes
Origen del Modelo OSI y su impacto en als estructuras de redes
 
Estándares para el Modelado de Procesos de Negocios
Estándares para el Modelado de Procesos de NegociosEstándares para el Modelado de Procesos de Negocios
Estándares para el Modelado de Procesos de Negocios
 
Integridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De DatosIntegridad Y Seguridad En Las Bases De Datos
Integridad Y Seguridad En Las Bases De Datos
 
Presentación diseño sistemas sm
Presentación diseño sistemas smPresentación diseño sistemas sm
Presentación diseño sistemas sm
 
Indagación de los requerimientos
Indagación de los requerimientosIndagación de los requerimientos
Indagación de los requerimientos
 
Formato de documentacion ieee 830
Formato de documentacion ieee 830Formato de documentacion ieee 830
Formato de documentacion ieee 830
 

Similar a Ieee 830

Similar a Ieee 830 (20)

Ieee830
Ieee830Ieee830
Ieee830
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
 
Requerimientos de Información
Requerimientos de InformaciónRequerimientos de Información
Requerimientos de Información
 
Ing1 requerimientos 3_2016
Ing1 requerimientos 3_2016Ing1 requerimientos 3_2016
Ing1 requerimientos 3_2016
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
 
Tema N° 14 Especificación de Requisitos del Software
Tema N° 14 Especificación de Requisitos del SoftwareTema N° 14 Especificación de Requisitos del Software
Tema N° 14 Especificación de Requisitos del Software
 
Unidad I Requerimientos
Unidad I RequerimientosUnidad I Requerimientos
Unidad I Requerimientos
 
Requisitos
RequisitosRequisitos
Requisitos
 
Ieee 830 srs
Ieee 830 srsIeee 830 srs
Ieee 830 srs
 
Tareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientosTareas de ingenieria de requerimientos
Tareas de ingenieria de requerimientos
 
Guide to the software engineering body of knowledge
Guide to the software engineering body of knowledgeGuide to the software engineering body of knowledge
Guide to the software engineering body of knowledge
 
Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)Tareas de ingenieria de requerimientos(1)
Tareas de ingenieria de requerimientos(1)
 
Taller en clases requisitos inge jerez, evan, catalina,lesly esleider
Taller en clases requisitos inge jerez,  evan, catalina,lesly esleiderTaller en clases requisitos inge jerez,  evan, catalina,lesly esleider
Taller en clases requisitos inge jerez, evan, catalina,lesly esleider
 
Taller requisitos
Taller  requisitos Taller  requisitos
Taller requisitos
 
Taller requisitos
Taller requisitosTaller requisitos
Taller requisitos
 
Ers
ErsErs
Ers
 
Ers
ErsErs
Ers
 
NORMA 830
NORMA 830NORMA 830
NORMA 830
 
Ers
ErsErs
Ers
 
Análisis de requerimientos
Análisis de requerimientosAnálisis de requerimientos
Análisis de requerimientos
 

Más de ALEX MERINO

Más de ALEX MERINO (10)

Trabajo investigaci n_compu_1
Trabajo investigaci n_compu_1Trabajo investigaci n_compu_1
Trabajo investigaci n_compu_1
 
I.t.s.s v04
I.t.s.s v04I.t.s.s v04
I.t.s.s v04
 
Algoritmo1
Algoritmo1Algoritmo1
Algoritmo1
 
Diagrama de flujo
Diagrama de flujoDiagrama de flujo
Diagrama de flujo
 
Diagrama de flujo
Diagrama de flujoDiagrama de flujo
Diagrama de flujo
 
Algoritmo1
Algoritmo1Algoritmo1
Algoritmo1
 
Deberes en general
Deberes en generalDeberes en general
Deberes en general
 
Conocimientos
ConocimientosConocimientos
Conocimientos
 
Internet
InternetInternet
Internet
 
Herramientas de la web
Herramientas de la webHerramientas de la web
Herramientas de la web
 

Ieee 830

  • 1. NORMA IEEE 830 PARA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE
  • 2. Antes de describir la norma IEEE 830...
  • 3. 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.)
  • 4. 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?
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. IEEE 830 Recommended Practice for Software Requirements SRS Specifications
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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)
  • 13. 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
  • 14. 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”
  • 15. 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
  • 16. 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
  • 17. 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).
  • 18. 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
  • 19. 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
  • 20. CARACTERÍSTICAS DE UN BUEN SRS  Correcto  No ambiguo  Completo  Consistente  Ordenado con base en importancia y/o estabilidad  Verificable  Modificable  Rastreable
  • 21. 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
  • 22. 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
  • 23. 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.
  • 24. 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)
  • 25. Ejemplo de uso de Notación Z RAdd 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)
  • 26. 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)
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. 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”
  • 32. 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.
  • 33. 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
  • 34. 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
  • 35. RASTREABLE (cont.)  La rastreabilidad hacia delante facilita las actividades de diseño, codificación, y modificación del software.
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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
  • 44. 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
  • 45. 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
  • 46. 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
  • 47. 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
  • 49. ( Del documento ) ( Del software ) Contenido y organización típicos de un SRS
  • 50. 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
  • 51. 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, programado res, etc.)
  • 52. 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
  • 53. 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
  • 54. 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.)
  • 55. 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
  • 56. 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
  • 57. 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.
  • 58. 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
  • 59. 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
  • 60. 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
  • 61. Ejemplo de diagrama de bloques: Sistema para Inscripciones 1.0 Estudiante Cursos Cursos Módulo para solicitados Verificar disponibles disponibilidad Archivo de Cursos cursos Carta de confirmación autorizados Detalles de curso 3.0 2.0 Módulo para Registro Módulo para Inscripción a curso Notificar Inscribir al Datos Archivo de inscripción estudiante estudiantes estudiante Basado en Laudon & Laudon. Sistemas de Información Gerencial. Prentice-Hall. México, 2002.
  • 62. Ejemplo de diagrama de bloques: Sistema para Inscripciones Este podría ser un software que estamos 3.0 requiriendo, que formaría parte del Módulo para sistema grande Notificar inscripción Basado en Laudon & Laudon. Sistemas de Información Gerencial. Prentice-Hall. México, 2002.
  • 63. 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?
  • 64. 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
  • 65. Veamos los módulos... 1.0 Estudiante Cursos Cursos Módulo para solicitados Verificar disponibles disponibilidad Archivo de Cursos cursos Carta de confirmación autorizados Detalles de curso 3.0 2.0 Módulo para Registro Módulo para Inscripción a curso Notificar Inscribir al Datos Archivo de inscripción estudiante estudiantes estudiante
  • 66. 1.0 Estudiante Cursos Cursos Módulo para solicitados Verificar disponibles disponibilidad Archivo de Cursos cursos Carta de confirmación autorizados Detalles de curso 3.0 2.0 Módulo para Registro Módulo para Inscripción a curso Notificar Inscribir al Datos Archivo de inscripción estudiante estudiantes estudiante
  • 67. Lo que hay entre los módulos... 1.0 Módulo para Verificar disponibilidad I.S. significa Cursos Interfaz de autorizados I.S. sistema I.S. 3.0 2.0 Módulo para Módulo para Notificar Inscribir Registro al inscripción estudiante Basado en Laudon & Laudon. Sistemas de Información Gerencial. Prentice-Hall. México, 2002.
  • 68. 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.)
  • 69. CONTENIDO DE UN SRS 2.1 Perspectiva del software 2.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)
  • 70. CONTENIDO DE UN SRS 2.1 Perspectiva del software 2.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
  • 71. CONTENIDO DE UN SRS 2.1 Perspectiva del software 2.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
  • 72. CONTENIDO DE UN SRS 2.1 Perspectiva del software 2.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
  • 73. CONTENIDO DE UN SRS 2.1 Perspectiva del software 2.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
  • 74. CONTENIDO DE UN SRS 2.1 Perspectiva del software 2.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
  • 75. CONTENIDO DE UN SRS 2.1 Perspectiva del software 2.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
  • 76. 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.
  • 77. 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.
  • 78. CONTENIDO DE UN SRS 2.4 Restricciones Informació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
  • 79. 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
  • 80. 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.
  • 81. 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
  • 82. 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
  • 83. 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
  • 84. 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
  • 85. 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édi cos, medicinas, etc. – Para cada objeto se define un conjunto de atributos y funcionalidades (denominadas servicios o métodos). – Usar plantilla A.4
  • 86. 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
  • 87. Organización de los requerimientos específicos (Sección 3)  Por estímulos – >>>
  • 88. Organización de los requerimientos específicos (Sección 3)  Por respuestas – >>>
  • 89. 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