INV. ESPECIFICACIÓN DE REQUISISTOS DE SOFTWARE Chávez Martínez Jose Guadalupe Descripción breve Definir las especificaciones funcionales y no funcionales para el desarrollo de un sistema recomendado web que permitirá orientar a los clientes durante la compra de su equipo de cómputo. Éste será utilizado por clientes y proveedores TECNOLOGICO DE ESTUDIOS SUPERIORES DE ECATEPEC FUNDAMENTOS DE INGENIERIA DE SOFTWARE Objetivo Definir las especificaciones funcionales y no funcionales para el desarrollo de un sistema recomendado web que permitirá orientar a los clientes durante la compra de su equipo de cómputo. Éste será utilizado por clientes y proveedores Justificación Esta especificación de requisitos está dirigida a los distintos usuarios del sistema, con el objetivo de continuar el desarrollo del sistema recomendado a través del mejoramiento continuo aplicado en las próximas versiones del sistema mejorando interfaz de usuario, método recomendado o proceso de comp. Desarrollo Cascada: Definir requisitos, diseño sistema, implementación, integración y pruebas, funcionamiento y mantenimiento) Desarrollo evolutivo se basa en la implementación de un sistema inicial, exponerla a los comentarios de los usuarios y depurarla, bucle(especificación, desarrollo, validación) hasta el sistema deseado. Modelo de entrega incremental: modelo intermedio,mix Cascada y evolutivo Las etapas principales de especificación de software son: Estudio de viabilidad Obtención y análisis de requisitos. Especificación de requisitos. Validación de requisitos. Validación de software Prueba de componentes Prueba del sistema Prueba de aceptación Crisis del software La dificultad que existía para dev programas, que además de funcionar correctamente, fueran comprensibles, verificables, adaptables y menos costosos. Los principales problemas eran: No terminaban en la fecha establecida. Superaban de manera sustancial el presupuesto inicial. No se cumplían con las especificaciones establecidas. Se desarrollaba código de baja calidad. Requisitos deben de ser: Comprensibles, Necesario, No ambiguo, Completo, Consistente, Verificable, Realizable, Modificable, Rastreable, Priorizable RF Describen con detalle los servicios y funcione que un sistema debe hacer. Como debe reaccionar ante una entrada particular y como debe comportarse ante situaciones particulares, excepcionales,… RNF Describen las restricciones que afectan a los servicios o funcionalidades del sistema. Son restricciones sobre los RF. Pueden ser del tipo: Producto: especifican o restringen el comportamiento del producto obtenido, ejemplo: memoria requerida o velocidad de ejecución.(usabilidad,fiabilidad,eficiencia[rendimiento,espacio],portabilidad) Organizacionales: pueden ser procesos estándar utilizados, fechas de entrega, documentación a entrega.(entrega,implementación,estándares) Externos: describen factores externos al sistema, ejemplo: LOPD. (Inteoperabilidad,ético,legislativos[privacidad,seguridad]) RDom Provienen del dominio de aplicación del sistema, reflejando las carácterísticas y restricciones de ese dominio. Pueden ser RF o RNF. Ejemplo: Debido a las restricciones de la licencia CEDRO, algunos documentos solo podrán ser visualizados online. SRS Software Requirements Specifications. Debe incluir todo lo que los desarrolladores del software deben implementar, es decir, una descripción general de las funcionalidades, necesidades y restricciones del software a desarrollar. Debe de incluir tanto los requisitos de usuario como los del sistema. Elicitación Hasta las últimas décadas la elicitación de requisitos no era considerada como parte de un proyecto de desarrollo de software ya que se asumía que los clientes debían proporcionar los requisitos por lo que estas tareas, de elicitación y validación, no se consideraban necesarias. A partir de la “crisis del software” fue cuando se empezaron a considerar importantes estas tareas. Esta actividad es donde se capturan y obtienen los requisitos. Los participantes o stakeholders son aquellas personas que se verán afectadas por el software que se va a desarrollar. La elicitación y análisis de requisitos se puede estructurar en cuatro puntos: Descubrimiento de requisitos. Clasificación y organización de requisitos. Ordenación por prioridades y negociación de requisitos. Documentación de requisitos Técnicas de elicitación: Entrevistas individuales/grupales Cuestionarios Escenarios Casos de uso Brainstorming Reutilización de requisitos. Prototipos. Revisión de documentación técnica. Ingeniería inversa Talleres de discusión. Entrevistas cerradas/abiertas. Comprender preparación/realización/análisis. las necesidades del software. Fase Brainstorming participantes experiencia en diferentes disciplinas para ideas creativas. No juzgar ideas. No se descarta ninguna. Fase Preparación, Generación, Consolidación, Documentación. Casos de uso Se basa en escenarios para obtener los RF de un software. Un caso de uso es un escenario que representa la interacción entre los actores y el software. Un actor caracteriza las interacciones que los usuarios pueden tener con el sistema y puede participar en uno o más casos de uso al igual que un caso de uso puede estar relacionado con uno o varios actores. Prototipos El dev representativo y a pequeña escala de las necesidades del usuario simulando el software a desarrollar. Fases: Captura de requisitos; Definición de objetivos del software e identificación de requisitos por parte de desarrolladores y clientes; Diseño rápido del software, centrándose en los elementos que interactuarán con el usuario (entradas y salidas);Construcción del prototipo. JAD La técnica de trabajo grupal en la que se involucra a todos los stakeholders para realizar un desarrollo preliminar del software a desarrollar. Tipos de participantes: Jefe del JAD, analista, Patrocinador ejecutivo, Representantes de los usuarios, Representantes de los sistemas, Especialista. Ingeniería inversa Es una técnica que se utiliza para obtener información de un software ya existente con la finalidad de entender como funciona, y así, poder modificarlo, mejorarlo, evolucionarlo y rediseñarlo. Validación de requisitos Es la actividad en la que se verifica que todos los requisitos obtenidos, descritos y documentados en los pasos anteriores son válido. Durante esta validación debemos controlar que estos requisitos son: válidos, consistentes, completos, reales, verificables, comprensibles, trazables, adaptables Conclusión Este tema es muy interesante ya que nos habla de una descripción general del sistema, con el fin de conocer las principales funciones que éste debe realizar, los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin detallar de manera excesiva los diferentes aspectos del mismo.
