Unidad III Ingenieria de Requisitos

Fundamentos de ingeniería de Software

Unidad II Ingeniería de requisitos 2.1 Ingeniería de requisitos Comprende todas las tareas relacionadas con la determinación necesidades o de las condiciones a satisfacer para un software tomando en cuenta los diversos requerimientos de los inversores Esta facilita:    

comprender lo que quiere el cliente analizando la solución validando la especificación gestión de los requerimientos

Para que se transformen en un sistema operacional

2.1.2 Que es un requerimiento 





Una condición o necesidad de un usuario para resolver un problema o alanzar un objetivo [IEEE2006] Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal [IEEE2006] Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de este [SOM2005]

Requerimiento

Podemos decir que es una descripción de la capacidad que debe cumplir un sistema, ya sea derivado de una necesidad, una especificación o un documento formal mente impuesto al inicio del proceso Requerimientos del sistema

Instituto Tecnológico de Chihuahua II


Descripción detallada de las funciones, servicios y sistema.

restricciones operativas del

Es un punto de partida para el diseño del sistema. Los requerimientos del software se dividen en: 



Requerimientos funcionales: Servicios que proveerá el sistema. La

manera en reaccionar ante entradas particulares y de cómo se comportara en situaciones particulares. Requerimientos no funcionales: Restricciones de los servicios o funciones ofrecidas por el sistema. Son propiedades que debe tener el sistema (software) como por ejemplo: la fiabilidad, el tiempo de respuesta entre otros (investigar sobre la clasificación de requerimientos no funcionales).

Características de un requerimiento     

Verificable: ¿Cómo se sabe si se cumplió con él o no? Conciso: Redacción simple y clara Completo: Proporciona la información suficiente para su comprensión. Consistente: No debe ser contradictorio con otros requerimientos No ambiguo: El lenguaje usado en su definición, no debe causar confusión

al lector. 2.1.2 Ingeniería de Requerimientos El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema. La meta es entregar una especificación de los requisitos de software correcta y completa 2.1.3 Importancia de IR  

 

Permite gestionar las necesidades del proyecto en forma estructurada Controles subsecuentes y actividades de mantenimiento, estimación de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto Mejora la calidad del software (funcionalidad, facilidad de uso, confiabilidad, etc.) Instituto Tecnológico de Chihuahua II

Fundamentos de ingeniería de Software  

Mejora la comunicación entre clientes y desarrolladores Obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema

2.1.4 Tareas de la ingeniería de requerimientos Existen cuatro actividades básicas, esta ayuda a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificación y administración adecuada de los requerimientos de los clientes o usuarios. 1.- Extracción: Son las actividades involucradas en el descubrimiento de los

requerimientos del sistema. Se trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los deferentes servicios que debe prestar, las restricciones, etc. 2.- Análisis: Se enfoca en descubrir problemas con los requisitos del sistema

identificados hasta el momento. Se leen, conceptúan, investigan, intercambian ideas con el resto del equipo, resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir requeriremos. 3.- Especificaciones: Se documentan los requisitos acordados con el cliente, a

un nivel de detalle apropiado. Es pasaren limpio el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML(Lenguaje de modelado unificado) 4.- Validación: Su objetivo es, ratificar los requerimientos, asegurar que

representen una descripción, por lo menos, aceptable del sistema que se debe implementar, que sean consistentes y estén completos 2.2 Técnicas de la Ingeniería de requerimientos Existen varias técnicas de las cuales solo referenciaremos cinco:  

Entrevistas y cuestionarios Sistemas existentes Instituto Tecnológico de Chihuahua II

Fundamentos de ingeniería de Software   

Lluvia de ideas Prototipos Casos de uso

Estas técnicas pueden ser aplicables a las distintas fases del proceso, tomando en cuenta las características de cada proyecto en particular

Entrevistas y cuestionarios

Se emplean para reunir información proveniente de personas o grupos Entrevista (Formales e informales), en estas se hacen preguntas sobre el sistema que utilizan y sobre el sistema a desarrollar. 1. Interrogación estandarizada 2. Conversación libre donde no hay un programa definido. Nota: Normalmente son una mezcla, ya que las respuestas a algunas preguntas

pueden conducir a otras cuestiones que se discuten de una manera menos estructurada. Cuestionario

Es la forma de relacionarse con un gran número de personas. 1. Debe llevar el nombre del tema al inicio 2. El objetivo y un preámbulo para quien va a contestar 3. No se tiene contacto con las personas que responden, esto asegura respuestas más honestas 4. Las preguntas pueden ser abiertas (sentimientos, opiniones y experiencias personales), 5. Las preguntas cerradas (limita las respuestas posibles) 6. Mixtas (de los dos tipos). Sistemas Existentes

Consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a construir.



 

Analizar Las interfaces (tipo de información y forma de manipulación) Análisis de las salidas (Listados, consultas, etc.)

Lluvia de Ideas

Busca establecer la máxima cantidad posible de requerimientos para el sistema, sin importar si esta son o no útiles del todo. Busca tener muchas ideas, que después se irán descartando, pro, ejemplo por caro, impráctico, imposible, etc. Reglas:  

 



Los participantes deben pertenecer a distintas disciplinas Conviene suspender el juicio crítico y debe permitir la evolución de cada idea Por locas que parezcan, no se deben descartar Abecés ocurre que una idea resulta en otra, y abecés varias generan una nueva Escribir las ideas sin censura

Observación (Escenarios)

Las personas encuentran más fácil dar ejemplos de la vida real que descripciones abstractas. Pueden comprender y criticar un escenario, de cómo podría interactuar con un sistema de software. Pueden ser útiles para agregar detalles a un esbozo de la descripción de requerimientos. Estos comienzan con un esbozo de la interacción y, durante la observación, se agregan detalles para crear una descripción completa de esta interacción. Revisión de documentos

Recopilación y estudio de los documentos de la empresa para el desarrollo del Sistema. 1. Facturas 2. Órdenes de compra 3. Políticas y procedimientos



4. Reportes Prototipos

Puede ocurrí que algún requerimiento no quede claro o haberse comprendido, entonces para validar estos, se construyen prototipos. Estos son simuladores del posible producto, que luego son utilizados por el usuario final, permitiendo nos una retroalimentación si el diseño permite al usuario realizar su trabajo de manera eficiente y efectiva. Inicia con: Recolección de requisitos Diseño rápido  

Caso de uso:

Documento narrativo que describe la secuencia de eventos de un actor (agentes externos) que utiliza un sistema para completar un proceso.    

Son casos de utilización del sistema No son los requerimientos ni las especificaciones Son ejemplificaciones en las que se Incluyen los requerimientos en la narración

2.3 Modelado de requisitos Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interacción, de objetos, etc. La meta es entender mejor el problema, más que iniciar el diseño de la solución (idealmente), el tipo de modelo elegido depende de:    

La naturaleza del problema La experiencia del modelizador La disponibilidad de herramientas Por decreto. El cliente impone una notación



Por otro lado, no existe “la mejor” forma de modelizar requisitos. En realidad, no hay evidencia empírica que demuestre, en general, la superioridad de unas notaciones de modelización frente a otras.

La comprensión de los requerimientos, es necesario comprender los procesos y ambiente externo que participan en los proceso. Esto lo podemos describir con una narración del proceso con un formato estructurado Caso de uso

Documento narrativo que describe la secuencia de eventos de un actor (agentes externos) que utiliza un sistema para completar un proceso. Son casos de utilización del sistema, No son los requerimientos ni las especificaciones, Son ejemplificaciones en las que se incluyen los requerimientos en la narración Errores en los casos de uso

La identificación de los pasos, operaciones o transacciones individuales como casos de uso Por ejemplo: En el dominio de la TPV, podemos definir (Incorrectamente) un caso denominado imprimir el recibo , cuando en realidad es una operación que es parte de un proceso más amplio compra productos. Nota: los caos son descripciones completas de principio a fin relativamente amplio, que abarca muchos pasos o transacciones, no es una actividad o paso individual Caso de uso formato de Alto Nivel

Este describe un proceso muy brevemente, en dos o tres enunciados 1. Usado durante el examen de requerimientos y el proyecto 2. Permite conocer rápido el grado de complejidad y funcionalidad 3. Son muy concisos y vagos en las decisiones del diseño



Ejemplo: caso de uso de alto nivel que descebe el proceso de compra de un

artículo en una tienda cuando de emplea una terminal punto de venta (TPV)

Caso de uso formato Expandido

Describe un proceso más a fondo que el de alto nivel. La diferencia básica consiste en que tiene una sección destinada a curso normal de eventos, que los descebe paso a paso  

Usados en la especificación de requerimientos en los más importantes Los menos importantes pueden realizarse en la etapa de desarrollo

Ejemplo: Caso de uso de alto nivel que descebe el proceso de compra de un

artículo en una tienda cuando de emplea una terminal punto de venta (TPV)



Explicación de formato expandido 

Caso de uso: Se da comenzando con un verbo, para identificar que es un

proceso 

Actores: Lista de agentes externos, en la cual se identificas quien inicia el

caso     

Propósito: Objetivo del caso Resumen: Síntesis de caso Tipo: 1- primario o secundario 2- esencial o real Referencias: casos y funciones relacionadas Curso normal de eventos: detalla la iteración de los actores con el

sistema 

Cursos alternativos: Alternativas que pueden suceder en el numero de

una línea Tipos de casos:

1. Primarios : Representan los procesos comunes mas importantes (compra de productos) Instituto Tecnológico de Chihuahua II


2. Secundarios: Representan procesos menos importantes (sol de resurtir producto) 3. Opcionales: representan proseos que pueden no abordarse 4. Esenciales: escribe el proceso a partir de sus actividades y motivos esenciales. 5. Reales: describe su proceso a partir de su diseño actual, sujeto a la tecnologías de e/s

2.4. Herramientas CASE para la Ingeniería de requisitos (IR) En la actualidad los sistemas informáticos se caracterizan por su complejidad, eficacia e importancia estratégica. En este confuso contexto de especificación de software, crear documentación de alta calidad es complicado. Es frecuente los clientes no saben con claridad lo que desean y muchas veces los requisitos no reflejan las necesidades del clientes. Es común tropezar con requerimientos inconsistentes e incompletos. En este contexto, uno de los grandes desafíos está en la necesidad de constituir los requisitos organizacionales y funcionales del software que será desarrollado.



La IR es en esencia la aplicación de principios, métodos, técnicas y herramientas en pro del descubrimiento de los requisitos de un producto software; de igual manera, permite el análisis y documentación de los objetivos, funciones y restricciones de dicho sistema de computación, pero presenta una falencia: no hay acuerdo sobre lenguajes, métodos y herramientas, para su ejecución Es decir al proceso de identificación, asignación y seguimiento de los mismos, incluyendo interfaz, verificación, modificación y control de cada requisito, durante el ciclo de vida del proyecto. Los cambios/actualizaciones de requisitos deben ser gestionados para asegurar que se mantenga la calidad del producto. Hasta hace poco tiempo las herramientas para la gestión de requisitos de software se limitaban a editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones La ingeniería de requisitos es una tarea que aún tiene mucho por explorar para optimizar sus tareas y cumplir a cabalidad los objetivos propuestos.

IRQA4

Herramienta CASE de ingeniería de requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación del sistema  

Facilita y formaliza la comunicación (cliente, proveedor y equipo desarrollo) Facilita la captura, organización y análisis de requisitos y especificaciones

Se apoya en metodología adaptable a cada cliente

Osrmt (open source requerements management tool)

Herramienta libre para gestión de requisitos, algunas de sus principales características es:  Trabaja en arquitectura cliente/servidos  Desarrollado bajo Java  La versión 1.3 trae un módulo para manejar la rastreabilidad de los requisitos  Introduce modulo para el control de cambios



Genera la documentación de los requisitos tratados Aunque tiene una interfaz agradable, le falta madurar algunos aspectos. 

Jerema

Se trata de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Esta herramienta ayuda durante el desarrollo del sistema, específicamente con el seguimiento de cambios de los requisitos a lo largo del ciclo de vida.  Capta las necesidades, las analiza y califica  Implementa un módulo orientado a la generación de documentación posible de exportar en formato docbook XML Los requisitos y documentos se almacenan en una base de datos de MySQL Rambutan

Eta herramienta es básicamente en XML, realmente consta de un conjunto de aplicaciones para usuario final ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos.  Tiene un cliente palm )(PDA), el cual se utiliza para recopilar los hechos en el lugar donde esté ubicado el cliente  La aplicación de escritorio recibe la información, edita y perfecciona los requisitos Ambas aplicaciones permite introducir, modificar y visualizar los datos que componen un documento de especificación de requisitos Otras herramientas

(ARTS), CARE 3.2, CORE 5.1, Cradle 5.2, Envision VIP, Gatherspace, IBM Rational RequisitePro, KollabNet Editor 2005, PACE, RaQuest 3.0, RMTrak, RTM, SLATE REquire 6.5, SoftREQ, UGS Teamcenter 2005, truereq product desktop, XTie-RT, Specification Analysis Tool (SAT), ECM, Banyan2.2, Contour, Projectricity 3.5, FeaturePlan 2.6, analyst pro, ChangeWare 2.0, aligned elements, Dassault Systemes CSE 4.0, Polarion ALM for Subversion 3.0, Telelogic DOORS, Accept 360.



Siglas más comunes en ingeniería de software IR ingeniería de requerimientos UML Lenguaje de modelado unificado

Referencias:

http://www.inei.gob.pe/biblioineipub/bancopub/inf/lib5040/TECN02.HTM http://es.scribd.com/doc/454427/39/Tecnologias-de-desarrollo-estructurado Andrea Alarcon, Erika Sandoval, Herramientas CASE para ingeniería de Requisitos, http://www.revistasjdc.com/main/index.php/ccient/article/view/37, 2008 Bibliografia

Alfredo Weitzenfeld, Ingenieria de Software Orientada a Objetos Con Uml, Java E Internet, Ed Thomson [BOE81] Boehm, B., SofrYt9ar-e Engineering Economics, Prentice-Hall, 1981. [LEO96] León, G, S., Ingeniería de Sistemas de Software, Isdefe,1996. [IEEE2006] IEEE Glossary of software Enegoneering Terminilogy, 2006,

http://standards.ieee.org/reading/ieee/std_public/description/se/610.121900_desc.html [SOM2005] Sommerville lan, 2005, Ingenieria de software, 7ª Edicion, Mexico,

DF, Ed Pearson. [HER2003] Herrera J., Lizka J., 2003, Ingieneria de requerimientos, Ingenieria de

software,Recuperado el 25 de mayo de 2006. en: http://www.monografias.com/trabajos6/resof/resof.shtml [KEN2009] KennethKendall & Julie Kendall,2009, Análisis y diseño de sistemas, 3

ª Edición, Prentice-Hall


Unidad III Ingenieria de Requisitos

Recommend Documents