Mv unidad 2 t1

3,222 views

Published on

Especificación de requisitos

1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total views
3,222
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
143
Comments
1
Likes
0
Embeds 0
No embeds

No notes for slide

Mv unidad 2 t1

  1. 1. Ingeniería delSoftware<br />Unidad 2: Especificación de Requerimientos.<br />Trimestre I<br />Ing. Noretsys Rodríguez<br />
  2. 2. Especificación de requisitos<br />Los requisitos del software son susceptibles de cambios, no sólo después de la entrega del producto sino que también durante el proceso de desarrollo iterativo.<br />La gestión de requisitos es el proceso que administra los cambios en los requisitosdelsoftware.<br />La gestión de requisitos puede ser un proceso muy costoso, con lo cual, debe planificarse el nivel de detalle que se desea, dependiendo del proyecto.<br />Es primordial que la recolección de información de trazabilidad y su uso sea acorde con las necesidades específicas del proyecto para así conseguir un resultado positivo respecto del costo-beneficio de esta tarea.<br />
  3. 3. Textual<br />Tradicionalmente la especificación de requisitos se ha realizado usando sobre todo especificaciones textuales en lenguaje natural. <br />Las herramientas de apoyo a la gestión de requisitos se han enfocado a la manipulación de trozos de texto. <br />Estos requisitos expresados textualmente se enlazan formando un grafo de trazabilidad el cual se usa para gestionar los requisitos y su trazabilidad.<br />En este enfoque, las especificaciones generadas en las otras actividades del desarrollo de software pueden también ser añadidas al grafo de trazabilidad representándolas como texto.<br />
  4. 4. Documento de requisitos<br />El documento de requisitos es un escrito oficial de los requisitos del sistema para los clientes, usuarios finales y desarrolladores de software. <br /> Nombres:<br />Especificación funcional,<br />Definición de requisitos, <br />Especificación de los requisitos de software<br />
  5. 5. Documento de requisitos<br />El documento describe: <br /><ul><li>Los servicios y funciones que el sistema debería proveer.
  6. 6. Las restricciones bajo las cuales el sistema debe operar
  7. 7. Las propiedades generales del sistema, es decir, restricciones sobre las propiedades emergentes del sistema
  8. 8. Definiciones de otros sistemas con los cuales el sistema se debe integrar.
  9. 9. Información acerca del dominio de aplicación del sistema, por ej. cómo llevar a cabo tipos particulares de cálculos.
  10. 10. Restricciones sobre el proceso usado para desarrollar el sistema
  11. 11. glosario</li></li></ul><li>Usuarios del documento de requisitos<br />Especifican los requisitos y los leen para chequear que atienden sus necesidades. Especifican cambios en los requisitos.<br />Clientes del sistema<br />Usan los documentos de requisitos para planificar una propuesta (oferta) para el sistema y planificar el proceso de desarrollo.<br />Gerentes<br />Usan los requisitos para entender qué sistema tiene que ser desarrollado.<br />Ingenieros de sistemas<br />Usan los requisitos para desarrollar pruebas de validación para el sistema.<br />Ingenieros de prueba de sistemas<br />Usan los requisitos para ayudar a entender los sistemas y las relaciones entre sus partes.<br />Ing. de mantenimiento de sistemas<br />
  12. 12. Modelo IEEE/ANSI 830-1998<br />Introducción<br /><ul><li>1.1.Propósito del documento de requisitos
  13. 13. 1.2.Alcance del proyecto
  14. 14. 1.3.Definiciones, acrónimos y abreviaturas
  15. 15. 1.4.Resumen del resto del documento</li></ul>Descripción General<br /><ul><li>2.1.Perspectiva del producto
  16. 16. 2.2.Funciones del producto
  17. 17. 2.3.Características de los usuarios
  18. 18. 2.4.Limitaciones generales
  19. 19. 2.5.Suposiciones y dependencias</li></ul>Requisitos Específicos<br /><ul><li> 3.1.Requisitos funcionales, no funcionales</li></ul>Apéndices<br />Índice<br />
  20. 20. Notación gráfica<br />Incluye todas las notaciones que pueden demostrar el flujo de información entre requisitos apoyándose en diversas imágenes.<br />Estas notaciones permiten al usuario del sistema tener mayor comprensión del software lo que hace y como lo hace.<br />La más utilizada actualmente es el Lenguaje Unificado de modelado (UML).<br />Otra notación que se puede usar es la notación de requerimientos de usuario (URN),<br />
  21. 21. UML<br />Es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo.<br />UML, emergió en los '90 luego de la búsqueda de un lenguaje de modelamiento que unificara a la industria.<br />A pesar de que UML evolucionó de varios métodos orientados al objeto de segunda generación (en nivel de notación), su alcance extiende su uso más allá de sus predecesores. <br />
  22. 22. UML es<br />Como un lenguaje, es usado para la comunicación. Es decir, un medio para capturar el conocimiento (semánticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propósito de la comunicación. <br />Como un lenguaje para modelamiento, se enfoca en la comprensión de un tema a través de la formulación de un modelo del tema (y su contexto respectivo). <br />Cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y sistemas de información pasando por todos Los tipos de sistemas (software y no - software), dominios (negocios versus software) y los procesos de ciclo de vida.<br />
  23. 23. UML es<br />En cuanto a cómo se aplica para especificar sistemas, puede ser usado para comunicar "qué" se requiere de un sistema y "cómo" un sistema puede ser realizado.<br />En cuanto a cómo se aplica para visualizar sistemas, puede ser usado para describir visualmente un sistema antes de ser realizado. <br />En cuanto a cómo se aplica para construir sistemas, puede ser usado para guiar la realización de un sistema similar a los "planos".<br />En cuanto a cómo se aplica para documentar sistemas, puede ser usado para capturar conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo de vida.<br />
  24. 24. UML no es<br />Un lenguaje de programación visual, sino un lenguaje de modelamiento visual<br />Una herramienta o deposito de especificación, sino un lenguaje para modelamiento de especificación.<br />Un proceso, sino que habilita procesos.<br />
  25. 25. Tipos de requerimientos<br />El proceso de requerimientos maneja diferentes tipos de requerimientos, estos se pueden clasificar en: <br />Requerimientos de hardware. <br />Requerimientos de rendimiento. <br />Requerimientos de interfaz.<br />Requerimientos especiales de la ingeniería.<br />Requerimientos de ambiente.<br />Requerimientos de software: <br />Requerimientos funcionales. <br />Requerimientos no funcionales.<br />Requerimientos del Dominio.<br />Requerimientos de atributos de calidad.<br />
  26. 26. Funcionales<br />Son los requerimientos del usuario se ocupan para asignar los requerimientos de más alto nivel.<br />Los requerimientos del sistema se usan para designar la descripción detallada.<br />Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones que este debe tener.<br />Los requerimientos del sistema establecen detalladamente los servicios y restricciones del sistema.<br />
  27. 27. Funcionales<br />El documento con estos requerimientos se llama Especificación Funcional, el que debe ser preciso. Es lo más parecido al contrato entre cliente y desarrollador.<br />Corresponde a una descripción abstracta del diseño de software. Es la base para un diseño e implementación detallado.<br />Agrega el detalle a la especificación de requerimientos.<br />
  28. 28. No funcionales<br />Son prescindibles, condicionan lo que se tiene que hacer pero no son indispensables, indican mediante restricciones globales, de dominio y tecnología como debe construirse o funcionar. <br />Su fuente principal es tanto el usuario como el cliente. También se especifican en las SRS.<br />Definido como característica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que señala una restricción del mismo.<br />
  29. 29. Tipos de requerimientos no funcionales<br />Requerimientos no funcionales<br />Requerimientos del producto<br />Requerimientos organizacionales<br />Requerimientos externos<br />Requerimientos de interoperabilidad<br />Requerimientos éticos<br />Requerimientos de eficiencia<br />Requerimientos de fiabilidad<br />Requerimientos de portabilidad<br />Requerimientos legislativos<br />Requerimientos de usabilidad<br />Requerimientos de entrega<br />Requerimientos de implementación<br />Requerimientos de estándares<br />Requerimientos de desempeño<br />Requerimientos de seguridad<br />Requerimientos de privacidad<br />Requerimientos de espacio<br />
  30. 30. Requisitos funcionales Vs. Requisitos no funcionales<br />Funcionales: Me identifica, que eventos reconocer, que datos mantener y que transformaciones hacer.<br />No funcionales: Me identifica las restricciones del productos, De la organización y externos. <br />
  31. 31. Del dominio<br />Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales. <br />Se derivan del dominio del sistema más que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria. <br />
  32. 32. Resumen de contenido<br />Textual, notación gráfica y lenguajes de representación (Lenguaje Unificado de Modelado UML). <br />Técnicas para escribir requerimientos de alta calidad. Estándares de Documentación. <br />Tipos de requerimientos: funcionales, no-funcionales, del dominio. <br />

×