Resumen del capitulo 2 del libro Guide to the Software Engineering Body of Knowledge o llamado tambien como SWEBOK, el resumen es sobre los Requerimientos del Software

1. UNIVERSIDAD NACIONAL PEDRO RUIZ GALLO Ingeniería en Computación e Informática Guide to the Software Engineering Body of Knowledge SWEBOK A project of the IEEE Computer Society Professional PracticesCommittee Ramírez Venegas Mario César Lambayeque, 20 de Septiembre 2011

3. INTRODUCCIÓN La definición de la función intencional es fundamental para asegurar que el producto software representa un valor agregado para el negocio. Para tal propósito, se hace necesario conocer, seleccionar y aplicar practicas de captura, análisis y gestión de requisitos que faciliten un esquema permanente de interacción con el cliente y una evolución de las necesidades para convertirse en especificaciones que debe cumplir el producto software (Kotonya y Sommerville 1998; Schneider y Winters 1998).

4. PRINCIPIOS DE REQUERIMIENTOS DEL SOFTWARE Definición de un Requerimiento de software: Un requerimiento de software es una característica que se puede exhibir para solucionar un cierto problema en el mundo real. Una característica esencial de todos los requerimientos de software es que sean comprobables. Productos y Requerimientos de Proceso: Los parámetros del producto son los requisitos del software a desarrollar. Un parámetro de proceso es esencialmente una restricción en el desarrollo del software. Requerimientos Funcionales y No Funcionales: Los requerimientos funcionales describen las funciones que el software va a ejecutar. Los requerimientos no funcionales son también conocidos como restricciones o requerimientos de calidad, son aquellos que actúan para limitar la solución. Propiedades Emergentes: Requerimientos que no pueden ser abordados por un solo componente, sino que dependen para su satisfacción sobre cómo todos los componentes del software interactúan. Requerimientos Cuantificables: Requerimientos de software se debe indicar como más clara e inequívoca como sea posible, y, en su caso, en términos cuantitativos. Requerimientos del Sistema y Requerimientos de Software: Los requerimientos del sistema son los requerimientos para el sistema en su conjunto. En un sistema que contiene componentes de software, los requerimientos de software se derivan de los requerimientos del sistema.

5. EL PROCESO DE REQUERIMIENTOS Modelos de Procesos: El tema se refiere a cómo las actividades de obtención, análisis, especificación y validación están configurados a diferentes tipos de proyectos y las limitaciones. El tema también incluye actividades que constituyen un aporte en el proceso de requisitos, tales como marketing y estudios de viabilidad. Actores del Proceso: Presenta las funciones de las personas que participan en el proceso de requerimientos : Usuario, Clientes, Analistas, Reguladores e Ingenieros de Software.No será posible satisfacer perfectamente las necesidades de todos los interesados, y es el trabajo del Ingeniero de Software negociar las compensaciones que son aceptables para las principales partes interesadas y dentro de las limitaciones presupuestales, normativas técnicas y otros. Proceso de Apoyo y Gestión: Presenta los recursos de gestión de proyectos requeridos y consumidos por el proceso de requisitos. Proceso de Calidad y Mejora: Tiene que ver con la evaluación de la calidad y la mejora del proceso de requerimientos. Su propósito es acentuar el papel fundamental que juega el proceso de requerimientos en términos de costos y oportunidades de un producto software.

6. CAPTURA DE REQUERIMIENTOS Se refiere a de donde vienen los requerimientos del software y cómo el ingeniero de software puede recogerlos. Es la primera etapa en la construcción de una comprensión del problema que el software requiere solucionar. Fuentes de los Requisitos: Este asunto se diseña para promover el conocimiento de las varias fuentes de los requerimientos del software y de los armazones para manejarlos. Los puntos principales cubiertos son: Objetivos, conocimientos de dominio, Stakeholders, entorno operacional y el entorno de la organización. Técnicas de Captura de Requerimientos: Este asunto se concentra en las técnicas para conseguir que los stakeholders articulen sus requerimientos. Es un área muy difícil y ingenieros de software necesitan sensibilizarse al hecho que (por ejemplo) los usuarios pueden tener dificultad para describir sus tareas, puede dejar la información importante sin especificar, o pueden estar poco dispuestos o cooperar, las principales técnicas son: Entrevistas, Escenarios, Prototipos, Reuniones, Observación.

7. ANÁLISIS DE REQUERIMIENTOS Tiene que ver con el proceso de analizar los requerimientos para: Detectar y resolver conflictos entre los requerimientos, descubrir los límites del software y como se debe interactuar con su entorno, elaborar los requerimientos del sistema para derivar los del software. Clasificación de Requerimientos: Pueden ser clasificados en una serie de dimensiones: si es funcional o no funcional, si se deriva de uno o más requerimientos de alto nivel, si esta en el producto o en el proceso, por su prioridad, por su alcance y por su volatilidad / estabilidad. Modelo Conceptual: Modelos conceptuales abarcan modelos de entidades del dominio del problema, configurados para reflejar sus relaciones y dependencias con el mundo real. Los factores que influyen en la elección del modelo son: La naturaleza del problema, la experiencia del ingeniero de software, los requerimientos del proceso del cliente y la disponibilidad de métodos y herramientas. Tenga en cuenta que es útil comenzar construyendo un modelo del contexto del software. Diseño Arquitectónico y Asignación de los requerimientos: Esta estrechamente relacionado con el capítulo de la estructura y la arquitectura del software el Área del Conocimiento del diseño del software. El diseño arquitectónico se identifica de cerca con el modelado conceptual. El mapeado de las entidades del dominio del mundo real para componentes de software no siempre tiene un diseño obvio, así que arquitectónicamente se identifica como a asunto separado. Los requisitos de notaciones y los métodos son ampliamente iguales para modelado conceptual y diseño arquitectónico. Negociación de Requerimientos: Hemos clasificado esto como asunto del análisis de requerimientos del software porque los problemas emergen como resultado el análisis. Sin embargo, un caso fuerte se puede también hacer para considerar los requerimientos como asunto de la validación.

8. ESPECIFICACIÓN DE REQUERIMIENTOS En software el término, “especificación de requerimientos del software” se refiere típicamente a la producción de un documento, o a su equivalente electrónico, que puede estar sistemáticamente repasado, evaluado, y aprobado. Para los sistemas complejos, particularmente ésos que implican componentes no-software, se elaboran tres tipos de documentos: definición de sistema, sistema requerimientos, y requerimientos del software. Para sistemas simples, solamente el tercero de éstos es requerido. Los tres documentos se describen aquí, entendiendo que combinados pueden ser apropiados. El Documento de la Definición de Sistema: Conocido a veces como documento de exigencias del o concepto de operaciones, registra el sistema. Requerimientos de alto nivel desde la perspectiva del dominio. Sus lectores incluyen representantes del sistema de los usuario/clientes. El documento enumera los requisitos del sistema junto con información de fondo sobre los objetivos totales para el sistema, su ambiente de misión y una declaración de apremios, asunciones, y requerimientos no funcionales. Puede incluir los modelos conceptuales diseñados para ilustrar el contexto del sistema, panoramas del uso y las entidades principales del dominio, así como datos, la información, y workflows. Especificación de Requerimientos de Sistema: Se especifica la visión, requerimientos del sistema, los requerimientos software se derivan de los requerimientos del sistema, y entonces los requerimientos para los componentes de software se especifican. Especificación de Requerimientos del Software: La especificación de requerimientos del software establece la base para el acuerdo entre los clientes y los contratistas o los proveedores. También proporcionar una base realista para estimar costes, riesgos, y horario del producto.

9. VALIDACIÓN DE REQUERIMIENTOS La validación de los requerimientos se refiere al proceso de examinar el documento de los requerimientos para asegurarse de que este define el software correctamente (es decir, el software que los usuarios esperan). Revisiones de los Requerimientos: Las revisiones se pueden constituir en el final del documento de definición del sistema, el documento de la especificación de sistema, el documento de la especificación de requerimientos del software, las revisiones son también cubiertas en Área del Conocimiento de la calidad del software, punto 2.3 Revisiones e intervenciones. Prototipado: Es comúnmente el medio para validar la interpretación del ingeniero del software de los requerimientos del software, así como para sacar nuevos requerimientos. La ventaja de usar prototipos es que pueden hacer más fácil la interpretación de las asunciones del ingeniero del software y, donde lo necesite, dan la explicación útil de porqué son incorrectas. Los prototipos pueden ser costosos. Sin embargo, si evitan el despilfarro de los recursos causados intentando satisfacer requerimientos erróneos, su coste puede ser más fácilmente justificado. Validación del Modelo: Es típicamente necesario validar la calidad de los modelos desarrollados durante el análisis. Pruebas de Aceptación: Una característica esencial de un requerimiento del software es que debe ser posible validar que el producto final lo satisface.

10. CONSIDERACIONES PRÁCTICAS La documentación de los requerimientos y la gerencia del cambio son llave al éxito de cualquier proceso de los requerimientos. Naturaleza Iterativa del proceso de requerimientos: El proceso de los requerimientos no es simplemente una tarea anticipada en el desarrollo del software, pero atraviesa por completo el ciclo de vida del software. En un proyecto típico, las actividades de los requerimientos del software se desarrollan. Gestión del Cambio: Describe el papel de la gestión del cambio, los procedimientos que necesitan estar preparados, y el análisis que se debe aplicar a los cambios propuestos. Atributos de los Requerimientos: Los requerimientos deben consistir no sólo una especificación de qué se requiere, sino también de la información ancilar que las ayudas manejan e interpretan los requerimientos. Los requerimientos más importantes atribuyen, sin embargo, un identificador que permite requerimientos identificados inequívocamente. El Remontar de los Requerimientos: El trazado es fundamental para el análisis de la ejecución del impacto cuando los requisitos cambian. Un requerimiento debe ser detectable al revés a requerimientos y los stakeholders que lo motivaron. Inversamente, un requerimiento debe ser detectable entidades del diseño que lo satisfacen. Requerimientos para la Medición: Como cuestión práctica, es típicamente útil tener cierto concepto del “volumen” de los requerimientos para un producto de software particular. Este punto es útil evaluando el “tamaño” de un cambio en requerimientos, en estimar el coste de una tarea del desarrollo o del mantenimiento, o simplemente para el uso como el denominador en otra medida. La medida funcional del tamaño (FSM) es una técnica para evaluar el tamaño de un cuerpo de requerimientosfuncionales.

11. Muchas gracias