Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ingenieria de requisitos

759 views

Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

Ingenieria de requisitos

  1. 1. Que Es Ingeniería de Requisitos? La Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos. El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto.
  2. 2. ¿Que se entiende por requisito ? Una condición o necesidad del un requerimiento es usuario para resolver un problema una descripción de una o alcanzar un objetivo. condición o capacidad que debe cumplir un sistema, ya Una condición o capacidad que sea derivada de una debe estar presente en un sistema necesidad de usuario o componente de un sistema para identificada , o bien, satisfacer un estipulada en un contrato, un contrato, estándar, especificación estándar, una especiación u u otro documento formal. otro documento formalmente impuesto al inicio del proceso.
  3. 3. Características Necesario: Lo que pida un requisito debe ser necesario para el producto. No ambiguo: El texto debe ser claro, preciso  Completo: Los requisitos deben contener en y tener una única interpretación posible. sí mismos toda la información necesaria, y no Conciso: Debe redactarse en un lenguaje remitir a otras fuentes externas que los comprensible por los inversores en lugar de expliquen con más detalle. uno de tipo técnico y especializado, aunque  Alcanzable: Un requisito debe ser un objetivo aún así debe referenciar los aspectos realista, posible de ser alcanzado con el importantes. dinero, el tiempo y los recursos disponibles. Consistente: Ningún requisito debe entrar en  Verificable: Se debe poder verificar con conflicto con otro requisito diferente, ni con absoluta certeza, si el requisito fue satisfecho parte de otro. Asimismo, el lenguaje empleado o no. Esta verificación puede lograrse entre los distintos requisitos debe ser mediante inspección, análisis, demostración o consistente también. testeo.
  4. 4. Que implica? La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a: La educción (a veces llamada "elicitación", debido a una mala traducción de "elicitation") de los requisitos de usuario. El análisis y negociación de requisitos para derivar requisitos adicionales. La documentación de los requisitos como especificación. La validación de los requisitos documentados contra las necesidades de usuario. Así como los procesos que apoyan estas actividades.
  5. 5. Ingeniería de Requisitos.
  6. 6. Actividades A RealizarLas actividades son de cinco clases. Obtener requisitos: a través de entrevistas o comunicación conclientes o usuarios, para saber cuáles son sus expectativas. Analizar requisitos: detectar y corregir las falenciascomunicativas, transformando los requisitos obtenidos de entrevistas yrequisitos, en condiciones apropiadas para ser tratados en el diseño. Documentar requisitos: igual que todas las etapas, los requisitosdeben estar debidamente documentados. Verificar los requisitos: consiste en comprobar el correctofuncionamiento de un requisito en la aplicación. Validar los requisitos: comprobar que los requisitos implementadosse corresponden con lo que inicialmente se pretendía.
  7. 7. TécnicasLa ingeniería de requisitos puede ser un procesolargo y arduo para el que se requiere dehabilidades psicológicas. Los nuevos sistemascambian el entorno y las relaciones entre la gente,así que es importante identificar a todos losactores involucrados, considerar sus necesidadesy asegurar que entienden las implicaciones de losnuevos sistemas. Los analistas pueden emplearvarias técnicas para obtener los requisitos delcliente.
  8. 8. EntrevistasLas entrevistas son un método común. Por lo general no seentrevista a toda la gente que se relacionará con el sistema, sino auna selección de personas que represente a todos los sectorescríticos de la organización, con el énfasis puesto en los sectores másafectados o que harán un uso más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo secontradicen unos a otros o se formulan desde la ignorancia de losdetalles del funcionamiento del sistema, sus potencialidades,interdependencias o limitaciones.Las entrevistas pueden ser personales o grupales.
  9. 9. TalleresEs una técnica en donde las personas implicadas participan endiscusiones para descubrir requisitos y analizar sus detalles. A menudoes útil la selección de un secretario dedicado a la documentación de ladiscusión, liberando al analista del negocio para centrarse en elproceso de la definición de los requisitos y para dirigir la discusión. Forma de contratoEn lugar de una entrevista, se pueden llenar formularios o contratosindicando los requisitos. En sistemas muy complejos éstos puedentener centenares de páginas.
  10. 10. PrototiposUn prototipo es una pequeña muestra, defuncionalidad limitada, de cómo sería el productofinal una vez terminado. Ayudan a conocer la opiniónde los usuarios y rectificar algunos aspectos antesde llegar al producto terminado.Los prototipos pueden ser: diagramas, aplicacionesoperativas con funcionalidades sintetizadas.
  11. 11. Casos de usoEs una técnica para documentar posibles requisitos, graficando la relación delsistema con los usuarios u otros sistemas. El objetivo de esta práctica esmejorar la comunicación entre los usuarios y los desarrolladores, mediante laprueba temprana de prototipos para minimizar cambios hacia el final delproyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientespeligros 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.
  12. 12.  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.
  13. 13. Especificación de requisitos del softwareEs una descripción completa del comportamiento delsistema a desarrollar. Incluye un conjunto de casos deuso que describen todas las interacciones que se prevénque los usuarios tendrán con el software. Tambiéncontiene requisitos no funcionales (o suplementarios).Las estrategias recomendadas para la especificación delos requisitos del software están descritas por IEEE 830-1998. Este estándar describe las estructuras posibles,contenido deseable, y calidades de una especificación derequisitos del software.
  14. 14. Especificación de requisitos del softwareLos requisitos se dividen en tres: Funcionales: son los que el usuario necesita que efectúe el software. Ej.: el sistema debe emitir un comprobante al asentar la entrega de mercancía. No funcionales: son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño).Ej..: el soporte de almacenamiento a usar debe ser MySQL. Empresariales u Organizacionales: son el marco contextual en el cual se implantará el sistema para conseguir un objetivo macro. Ej.: abaratar costos operacionales.
  15. 15. Identificación de las personasinvolucradasDebido a que los cambios que introduce un sistema nuevo tienden aafectar a más de un tipo de usuario, los analistas de requisitos han detomar en consideración a todos los implicados para que se obtengan ydepuren sus requisitos de la forma más fidedigna posible. Entre laspersonas implicadas hay que considerar:  Organizaciones que integran la organización del analista que está diseñando el sistema  Organizaciones o sistemas de respaldo  Dirección  Usuarios
  16. 16. Problemas Relacionados con las personas involucradasLas vías que pueden dificultar la determinación de los requisitos son: Los usuarios no tienen claro lo que desean Los usuarios no se involucran en la elaboración de requisitos escritos Los usuarios insisten en nuevos requisitos después de que el coste y la programación se hayan fijado. La comunicación con los usuarios es lenta Los usuarios no participan en revisiones o son incapaces de hacerlo. Los usuarios no comprenden los problemas técnicos Los usuarios no entienden el proceso del desarrolloEsto puede conducir a la situación donde las exigencias del consumidorcambian, incluso cuando el desarrollo del producto ya está en marcha.
  17. 17. Problemas Relacionados con los analistasLa correcta redacción de las Especificaciones de requisitos delSoftware es imprescindible para el correcto desarrollo delproyecto. Por ello, en su redacción hay que evitar: Uso de terminología ambigua en la redacción de los documentos de requisitos Sobreespecificación de los requisitos Escritura poco legible, voz pasiva, abuso de negaciones Uso de verbos en condicional, expresiones subjetivas Ausencia de términos y verbos del dominio de la aplicación
  18. 18. CONCLUSION

×