Requerimiento de SoftWare unidad N° 1

Unidad I Requerimiento de Software.

1.Que es un Requerimiento:

R= Un requerimiento puede definirse como un atributo necesario dentro de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales. Condición o capacidad que un usuario necesita para poder resolver un problema o lograr un objetivo, los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto, Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.Los requerimientos se pueden clasificar en:
Requerimientos Indicados: son los entregados por el usuario al comienzo del proyecto.
Requerimientos Reales: son aquellos que reflejan la satisfacción de las necesidades del usuario en un sistema en particular.

Por Ejemplo: La parte más dura en la construcción de un sistema software es decidir cómo construirlo…Ninguna parte del trabajo mutila el resultado del sistema si está hecho mal. Ninguna parte es más dificultosa para rectificarlo después. La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. Los requerimientos para un sistema de software determinan lo que hará el sistema y definen las restricciones de su operación e implementación.

2.Que es la Ingeniería de Requerimientos:

R= “La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema”. Tambien se necarga de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniería de requerimientos. Se utiliza para definir todas las actividades involucradas en el sistema, se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto de software determinado.Por Ejemplo: Requerimientos del Sistema de Producción En esta etapa la organización aborda los requerimientos del usuario, y los expresa en especificaciones viables, cubriendo las siguientes etapas.La verificación de la factibilidad del Sistema, respondiendo a las inquietudes siguientes.

•La consistencia con la política de la organización y sus objetivos.

•La importancia del producto o servicio para el futuro de la organización.

•Las posibilidades de llevarlo adelante en forma exitosa.

•La integración con otras tareas que desarrolla la organización.

•El contexto social con el que se relaciona el sistema de producción. El análisis de los requerimientos expresados en un modelo del sistema de producción. Con ello, la organización depura los planteamientos de los clientes, supera los posibles conflictos, prioriza las tareas, y está listo para elaborar los requerimientos del sistema.La especificación de los requerimientos del sistema como la base para su diseño y desarrollo.

3.Cual es la Importancia de la Ingeniería de Requerimientos:

R= La ingeniería de requerimientos es un Importante proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema.Comprende cuatro actividades de alto nivel:

1.Estudio de factibilidad

2.Obtención y análisis de requerimientos

•Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.

•Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.

•Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la IR, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo.

•Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, y otros)

•Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.

•Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Por Ejemplo: El Documento de RequerimientosAmbos requerimientos así estudiados, pueden compendiarse en un Documento de Requerimientos, para lo cual puede ser útil un esquema como el siguiente. Alcances:

•Objeto del Documento de Requerimientos

•Producto o servicio a que se refieren los requerimientos. Requerimientos del Usuario

•Finalidad del producto

•Características del producto que son requeridas.

•Restricciones previsibles del producto. Requerimientos del Sistema

•Importancia para la organización.

•Exigencias del sistema productivo.

•Atributos viables.

•Restricciones del sistema.

4.Cuales son las Actividades:

R= Se dice que dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan 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. Las cinco actividades son: extracción, análisis, especificación, validación y evolucion, y serán explicadas a continuación cada una de ellasExtracción (Análisis del problema)Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar y otros. Es importante, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuán bien éste satisfaga las necesidades del cliente.Análisis (Evaluación y negociación de los requerimientos)Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientosEspecificaciónEn esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en 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), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientosValidaciónLa validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos. Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. Hay muchas maneras de organizar el proceso de ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.Evolución de los requerimientosLos requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto, es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo que ocurre a lo largo del ciclo de vida del proyecto.

Ejemplos de la Ingeniería de Requerimientos: Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.Actividades del proceso:•

Comprensión del dominio•

Recolección de requerimientos

•Clasificación•

Resolución de conflictosEjemplos de las sesiones de interacción con el sistema. Inicia con un bosquejo y durante la obtención de agregan detalles. Un escenario incluye:

•Una descripción del estado del sistema al inicio del escenario

•Una descripción del flujo normal de eventos en el escenario

5.Cuales son las Técnicas y herramientas en la Ingeniería de Requerimientos:

R= Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.Esta técnica se enfrenta a los siguientes peligros potenciales.

•A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

•Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

•Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

•Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.Entrevistas y Cuestionarios: Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistemaSistemas existentes: Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de información que se maneja y cómo es manejada, por otro lado también es útil analizar las distintas salidas que los sistemas producen (listados, consultas, y otros.), porque siempre pueden surgir nuevas ideas sobre la base de estas.Lluvia de ideas (Brainstorm)Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como,

por ejemplo, "caro", "impracticable", "imposible", y otros. Las reglas básicas a seguir son:

•Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.

•Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generación de ideas.

•Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil.

•A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva.

•Escribir las ideas sin censura.Prototipos:Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiado claros o que no se esté muy seguro de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva. El desarrollo del prototipo comienza con la captura de requerimientos.Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.Casos de Uso: Los casos de uso son una técnica para especificar el comportamiento de un sistema. El sitio en Internet wikipedia.org, define a un caso de uso como:“Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios.Casos de uso

•Introducido en el método Objectory.

•Convertido en una característica fundamental de UML.

•Un caso de uso encapsula un conjunto de escenarios en el que cada uno es un camino único a través del caso de uso.

Ejemplos de sus usos, Casos de UsoComo mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambia datos o control con el sistema, participando de ese caso de uso.El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Ventajas:

•Reduce el tiempo de análisis o diseño, pues en una sola sesión pueden participar todos los interesados en una misma área

•Mejora las comunicaciones, pues todos los modelos derivados trazados en las sesiones de trabajo se validan con sus participantes.

•Crea sentido de consenso y participación, pues, durante las sesiones de trabajo, el usuario directo tiene la oportunidad de presentar y discutir sus puntos de vista y problemas.

•Facilita la identificación de problemas o inconsistencias, pues cualquier discrepancia entre opiniones puede aclararse en las propias reuniones de trabajo.

•Mejora la calidad de los productos, pues será posible definir en forma más completa los verdaderos requerimientos de los usuarios.

Desventajas:

•La información obtenida al principio puede ser redundante o incompleta.

•Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados