CAPITULO 2 REQUERIMIENTOS DE SOFTWARE El rea del conocimiento de los requisitos de software (KA), se refiere al anlisis, especificacin y validacin de los

requisitos de software. Se ha demostrado ampliamente que el hecho de no realizar bien este proceso trae consecuencias fatales en el desarrollo de cualquier producto de software. 1. Fundamentos Un requisito de software es una caracterstica que se debe exhibir para solucionar un cierto problema en el mundo real. Se convierte en una combinacin compleja de requisitos entregados por parte de los usuarios implicados dentro del desarrollo de la solucin, teniendo en cuenta que pueden corresponder a diferentes niveles jerrquicos, ambientes e intereses. Es importante tambin que cada requisito sea comprobable, pensando tambin en las implicaciones que esto puede conllevar. Se pueden clasificar de la siguiente manera: Requisitos de Producto Se refiere a generar los parmetros del problema a solucionar para ser traducido a un software. Requisitos de Proceso Se refiere ya a la parte tcnica y a lo que voy a utilizar para realizar el software (lenguaje de programacin, por ejemplo). Requisitos Funcionales Son las capacidades o funciones del software. Requisitos No Funcionales Son los que actan para obligar a llegar a la solucin pero no son parte integral del software. Caractersticas Inesperadas Son requisitos que se toman pero no pueden comprobarse hasta que est funcionando el software en condiciones reales. Requisitos del Sistema y de Software Se refiere a todo lo que necesita el software para funcionar desde el punto de vista de hardware, software, recurso humano, informacin, instalaciones, servicios, etc. Los requisitos de software se derivan de los del sistema. 2. Proceso de los requisitos

Inicia de manera aislada y se va refinando con el modelo de ciclo de vida del software y necesita ser adaptado a la organizacin y al contexto del proyecto. Agentes de Proceso Incluye a todas las personas, usuarias o no, que participan en el desarrollo del proyecto. Es un grupo interdisciplinario que aporta informacin para la construccin del software. Pueden ser usuarios, clientes, analistas de mercado, reguladores, ingenieros de software, etc. Ayuda y Gerencia de Proceso Se refiere a toda la parte presupuestal y de gerencia para llevar a cabo el proyecto. Calidad y Mejora de Proceso Se refiere al coste generado por control de calidad y a los niveles de cumplimiento para lograr el objetivo principal y por ende, la satisfaccin del cliente. 3. Captura de los Requisitos Se refiere al cmo se van a recolectar los requisitos por parte del ingeniero de software. Es aqu donde es clave la comunicacin con el cliente y con todas las personas implicadas en el proceso. Fuentes de los Requisitos Deben ser confiables y sometidas a verificacin para confirmar que la persona que suministra la informacin es idnea para hacerlo y que se tom el tiempo para analizar su conveniencia. No solo por idoneidad sino porque en ocasiones los usuarios no son buenos escribiendo y no son claros a la hora de hacer una solicitud. Tcnicas de Captura de Requisitos A menudo, el ingeniero de software utiliza tcnicas de captura de requisitos, tales como: Entrevistas Prototipos Reuniones Observacin

4. Anlisis de Requisitos Es una auditora a todo lo que se recopil. De aqu salen los requisitos del sistema y por ende los de software. Permite establecer limitaciones y viabilidad del proyecto. Clasificacin de los requisitos

Pueden clasificarse en: Funcionales o no funcionales De producto o de proceso Derivado Prioritario Estable o Voltil

Modelo Conceptual Se debe elegir un modelo conceptual que ayude a entender de una mejor manera el problema. Es una habilidad con la que debe contar el ingeniero de software, apoyado en herramientas que le ayuden a contextualizar el software, como el caso de UML o el uso de la matemtica discreta. La IEEE tiene tres estndares para el modelado. Estos son: IEEE Std 1320.1 (conceptual) IDEF0 (funcional) IEE Std 1320.2, IDEF1X97 (de informacin) Asignacin Arquitectnica del Diseo y los Requisitos Es la fusin de toda la parte de requisitos con la parte de diseo. Es inseparable esta combinacin; una es parte integral de la otra y es fcil su comprensin, apoyndose en el modelo conceptual. El estndar IEEE Std 1471-2000 puede servir de apoyo en esta prctica. Negociacin de los requisitos Se llega a esta etapa cuando hay incompatibilidad en dos o ms requisitos y los solicitantes son distintos. El ingeniero de software debe reunirlos y tomar la decisin ms conveniente para el correcto funcionamiento de la solucin. 5. Especificacin de Requisitos Se refiere a plasmar en un documento todos los requisitos aprobados. Someterlos a verificacin por parte de los actores del proyecto. Es usual que se hagan tres documentos: Definicin del sistema o documento de exigencias Requisitos de sistema Requisitos de software

Es importante esta parte porque sin aprobar alguno o todos los documentos, es imposible pasar a la etapa de diseo.

El estndar IEEE Std 830 [IEEE830-98], apoya este proceso de especificacin de requisitos. 6. Validacin de los Requisitos Su objetivo es determinar que los documentos realizados sean comprensibles y de acuerdo a los estndares determinados. Por esto, deben someterse a una auditora final realizada por todo el personal implicado en el desarrollo del software (cliente), para asegurarse de que lo plasmado all es lo que se solicit. Revisiones de los requisitos Se nombra un comit revisor, que incluye a un representante del cliente, con el fin de evaluar los documentos ya mencionados. El estndar IEEE Std 1028 proporciona ayuda valiosa en la tarea de revisin. Prototipado Es un medio que utiliza el ingeniero de software para manifestar lo que entendi y para facilitar la correccin, eliminacin o adicin de requisitos. Como se evidencia, la ventaja de hacerlo es grande pero el costo puede ser alto. Pruebas de Aceptacin Son aquellas que se le aplican a cada requisito para determinar si el producto final lo satisface o no. Debe haber total planeacin para aplicar estas pruebas y hacerlo de manera cuantitativa. Como conclusin para este captulo puede afirmarse que los requisitos de software deben tomarse como una prctica seria, asignndole el tiempo y los recursos necesarios que permitan continuar con un proceso ordenado para llegar a obtener un software de calidad.