Especificacion De Requerimentos De Software

12,960 views
12,752 views

Published on

Material para aprender a escribir correctamente los requerimientos del usuario

Published in: Education, Technology, Business
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total views
12,960
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
520
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Especificacion De Requerimentos De Software

  1. 1. Requerimientos
  2. 2. Agenda <ul><li>Definiciones Iniciales: Requerimientos </li></ul><ul><li>Problemas con los Requerimientos </li></ul><ul><li>Procesos de Requerimientos </li></ul><ul><li>Especificación de Requerimientos </li></ul>
  3. 3. Requerimiento <ul><li>Restricción sobre el espacio de soluciones de software. </li></ul><ul><li>Condición que debe ser cumplida por el software para que pueda ser recibido por el cliente. </li></ul><ul><li>Se negocia/determina de mutuo acuerdo con el cliente. </li></ul><ul><ul><li>No todas las necesidades y expectativas de los clientes son requerimientos. </li></ul></ul>
  4. 4. Unas definiciones iniciales <ul><li>Calidad </li></ul><ul><ul><li>Existe muchas definiciones y teorías de calidad. </li></ul></ul><ul><ul><li>Algunas de las teorías actuales sobre sistemas, calidad y procesos fueron desarrolladas en la década de 1940, por investigadores americanos en el Japón (Deming). </li></ul></ul><ul><ul><ul><li>Administración Total de Calidad </li></ul></ul></ul><ul><ul><ul><li>El ciclo de Hacer-Planear-Verificar-Actuar </li></ul></ul></ul><ul><ul><ul><li>Mejoramiento continuo de procesos </li></ul></ul></ul>
  5. 5. Unas definiciones iniciales <ul><li>Calidad </li></ul><ul><ul><li>Podríamos definir calidad como la satisfacción de las necesidades y expectativas de los usuarios. </li></ul></ul><ul><ul><li>La clave esta en lograr convertir las necesidades y expectativas de los usuarios en requerimientos. </li></ul></ul><ul><ul><li>Los requerimientos no son (de por sí) las necesidades y las expectativas de los usuarios. </li></ul></ul>
  6. 6. Unas definiciones iniciales <ul><li>Requerimiento </li></ul><ul><ul><li>Característica requerida para recibir, aceptar o adquirir un producto. </li></ul></ul><ul><ul><li>Restricción sobre el espacio de soluciones. </li></ul></ul>Si No
  7. 7. Unas definiciones iniciales <ul><li>El conjunto de requerimientos define el espacio de soluciones aceptables. </li></ul>Soluciones Aceptables
  8. 8. Unas definiciones iniciales <ul><li>Ejemplo... </li></ul><ul><ul><li>Comprar una videocasetera </li></ul></ul><ul><ul><ul><li>Debe ser Sony </li></ul></ul></ul><ul><ul><ul><li>Debe manejar VHS </li></ul></ul></ul><ul><ul><ul><li>Debe costar menos de $200.000.oo </li></ul></ul></ul><ul><ul><ul><li>Debe poderse pagar con tarjeta de crédito </li></ul></ul></ul>
  9. 9. Unas definiciones iniciales <ul><li>Ejemplo... Comprar una videocasetera </li></ul><ul><ul><li>¿Compraría una grabadora de audio, Sony, de menos de $300.000?. </li></ul></ul><ul><ul><li>¿Compraría una videocasetera Panasonic, de menos de $300.000? </li></ul></ul><ul><ul><li>¿Compraría una videocasetera Sony de $450.000? </li></ul></ul>
  10. 10. Unas definiciones iniciales <ul><li>Los requerimientos deben negociarse con los clientes </li></ul><ul><ul><li>Las necesidades y expectativas de los clientes son requerimientos potenciales . </li></ul></ul><ul><ul><li>La negociación permite determinar los requerimientos del sistema/software. </li></ul></ul><ul><ul><li>Los requerimientos deben ser parte integral de los contratos. </li></ul></ul>
  11. 11. Unas definiciones iniciales Requerimientos Potenciales Necesidades, Deseos, Expectativas del cliente Requerimientos Acuerdos entre Desarrolladores y Clientes Entrevistas Especificación Negociación
  12. 12. Unas definiciones iniciales <ul><li>Calidad... </li></ul><ul><ul><li>Cumplir con los requerimientos. </li></ul></ul><ul><ul><li>Cumplir con lo acordado con los clientes. </li></ul></ul><ul><ul><li>Cumplir a cabalidad el contrato. </li></ul></ul><ul><li>Los contratos deben elaborarse adecuadamente. </li></ul><ul><li>Los contratos deben contener a los requerimientos. </li></ul>
  13. 13. Unas definiciones iniciales <ul><li>La Ingeniería de Software y los procesos de desarrollo de software suponen que los requerimientos de software ya existen (ya están definidos, por lo menos informalmente). </li></ul><ul><li>El punto de partida de todo proceso de ingeniería son los requerimientos. </li></ul>
  14. 14. Problemas con los Requerimientos <ul><li>El proceso de requerimientos no es fácil. </li></ul><ul><li>No es simplemente “tomar nota” de las necesidades del cliente. </li></ul><ul><li>Es un proceso de comunicación. </li></ul><ul><ul><li>Es necesario entender que es lo que quiere el cliente. </li></ul></ul><ul><li>Es un proceso de negociación. </li></ul><ul><ul><li>Es necesario determinar que cosas podemos comprometernos a hacer. </li></ul></ul>
  15. 15. Problemas con los Requerimientos <ul><li>No hay acuerdos en los Requerimientos </li></ul><ul><ul><li>No se hizo ningún tipo de negociación y no hay acuerdos reales entre los usuarios y desarrolladores. </li></ul></ul><ul><ul><li>No se ha realizado ningún tipo de verificación que posibilite determinar si los desarrolladores han comprendido las exigencias de los usuarios. </li></ul></ul><ul><li>Los Requerimientos no se han priorizado </li></ul><ul><ul><li>No se ha hecho ningún estudio costo-beneficio, ni de ningún otro tipo que posibilite la definición de prioridades y/o cronogramas basados en los requerimientos. </li></ul></ul>
  16. 16. Problemas con los Requerimientos <ul><li>Requerimientos incompletos </li></ul><ul><ul><li>El listado de los requerimientos no incluye cosas que son necesarias para que el software funcione. </li></ul></ul><ul><li>Requerimientos contradictorios </li></ul><ul><ul><li>Unos requerimientos parecen contradecir a otros requerimientos. Si el software cumple a cabalidad con algunos requerimientos, ni puede cumplir con los otros. </li></ul></ul>
  17. 17. Problemas con los Requerimientos <ul><li>Requerimientos ambigüos </li></ul><ul><ul><li>Existen múltiples interpretaciones para el requerimiento. Cada usuario y/o desarrollador puede entender algo distinto. (Puede no existir ningún acuerdo). </li></ul></ul><ul><li>Requerimientos de Desarrollador. </li></ul><ul><ul><li>El desarrollador introduce requerimientos que no fueron solicitados por el cliente, y que hacen díficil satisfacer los requerimientos reales. (Presunciones de Diseño). </li></ul></ul>
  18. 18. Problemas con los Requerimientos <ul><li>¿Cómo solucionar el problema? </li></ul><ul><ul><li>Un proceso disciplinado que busque determinar y solucionar los diferentes problemas de los requerimientos. </li></ul></ul><ul><ul><li>Un sistema de especificaciones que posibilite comunicar y negociar los requerimientos eficientemente con los usuarios. </li></ul></ul>
  19. 19. Procesos de Requerimientos <ul><li>En la actualidad, a diferencia de los métodos tradicionales, existe una separación marcada entre los procesos de requerimientos y de análisis de requerimientos. </li></ul><ul><li>Existen varias opciones en torno a los procesos de Requerimientos </li></ul><ul><ul><li>Ingeniería de Requerimientos </li></ul></ul>
  20. 20. Procesos de Requerimientos <ul><li>Aplicando UML y Patrones, Larman </li></ul>Declaración de Trabajo Listado de Casos de Uso Casos de Uso Esenciales Casos de Uso Reales Prototipos
  21. 21. Procesos de Requerimientos <ul><li>Use Case in Context, Kulak </li></ul>Declaración de Trabajo Listado de Casos de Uso Casos de Uso Fachada Casos de Uso Terminados Prototipos Listado de Actores Casos de Uso Completos Casos de Uso Enfocados
  22. 22. Procesos de Requerimientos <ul><li>RUP </li></ul>Visión de Producto Casos de Uso Especificación con Casos de Uso Prototipos Glosario de Términos
  23. 23. Procesos de Requerimientos <ul><li>Iconix </li></ul>Declaración de Trabajo Casos de Uso Prototipos
  24. 24. Proceso de Requerimientos <ul><li>El prototipo es el mecanismo para “revisar” las especificaciones de requerimientos. </li></ul><ul><li>La Especificación es el mecanismo para “formalizar” los acuerdos entre desarrolladores y usuarios. </li></ul>
  25. 25. Proceso de Requerimientos <ul><li>Algunos métodos y autores sugieren comenzar con la definición de los prototipos </li></ul><ul><ul><li>¿Será conveniente? </li></ul></ul><ul><ul><li>¿Qué pasa si el usuario no sabe “a ciencia cierta” que es lo que quiere? </li></ul></ul><ul><li>La realización de los prototipos puede ser un “arma de doble filo”. </li></ul>
  26. 26. Especificación de Requerimientos <ul><li>La Especificación es: </li></ul><ul><ul><li>El documento final que detalla, de manera completa y no ambigüa, los requerimientos del software a desarrollar. </li></ul></ul><ul><ul><li>El proceso de construcción de ese documento. </li></ul></ul>
  27. 27. Especificación de Requerimientos <ul><li>La Especificación puede realizarse de acuerdo a estándares internacionales reconocidos o a formatos de métodos formales de Ingeniería de Software </li></ul><ul><ul><li>ANSI/IEEE </li></ul></ul><ul><ul><li>NSA NASA </li></ul></ul><ul><ul><li>RUP </li></ul></ul><ul><ul><li>Otros. </li></ul></ul>
  28. 28. Agenda <ul><li>Levantamiento </li></ul><ul><li>Analisis </li></ul><ul><li>Especificación </li></ul><ul><li>Validación </li></ul>
  29. 29. Requerimientos <ul><li>“ El desarrollo de requerimientos puede ser subdividido en : Levantamiento, Analisis, Especificación y Verificación” Thayer and Dorfman 1977. </li></ul><ul><li>Cada etapa deberá contar con tecnicas claras, estandares, metodos y herramientas que permitan madurar los pasos del proyecto. </li></ul>
  30. 30. Requerimientos <ul><li>Escribir una buena especificación de requerimientos. </li></ul><ul><li>Validaciones y acuerdos con los usuarios </li></ul><ul><li>Validación del entendimiento del problema. </li></ul>Metas y Objetivos
  31. 31. Requerimientos Desarrollo de requerimientos HERRAMIENTAS Y ESTANDARES TECNICAS DE IDENTIFICACION DE REQTS METODOS DE ESPECIFICACION DE RQTS METODOS DE DOCUMENTACION VALIDACION EXCELENTES REQUERIMIENTOS
  32. 32. Requerimientos <ul><li>Los requerimientos son: “Una especificación de lo que deberia ser implementado. Ellos son descripciones de cómo el sistema deberia comportarse o son tambien un atributo o propiedad del sistema. Ellos pueden ser una restricción o condición en el proceso de desarrollo del sistema” (Sommerville and Sawyer 1977). </li></ul><ul><li>Es indispensable que todos y cada uno de los requerimientos esten, excelentemente definidos, claros y validados. </li></ul>Conceptos
  33. 33. Requerimientos <ul><li>Como saber si una especificaión de requerimientos es buena o tiene problemas ? </li></ul>Calidad
  34. 34. Requerimientos <ul><li>Necesarios </li></ul><ul><li>No ambiguos </li></ul><ul><li>Verificables </li></ul><ul><li>Completos </li></ul><ul><li>Correctos </li></ul><ul><li>Viables </li></ul><ul><li>Priorizables </li></ul><ul><li>Consistentes </li></ul>Características de excelentes requerimientos
  35. 35. Requerimientos <ul><li>Deberá documentar algo que el usuario realmente necesita. </li></ul><ul><li>Cuando forma parte de un contrato firmado. </li></ul><ul><li>Es requerido por un estandar o por variables externas indispensables. </li></ul>Necesarios
  36. 36. Requerimientos <ul><li>Un requerimiento es NO AMBIGUO si todos los lectores pueden llegar a la misma interpretación “Escribalo en lenguaje natural, evitando terminos tecnicos, de ser necesario haga un glosario.” </li></ul>No ambiguos
  37. 37. Requerimientos <ul><li>Aplique metodos formales, para realizar pruebas que confirmen que el requerimiento esta correctamente especificado. </li></ul><ul><li>Utilice la documentación escrita sobre el tema para verificar el requerimiento </li></ul>Verificables
  38. 38. Requerimientos <ul><li>Requerimientos mal especificados podrian esconder información que no es facil de detectar. </li></ul><ul><li>Enfoquese en conocer las tareas del usuario, y no en sesgarse en las funciones que deberia tener el sistema. </li></ul><ul><li>Si Ud. Sabe que tiene información incompleta utilice marcas o banderas que le anuncien “TAREAS PENDIENTES”. </li></ul>Completos
  39. 39. Requerimientos <ul><li>Es mas facil implementar requerimientos cuando se conocen las limitaciones tecnicas, la capacidad, y las condiciones que rodean el ambiente del proyecto. </li></ul><ul><li>Para detectar requerimientos “NO VIABLES” es importante incluir dentro del equipo de analisis un miembro de la parte tecnica o de ingenieria, asi como un miembro del dominio del problema. </li></ul>Viables
  40. 40. Requerimientos <ul><li>Cada requerimiento indica una funcionalidad o condición que debe contener el software. </li></ul><ul><li>No podemos contar con interpretaciones incorrectas sobre funcionalidades. </li></ul><ul><li>Un usuario representativo puede determinar si un requerimiento es correcto o no. </li></ul>Viables
  41. 41. Requerimientos <ul><li>Si todos los requerimientos tienen el mismo nivel de prioridad, esto es un sintoma de mala especificación . </li></ul><ul><li>Cada requerimiento o conjunto de ellos debe poderse distribuir en las diferentes releases o versiones del producto. </li></ul><ul><li>Si todos los requerimientos son de “alta prioridad”, problemas para incluir nuevos . </li></ul>Priorizables
  42. 42. Requerimientos <ul><li>Los requerimientos deben estar acordes con las reglas del negocio y con las variables externas que afectan el dominio del problema. </li></ul><ul><li>Si un requerimiento tiene conflicto con otro requerimiento  problema de especificación. </li></ul>Consistentes
  43. 43. Requerimientos <ul><li>Si no llega a un acuerdo con el usuario y sigue considerandolo NECESARIO, ESCALE EN NIVEL ORGANIZACIONAL O EN DOMINIO DEL PROBLEMA. </li></ul><ul><li>Presente modelos similares y resultados obtenidos del mismo dominio u otros dominios </li></ul><ul><li>Si continua considerando que aun es AMBIGUO, valide con otros miembros del dominio diferentes a la fuente. </li></ul><ul><li>Arme un grupo hectereogeneo de discusión de ambiguedades. </li></ul>Problemas ?  Estrategias
  44. 44. Requerimientos <ul><li>Si no lo considera lo suficientemente VERIFICABLE, apoyese en bibliografia y teorias. </li></ul><ul><li>Busque expertos externos en el dominio. </li></ul><ul><li>Busque una formula que lo lleve al resultado esperado. </li></ul><ul><li>Si considera que aun no es CORRECTO, diseñe una encuesta con formato cerrado de respuesta. </li></ul>Problemas ?  Estrategias
  45. 45. Requerimientos <ul><li>Si considera que aun no es VIABLE, busque opinion de terceros que tengan un buen nivel de credibilidad. </li></ul><ul><li>Justifique en terminos economicos ($). </li></ul><ul><li>Si no lo ha podido PRIORIZAR, elabore una tabla para que el usuario asigne una priorida unica a cada requerimiento. </li></ul><ul><li>Escale con la tabla. </li></ul><ul><li>Si considera que aun no es CONSISTENTE, reuna las fuentes y plantee la problematica </li></ul>Problemas ?  Estrategias
  46. 46. Requerimientos <ul><li>Analice los documentos “fuentes” (resultados de las reuniones con los usuarios). </li></ul><ul><li>Extraiga las sentencias que contienen las palabras : DEBERÁ , DEBE. </li></ul><ul><li>Identifique sentencias que impliquen requerimientos. </li></ul><ul><li>Identifique sentencias de tipo VERBOS, ACCIONES Y UN RESULTADO. </li></ul><ul><li>Haga una lista de FUNCIONALES Y NO FUNCIONALES. </li></ul>Identificación de requerimientos
  47. 47. Requerimientos <ul><li>Vital para el entendimiento. </li></ul><ul><li>Buena redaccion facilita buena interpretacion. </li></ul><ul><li>Redaccion estandar facilita comprension. </li></ul><ul><li>Buena redaccion, facil validacion. </li></ul><ul><li>TODOS LOS REQUERIMIENTOS DEBEN TENER EL </li></ul><ul><li>MISMO ESTILO DE REDACCION </li></ul>Redacción de requerimientos - IMPORTANCIA
  48. 48. Requerimientos <ul><li>“ El sistema en el modulo de ventas debe ofrecer una opción mediante la cual el usuario pueda ver una comparacion de lo presupuestado versus la venta real en un rango de fechas ” </li></ul>Modelo de redacción de requerimientos NUEVOS
  49. 49. Requerimientos <ul><li>“ Cuando el tiempo de conexión exceda el valor predeterminado como maximo, el sistema debe cancelar la selección informandole a el usuario que el tiempo se agoto y por lo tanto sera desconectado ” </li></ul>Modelo de redacción de requerimientos NUEVOS Lugar tiempo evento objeto Debe, deberá, no debe, no deberá A quien Sujeto Acción verbo sentencia
  50. 50. Requerimientos <ul><li>“ En el reporte de mercados objetivos, al aplicarle filtros por asesor y zona, muestra la informacion en desorden, se debe corregir de tal forma que salga ordenado por numero de cedula del asesor y agrupado por zona ” </li></ul>Modelo de redacción de requerimientos ERRORES –MODIFICACIONES - MEJORAS Lugar tiempo evento objeto Debe, deberá, no debe, no deberá A quien Sujeto Acción verbo sentencia
  51. 51. Requerimientos <ul><li>Mantenga sentencias y parrofos cortos. </li></ul><ul><li>Apropiada gramatica, ortografia y puntuación. </li></ul><ul><li>Haga un glosario. </li></ul><ul><li>Utilice terminos consistentes definidos en el glosario. </li></ul><ul><li>El sistema debe, deberá.. Seguidas de una acción. </li></ul><ul><li>Para evitar ambiguedades no use : amigable, facil. Simple, rapido, fuerte, superior, aceptable, robusto. </li></ul><ul><li>Si encuentra “y” , “o”, “etc”, esto puede representar varios requerimientos. </li></ul>Al escribir requerimientos TENGA EN CUENTA
  52. 52. Requerimientos <ul><li>Requerimos que en el momento de realizar una factura a credito, que el sistema automaticamente despliegue la pantalla de recaudo, donde el vendedor deberá digitar el valor del recaudo para esa factura. Ese valor de recaudo deberá ser igual al valor de la factura que acabo de crear, y ademas las opciones de pago que deberan aparecer deben ser solo las de cheque postfechado o credito firmado. De igual forma el sistema valida si el vendedor tiene autorizacion para recibirle cheque a ese cliente y si no la tiene debe esconder la opción de cheque postfechado. Cuando acabe de grabar ese recaudo, el valor no deberá afectar su cartera, y si se recibio cheque, esa informacion del cheque deberá ser guardada para que sea impresa en la factura que se va a grabar. </li></ul>Ejemplo para párrafos narrativos.
  53. 53. Administracion de Requerimientos <ul><li>Contar con una herramienta que permita la administración adecuada de los requerimientos. </li></ul><ul><li>RTM (Trace Matrix Requeriments). Ejemplo Asist Web </li></ul><ul><li>?? Existen herramientas comerciales para la ADM de requerimientos. Cuales ?? </li></ul>
  54. 54. Requerimientos <ul><li>Clasificarlos </li></ul><ul><li>Especificarlos </li></ul><ul><li>Priorizarlos </li></ul>Análisis de requerimientos
  55. 55. Requerimientos <ul><li>La clasificación ayuda a determinar que requerimientos se desarrollan o no. </li></ul><ul><li>Es una propuesta que permite ACOTAR el desarrollo de los requerimientos. </li></ul><ul><li>Nos ayuda a tomar en cuenta todos los requerimientos pero a enfocarnos en los FUNCIONALES. </li></ul><ul><li>Para clasificarlos se deben tomar en cuenta los diferentes tipos de requerimientos. </li></ul>Clasificación de requerimientos
  56. 56. Requerimientos <ul><li>SW (Software Requeriment) </li></ul><ul><li>SWC (Software Constraint) </li></ul><ul><li>DR (Deriverd Requeriment) </li></ul><ul><li>D# (Duplicated Requeriment) </li></ul><ul><li>HW (Hardware Requeriment) </li></ul><ul><li>NTH (Nice To Have) </li></ul><ul><li>P (Performance Requeriment) </li></ul>Clasificación de requerimientos
  57. 57. Requerimientos <ul><li>SW (Software Requeriment). Aquellos que representan una funcionalidad en el software. Son los que se construyen en el producto </li></ul>Clasificación de requerimientos
  58. 58. Requerimientos <ul><li>SWC (Software Constraint). Ayudan al analista a incluir condicionamientos, que pueden generar dificultades a la hora de contruir el software. </li></ul>Clasificación de requerimientos
  59. 59. Requerimientos <ul><li>DR (Deriverd Requeriment). Un requerimiento que se deriva de otro que ya existe. Se deriva por DETALLE o por CONSECUENCIA. </li></ul>Clasificación de requerimientos
  60. 60. Requerimientos <ul><li>D# (Duplicate Requeriment). Esta caracteristica o tipificación permite que este requerimiento no se DESARROLLE. </li></ul>Clasificación de requerimientos
  61. 61. Requerimientos <ul><li>HW (Hardware Requeriment). Esta caracteristica representa que este requerimiento no necesariamente tendra opciones de CÓDIGO. O que este requerimiento implica funcionalidad en un HARDWARE “es parte del proyecto” </li></ul>Clasificación de requerimientos
  62. 62. Requerimientos <ul><li>NTH (Nice To Have). Esta tipificación sirve para identificar aquellos requerimientos que estan por fuera del alcance del proyecto. Se podran tener en cuenta en futuras versiones “NO SE DESARROLLA” </li></ul>Clasificación de requerimientos
  63. 63. Requerimientos <ul><li>P (Performance Requeriment). Esta caracteristica ayuda al analista a generar PRECONDICIONES o cualidades especificas en el diseño, para cumplir con un requerimiento de rendimiento. </li></ul>Clasificación de requerimientos
  64. 64. Requerimientos <ul><li>La mayoria de los equipos de desarrollo son conscientes de que los requerimientos deben ser priorizados. </li></ul>Priorización de Requerimientos

×