Requerimientos
•Als PPS, PDF herunterladen•
1 gefällt mir•3,265 views
Este documento trata sobre la ingeniería de requerimientos. Explica que la especificación de requerimientos es una actividad clave en el desarrollo de software para comprender correctamente las necesidades de los usuarios. Se describen diferentes tipos de requerimientos como los funcionales, no funcionales, volátiles y duraderos. También se explica la importancia de la elicitud de requerimientos y la validación de los mismos.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Requerimientos
Ähnlich wie Requerimientos (20)
Mehr von Secretaría de Estado de Educación
Mehr von Secretaría de Estado de Educación (20)
Requerimientos
- 1. Universidad Tecnológica de Santiago Recinto Dajabón Cátedra de Análisis de Sistemas Especificación de los Requerimientos de los Usuarios J udith M eles 1 Ingeniería de Requerimientos
- 2. El Problema de los Requerimientos 1) Lo que el usuario necesita J udith M eles 2) Lo que el usuario cree necesitar 2 3) Lo que le transm al itió profesional Ingeniería de Requerimientos
- 3. EP l roblema de los Requerimientos 4) Lo que el profesional entendió 5) Lo que se entregó al principio 6) Lo que al final resultó J udith M eles 3 Ingeniería de Requerimientos
- 4. Introducción La efectividad yflexibilidad de un sistem está a extrecham ente relacionada a la correcta com prensión de las necesidades de los clientes y o usuarios del sistem hayun com / a, ponente clave en todo proceso de desarrollo , que juega un papel central, llam ado.... ESP ECIFICACIÓN DE R EQUERIMIENTOS J udith M eles 4 Ingeniería de Requerimientos
- 5. ¿ Qué es un Requerimiento? ( Definición IEEE-Std-610 - 1990) Condición o capacidad que necesita el usuario para resolver un problema o alcanzar un objetivo. Condición o capacidad que debe satisfacer o poseer un sistema o un componente de un sistema para satisfacer un contrato, un standard, una especificación u otro documento formalmente impuesto. Representación documentada de una condición o capacidad como las expresadas anteriormente. J udith M eles 5 Ingeniería de Requerimientos
- 6. Requerimientos: Categorías E general, caen en dos grandes categorías: n orientado al mercado específico para un cliente J udith M eles 6 Ingeniería de Requerimientos
- 7. Requerimientos Orientados al M ercado B ocetados e informales T écnicas más de manufactura que de Ingeniería de Software E specificación en forma de presentación comercial “Cliente” no fácilmente identificable Se basan en Consultores para aspectos deseables E nfoque poco estructurado. J udith M eles 7 Ingeniería de Requerimientos
- 8. Requerimientos E specíficos para un cliente Voluminosos y más “formales” Uso de técnicas de Ingeniería de Software L argas especificaciones Uso del conocimiento del dominio P royectos basados en personal propio M étodo estructurado siguiendo un enfoque particular J udith M eles 8 Ingeniería de Requerimientos
- 9. Requerimientos: Una P erspectiva Organizacional L contribución de los SI a las organizaciones a Automatizar reduciendo costos de proceso Informar a los tomadores de decisiones T ransformar la organización P rerequisitos Visión del negocio y la organización Alineación de los SI con la estrategia corporativa E desarrollo de los SI tiene que ver con: l Necesidades de los involucrados Requerimientos del usuario y estrategia de negocios J udith M eles 9 Ingeniería de Requerimientos
- 10. De la automatización de la rutina a los procesos críticos L especificación de requerimientos debe atender a: a mejorar la gestión del cambio integrar visiones dentro de la empresa vincular la estrategia empresaria con los SI E como camino para gerenciar el cambio: R J udith M eles comprensión conceptual del status actual definición del cambio implementación del cambio integración de esta nueva implementación 10 Ingeniería de Requerimientos
- 11. Requerimientos: Una P erspectiva del Software L errores en la definición de requerimientos resulta os en un mantenimiento costo de los sistemas de software. Surge la Ingeniería de Requerimientos como un subcampo de la Ingeniería de Software J udith M eles 11 Ingeniería de Requerimientos
- 12. Importancia de los requerimientos Premisa H acer un mejor trabajo definiendo y especificando software no sólo vale la pena sino que tambien es posible y ventajoso en costo Soporte: Cuanto más tarde en el ciclo de vida se detecta un error, más cuesta repararlo M uchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieron L errores de requerimientos son comúnmente: hechos, os incorrectos, omisiones, inconsistencias y ambigüedades L errores en los requerimientos pueden detectarse os J udith M eles 12 Ingeniería de Requerimientos
- 13. Catarata de E rrores de M izuno PROBLEMA REAL Especificación de Requerimientos Diseño Implementación Testing J udith M eles especificación correcta diseño Diseño correcto correcto programas correctos funciones correctas especificación incorrecta diseño basado en especificación incorrecta diseño incorrecto errores de programación programas basados en diseño incorrecto Errores errores corregibles corregibles 13 programas basados especificación incorrecta errores no corregibles errores ocultos Ingeniería de Requerimientos
- 14. Impacto de los errores en la etapa de requerimientos E software resultante puede no satisfacer a los l usuarios L interpretaciones múltiples de los requerimientos as pueden causar desacuerdos entre clientes y desarrolladores E imposible que a través del testeo el software s satisfaga sus requerimientos P uede gastarse tiempo y dinero construyendo el sistema erróneo J udith M eles 14 Ingeniería de Requerimientos
- 15. E volución de Requerimientos Comprensión Comprensión inicial del inicial del problema problema Cambios en la Cambios en la comprensión del comprensión del problema problema Requerimientos Requerimientos Cambiados Cambiados Requerimientos Requerimientos iniciales iniciales Tiempo J udith M eles 15 Ingeniería de Requerimientos
- 16. Clases de Requerimientos Requerimientos Durables: son relativamente estables, derivan de las actividades centrales del negocio, los cuales se relacionan directamente con el dominio del sistema. Requerimientos Volátiles: son aquellos que tienen probabilidad de cambiar durante el desarrollo del sistema o después que el sistema se haya puesto en producción. J udith M eles 16 Ingeniería de Requerimientos
- 17. Clasificación de Requerimientos Volátiles M utables: los requerimientos cambian debido al entorno en el cual la organización opera. E mergentes: surgen con la comprensión de los clientes del sistema, durante su desarrollo. E diseño puede relevar nuevos l requerimientos. Consecuentes: resultan de la introducción del sistema de computación, cambiando los procesos del negocio y abriendo nuevas formas de trabajo que generan nuevos requerimientos De Compatibilidad: dependen de un sistema o proceso en particular dentro del negocio, si cambian, los requerimientos relacionados deberán cambiar. J udith M eles 17 Ingeniería de Requerimientos
- 18. E specificación de Requerimientos L documentación de R a equerimientos para la construcción de Software es la actividad que tradicionalmente se ha llamado E specificación de Requerimientos. L E a specificación de R equerimientos representa ambos: un modelo de lo que se necesita y una definición del problema bajo consideración. J udith M eles 18 Ingeniería de Requerimientos
- 19. E specificación de Requerimientos Razones para esforzarse en su desarrollo.... F ocaliza el proceso comunicacional en la comprensión a cerca del dominio, el negocio y el sistema propuesto. P uede ser parte de un arreglo contractual. P uede usarse para la evaluación del producto final, y tener un rol crucial en las pruebas de aceptación del sistema. J udith M eles 19 Ingeniería de Requerimientos
- 20. E specificación de Requerimientos Una nueva visión para su desarrollo... Requerimientos E mpresariales Requerimientos F uncionales E specificación de Requerimientos Requerimientos No F uncionales E valuación J udith M eles 20 Ingeniería de Requerimientos
- 21. Requerimientos F uncionales Relacionados con la descripción del comportamiento fundamental de los componentes del software. L funciones son especificadas en términos de as entradas, procesos y salidas. Una vista dinámica podría considerar aspectos como el control, el tiempo de las funciones (de comienzo a fin) y su comportamiento en situaciones excepcionales. J udith M eles 21 Ingeniería de Requerimientos
- 22. Requerimientos No F uncionales Juegan un papel crucial en el diseño y desarrollo del sistema de información. Pueden definirse como consideraciones o restricciones asociadas a un servicio del sistema. Suele llamarse también requerimientos de calidad o no comportamentales en contraste con los comportamentales. Pueden ser tan críticos con los funcionales. J udith M eles 22 Ingeniería de Requerimientos
- 23. Dificultades asociadas a los Requerimientos No F uncionales No hay reglas ni lineamientos para determinar cuando se obtuvo una solución óptima. T iene buenas y malas soluciones, no soluciones correctas e incorrectas P roblemas relacionados con requerimientos no funcionales pueden ser síntomas de problemas mayores. H dos atributos que deben poseer: deben ser ay objetivos y testeables. J udith M eles 23 Ingeniería de Requerimientos
- 24. Requerimientos No F uncionales: T ipos Non-functional Requerimientos No Funcionales requir ements Product Requerimientos del Producto requir ements Ef ficiency Requerimientos de requir ements Eficiencia Reliability Requerimientos de Confiabilidad requir ements Usability Requerimientos de requirements Usabilidad Performance Requerimientos Derequirements Performance J udith M eles Or ganizational Requerimientos Organizacionales requir ements Portability Requerimientos de requirements Portabilidad Delivery Requerimientos de Entrega requirements External Requerimientos Externos requirements Interoperability Requerimientos Interoperatibidad requirements Implementation Requerimientos de Entrega requir ements Ethical Requerimientos Eticos requirements 24 Legislative Requerimientos Legales requirements Privacy Requerimientos requirements de Privacidad Space Requerimientos requir ements De Espacio Standards Requerimientos derequirements Estándares Safety Requerimientos requirements de Seguridad Ingeniería de Requerimientos
- 25. Ingeniería de Requerimientos “Es el proceso sistemático de desarrollar requerimientos a través de un proceso cooperativo e iterativo de analizar el problema, documentar las observaciones resultantes en una variedad de formatos de representación y chequear la precisión de la comprensión obtenida” J udith M eles 25 Ingeniería de Requerimientos
- 26. Características del proceso Representación, aspecto social y aspecto cognitivo De una formulación informal a una especificación formal Proceso no determinístico y no lineal Elicitar, especificar y validar requerimientos, no son actividades predominantemente técnicas Típica actividad de resolución de problemas. J udith M eles 26 Ingeniería de Requerimientos
- 27. Aspectos principales de la Ingeniería de Requerimientos Comprender el problema Describir el problema Acordar sobre la naturaleza del problema J udith M eles 27 Ingeniería de Requerimientos
- 28. P ropuesta de la Ingeniería de Requerimientos Validación E specificación E licitación RASTREABILIDAD HACIA DELANTE Y HACIA ATRAS J udith M eles 28 Ingeniería de Requerimientos
- 29. Interacción entre P rocesos de la Ingeniería de Requerimientos Feedback del usuario Usuario Usuario Requerimientos del usuario Especificación de Requerimientos Conocimiento E licitación licitación E E specifica specifica E ción ción Necesidad de más conocimiento Conocimiento del dominio J udith M eles Dominio Dominio del del P roblema roblema P 29 Modelos a validar por el usuario Modelos de Requerimientos Validación Validación Resultados de la validación Conocimiento del dominio Ingeniería de Requerimientos
- 30. P roductos entregables M odelos ... Del dominio del problema De los requerimientos funcionales De los requerimientos no funcionales J udith M eles 30 Ingeniería de Requerimientos
- 31. E licitación: P ropósito Ganar conocimiento relevante del problema, para producir una especificación rigurosa del software necesario para resolver el problema. Al final del proceso el analista podría ser un “experto” en el dominio del problema. J udith M eles 31 Ingeniería de Requerimientos
- 32. E licitación: E ntradas Fuentes del conocimiento del dominio: • Expertos del dominio • Literatura sobre el dominio • Software existente en el dominio • Software similar en otros dominios • Standards nacionales e internacionales • Otros “involucrados” J udith M eles 32 Ingeniería de Requerimientos
- 33. Elicitación: Actividades Tareas a encarar por el analista: • Identificar fuentes de conocimiento • Adquirir el conocimiento • Decidir sobre la relevancia de un conocimiento • Comprender la significación del conocimiento y su impacto J udith M eles 33 Ingeniería de Requerimientos
- 34. E licitación: Actividades Técnicas más usadas : Entrevistas Torbellino de Ideas Escenarios Reuso de conocimiento Análisis de Documentación Observación Análisis de Objetivo / Meta J udith M eles 34 Ingeniería de Requerimientos
- 35. E licitación: P roductos E un proceso de creación de modelos s E analista comienza con modelos l mentales con conocimiento dependiente del domino Al avanzar, los modelos son más orientados al software No se produce ningún modelo formal Sucesión de modelos mentales del dominio del problema J udith M eles 35 Ingeniería de Requerimientos
- 36. E specificación: P ropósito Acuerdo usuarios-desarrolladores sobre el problema a resolver P auta para el desarrollo de un sistema de software J udith M eles 36 Ingeniería de Requerimientos
- 37. E specificación: E ntradas Conocimiento sobre el dominio del problema L provee el proceso de elicitación o J udith M eles 37 Ingeniería de Requerimientos
- 38. E specificación: Actividades Análisis y asimilación del conocimiento de los requerimientos Síntesis y organización del conocimiento en un modelo de requerimientos coherente y lógico J udith M eles 38 Ingeniería de Requerimientos
- 39. E specificación: P roductos Se producen una variedad de modelos: modelos orientados al usuario, que especifican comportamiento, características no funcionales, etc. modelos orientados al desarrollador, que especifican propiedades funcionales y no funcionales del software y restricciones J udith M eles 39 Ingeniería de Requerimientos
- 40. EP l roblema... A partir del M odelo de requerimientos se puede establecer que no contiene definiciones contradictorias, pero... Un modelo correcto de requerimientos no es necesariamente el modelo de requerimientos correcto. No existen los RE QUE RIM NT IE OS de los requerimientos E peligro está en hacer el esfuerzo de l analizar el problema erróneo. J udith M eles 40 Ingeniería de Requerimientos
- 41. Causas de los errores Dificultades en la elicitación de los requerimientos del usuario. Dificultad en establecer un esquema de comprensión común entre analista y usuario. J udith M eles 41 Ingeniería de Requerimientos
- 42. Validación: P ropósito Certifica la consistencia del modelo (de requerimientos) con las intensiones de clientes y usuarios Ayuda a hacer el artefacto correcto L necesidad aparece cuando se a modifica el modelo actual Se aplica también a los modelos intermedios J udith M eles 42 Ingeniería de Requerimientos
- 43. Validación: E ntradas T odo modelo está sujeto a validación, por lo tanto cada modelo es input E conocimiento sobre el dominio del l problema debe ser validado Algunas partes del modelo formal J udith M eles 43 Ingeniería de Requerimientos
- 44. Validación: Actividades Interacción entre analistas, clientes del sistema y usuarios en el dominio del problema. Similar a formular una nueva teoría científica y posteriormente testearla Caracterizada por: preparación del experimento ejecución del experimento y análisis de los resultados J udith M eles 44 Ingeniería de Requerimientos
- 45. Validación: T écnicas P rototipos Animación E nfoque de Sistemas E xpertos J udith M eles 45 Ingeniería de Requerimientos
- 46. P rototipos P roceso de construcción y evaluación de modelos de trabajo de un sistema para aprender de ciertos aspectos del sistema requerido y/ su solución potencial. o T écnica común de la ingeniería. E Ingeniería de Software: es el paradigma de producir n software tan rápido y económicamente como sea posible en alguna etapa del desarrollo. Un modelo es considerado un prototipo si: • es posible obtener información sobre el comportamiento y performance del sistema que se “prototipea” • construir el prototipo debería ser un proceso rápido J udith M eles 46 Ingeniería de Requerimientos
- 47. T ipos de prototipos P rototipo de comportamiento, es un modelo en caja negra del sistema que muestra como responde a los estímulos. E un modelo funcional n P rototipo estructural, muestra como el sistema “prototipeado” cumplirá con este comportamiento. E un modelo de caja de cristal que muestra la s estructura interna y la organización del sistema. M odela los requerimientos no funcionales J udith M eles 47 Ingeniería de Requerimientos
- 48. Animación Visión gráfica múltiple de un proceso en acción. Se representan gráficamente los principales objetos y se interactúa con ellos (tiempo real) E el contexto de desarrollo de IS es un enfoque que n provee un ambiente visual para validar y ejecutar simbólicamente especificaciones conceptuales (en términos de modelos de entidades, reglas y procesos) de un IS. “E el contexto de especificaciones conceptuales, visualización involucra n la animación del comportamiento de un sistema y una interfase visual que refleja los resultados de eventos bajo la componente gráfica -cuando es apropiado la textual- de la especificación” J udith M eles 48 Ingeniería de Requerimientos
- 49. Animación: Características Ventaja sobre prototipos: no impone decisiones de diseño muy tempranas P rovee una indicación de la dinámica del sistema mediante una recorrida P ermite determinar relaciones causales escondidas en la especificación J udith M eles 49 Ingeniería de Requerimientos
- 50. E nfoque de sistemas expertos Algunas herramientas CASE reciben el calificativo de sistemas expertos por el conocimientos de algunos aspectos del proceso que ellos corporizan. E puede ser: ste • conocimiento del método, conocimiento de cómo aplicar un método de RE • conocimiento del dominio, conocimiento sobre el dominio el cual se supone se modeló J udith M eles 50 Ingeniería de Requerimientos
- 51. M odos de acción de un Sistema E xperto Comportamiento de un sistema experto en RV experto, lleva a cabo el proceso de experto validación, asistente, asiste al analista en la validación asistente aprendiz, ejecutar las actividades de bajo aprendiz nivel de la validación J udith M eles 51 Ingeniería de Requerimientos
- 52. Validación: Salidas M odelo de requerimientos en línea con las expectativas de los usuarios No significa que el modelo sea correcto Compromiso entre lo deseado y lo posible y factible J udith M eles 52 Ingeniería de Requerimientos
- 53. Validación Interacción con otros procesos •L a validación está presente en todos los procesos L de la IR, la dispara: nuevo conocimiento sobre el dominio del problema (elicitación) formulación de un modelo de requerimientos (especificación) L validación se requiere en las etapas a de análisis y síntesis (pues debe chequearse la corrección de la información) J udith M eles 53 Ingeniería de Requerimientos
- 54. Verificabilidad de los Requerimientos L requerimientos deberían ser os escritos de manera tal que puedan ser objetivamente verificables. E problema con el requerimientos es l el uso de términos vagos. E ratio de errores debería ser l cuantificado. J udith M eles 54 Ingeniería de Requerimientos
- 55. M edidas de los Requerimientos Propiedad Medida Velocidad Tamaño • K Bytes • Número de chips de RAM Facilidad de Uso • Tiempo de capacitación • Número de entornos de ayuda Confiabilidad • Tiempo medio entre fallas • Probabilidad de indisponibilidad • Ratio de Ocurrencia de Fallas • Disponibilidad Robustez • Tiempo de reinicio después de fallas • Porcentaje de Eventos que causan fallas • Probabilidad de corrupción de datos durante una falla. Portabilidad J udith M eles • Transacciones / Segundo Procecesadas • Tiempo de Respuesta de Evento / Usuario • Tiempo de barrido de la pantalla • Número de Sistemas destino • Porcentaje de definiciones dependientes del destino 55 Ingeniería de Requerimientos
- 56. P ropiedades Deseables para la E specificaicón de Requerimientos Consistencia Interna No ambigüedad Consistencia E xterna M inimalidad Completitud Rastreabilidad J udith M eles 56 Ingeniería de Requerimientos
- 57. Indice del Standard de IE E para la E E specificación de Req. de Software 1. Introducción 1.1. Propósito 1.2. Alcance 1.3. Definiciones, acrónimos y abreviaturas 1.4. Referencias 1.5. Overview 2. Descripción general 2.1. Perspectiva del producto 2.2. F unciones del producto 2.3. Características del usuario 2.4. Restricciones generales 2.5. Supuestos y dependencias 3. Requerimientos específicos Apéndices J udith M eles 57 Ingeniería de Requerimientos
- 58. 1.Introducción 1.1. Propósito Delinear el propósito de la SRS y especificar a quién se dirige 1.2. Alcance Identificar los productos de SW explicar que hará y , que no hará cada uno, describir la aplicación 1.3. Definiciones, acrónimos y abreviaturas Incluir las definiciones de los términos, acrónimos y abreviaturas requeridas para interpretar la SRS. 1.4. Referencias P roveer una lista completa de todos los documentos referenciados 1.5. Overview Describir qué contiene el resto de la SRS y explicar cómo está organizada la SRS J udith M eles 58 Ingeniería de Requerimientos
- 59. 2.Descripción General Describe los factores generales que afectan al producto y a los requerimientos, facilita su comprensión 2.1. Perspectiva del producto – – – – – – Relación con otros productos o proyectos P roductos independientes Componentes de un sistema o de un proyecto: H ardware y equipamiento periférico Diagrama de bloques Restricciones de diseño 2.2. F unciones del producto – – – – J udith M eles Resumen de las funciones que ejecutará el software. Comprensibilidad Diagrama de bloques No establece requerimientos específicos, 59 Ingeniería de Requerimientos
- 60. 2.Descripción General - II 2.3. Características del usuario – Características generales del usuario – Restricciones impuestas por los interactuantes – Requerimientos específicos o restricciones sobre la solución 2.4. Restricciones generales – L ímites al desarrollador – Requerimientos específicos o restricciones sobre la solución 2.5. Supuestos y dependencias – F actores que afectan los requerimientos – Restricciones de diseño – Cambios quepueden afectar los requerimientos en la SRS. J udith M eles 60 Ingeniería de Requerimientos
- 61. Descripción General - III 2.4. Restricciones generales L ímites a las opciones para diseñar el sistema: • • • • • • • • • • J udith M eles P olíticas regulatorias L imitaciones de hardware Interfases con otras aplicaciones Operaciones paralelas F unciones de auditoría F unciones de control Requerimientos de lenguajes de alto nivel P rotocolos de “signal handshake” (ej: XON/ XOF ) F Criticalidad de la aplicación Consideraciones de seguridad (Safety and Security) 61 Ingeniería de Requerimientos
- 62. 3.Requerimientos específicos E sector mayor y más importante de la SRS l P resentación y conceptualización del desarrollo de los requerimientos E contexto de la ingeniería de l requerimientos. J udith M eles 62 Ingeniería de Requerimientos
- 63. Requerimientos específicos - I 3.1. Requerimientos funcionales 3.1.1. Requerimientos funcionales 1 3.1.1.1.Introducción 3.1.1.2.Inputs 3.1.1.3.P rocesos 3.1.1.4.Outputs ..... 3.1.n. Requerimientos funcionales n 3.2. Requerimientos de interfase externa 3.2.1. Interfases del usuario 3.2.2. Interfases del hardware 3.2.3. Interfases del software 3.2.4. Interfases de comunicaciones 3.3. Requerimientos de performance 3.4. Restricciones de diseño 3.4.1. Cumplimiento de standards 3.4.2. L imitaciones de H ardware .... J udith M eles 63 Ingeniería de Requerimientos
- 64. Requerimientos específicos - II 3.5. Atributos 3.5.1. Disponibilidad 3.5.2. Seguridad 3.5.3. Mantenibilidad 3.5.4. T ransferibilidad/ conversión ... 3.6. Otros requerimientos 3.6.1. B ase de Datos 3.6.2. Operaciones 3.6.3. Adaptación del lugar J udith M eles 64 Ingeniería de Requerimientos
- 65. B ibliografía L oucopoulos, P K ., arakostas, V., Sy stem Requirem ents Engineering, M cGraw-H ill, 1995, L ondon. Sommerville, Ian, Software E ngineering 5T E h dition, Addison W esley, 1995 J udith M eles 65 Ingeniería de Requerimientos
Hinweis der Redaktion
- 1.1. Propósito 1. Delinear el propósito de la SRS en particular 2. Especificar la audiencia a la que se dirige la SRS 1.2. Alcance 1. Identificar los productos de software ha ser producidos por nombre, por ejemplo: DBMS del Host, Report Generator, etc. 2. Explicar que hará y, si es necesario, que no hará el producto de software 3. Describir la aplicación del software a ser especificado. Como parte de este, debería: · Describir todos los beneficios relevantes, objetivos y metas tan precisamente como sea posible · Ser consistente con especificaciones de mayor nivel (como un análisis del dominio o un plan de sistemas) 1.3. Definiciones, acrónimos y abreviaturas Debería incluir las definiciones de todos los términos, acrónimos y abreviaturas requeridas para interpretar la SRS. Esta información puede proveerse por referencia a apéndices de la SRS o a otros documentos. 1.4. Referencias 1. Proveer una lista completa de todos los documentos referenciados en otra parte de la SRS o en un documento, separado, especifico. 2. Identificar cada documento por título, numero de informe (si corresponde), fecha y organización que lo publicó. 3. Especificar las fuentes de dónde se obtuvieron las referencias. Esta información puede darse por referencia a un apéndice o a un documento por separado. 1.5. Overview 1. Describir qué contiene el resto de la SRS 2. Explicar cómo está organizada la SRS
- 2. Descripción General Esta sección describe los factores generales que afectan al producto y a los requerimientos. No tiene como meta establecer requerimientos específicos, sólo hace que esos requerimientos sean más fáciles de comprender. 2.1. Perspectiva del producto Esta subsección de la SRS pone al producto en perspectiva con otros productos o proyectos. 1. Si el producto es independiente y totalmente autocontenido, aquí debe establecerse. 2. Si la SRS define un producto que es una componente de un sistema o de un proyecto mayor, en esta sección debería: · Describir las componentes del sistema o proyecto mayor e identificar las interfases · Identificar las principales interfases externas del producto de software que se está especificando (la descripción no debe ser detallada) · Describir el hardware de computadoras y equipamiento periférico a ser usado (esta es una descripción global) Puede ser útil un diagrama de bloques del sistema o proyecto mayor con las interconexiones e interfases externas. Esta subsección debería proveer las razones por las que ciertas restricciones de diseño serán especificadas más adelante en la SRS. 2.2. Funciones del producto Es un resumen de las funciones que ejecutará el software, sin mencionar los detalles que requieren esas funciones. Muchas veces este resumen puede extraerse de la especificación de mayor nivel. A los efectos de claridad: 1. Las funciones deberían organizarse haciendo que la lista de funciones sea comprensible al cliente o a cualquiera que lea el documento por primera vez 2. Diagramas de bloques que muestran las funciones y sus relaciones pueden ser útiles. Esta sección no debería establecer requerimientos específicos, pero debería dar las razones por las que luego se establecerán ciertos requerimientos específicos.
- 2.3. Características del usuario Describe las características generales del usuario que afectarían los requerimientos específicos. De las muchas personas que interactúan con un producto, algunas características tales como nivel educacional, experiencia y expertise técnico imponen restricciones importantes en el ambiente operacional del sistema. Esta subsección no debería establecer requerimientos específicos ni restricciones sobre la solución, pero debería dar las razones por las que luego se establecerán ciertos requerimientos específicos o restricciones de diseño. 2.4. Restricciones generales Describe en términos generales cualquier ítem que limite al desarrollador las opciones para diseñar el sistema. Estas incluyen: 1. Políticas regulatorias 2. Limitaciones de hardware 3. Interfases con otras aplicaciones 4. Operaciones paralelas 5. Funciones de auditoría 6. Funciones de control 7. Requerimientos de lenguajes de alto nivel 8. Protocolos de “signal handshake” (ej: XON/XOFF) 9. Criticalidad de la aplicación 10. Consideraciones de seguridad (Safety and Security) Esta subsección no debería establecer requerimientos específicos ni restricciones sobre la solución, pero debería dar las razones por las que luego se establecerán ciertos requerimientos específicos o restricciones de diseño. 2.5. Supuestos y dependencias Esta subsección debería listar cada uno de los factores que afectan los requerimientos establecidos en la SRS. Estos factores no imponen restricciones de diseño sobre el software, pero cada cambio en ellos puede afectar los requerimientos en la SRS.
- 2.4. Restricciones generales Describe en términos generales cualquier ítem que limite al desarrollador las opciones para diseñar el sistema. Estas incluyen: 1. Políticas regulatorias 2. Limitaciones de hardware 3. Interfases con otras aplicaciones 4. Operaciones paralelas 5. Funciones de auditoría 6. Funciones de control 7. Requerimientos de lenguajes de alto nivel 8. Protocolos de “signal handshake” (ej: XON/XOFF) 9. Criticalidad de la aplicación 10. Consideraciones de seguridad (Safety and Security) Esta subsección no debería establecer requerimientos específicos ni restricciones sobre la solución, pero debería dar las razones por las que luego se establecerán ciertos requerimientos específicos o restricciones de diseño.
- 3. Los requerimientos específicos La presentación de estos está estrechamente asociada con la conceptualización que se tenga del desarrollo de los requerimientos, de allí que esta parte, la mayor y más importante de la SRS, se debe presentar en el contexto de la ingeniería de requerimientos.