levantamiento de requerimiento

of 14 /14
30/04/2015 1 Ingeniería de Software Levantamiento de Requisitos Vicky Latorre C. Levantamiento de Requisitos Entrevista Otras Técnicas Anexos Puedes Leer la Mente ? Entrevistas y Levantamiento de Requisitos Si la respuesta es NO …entonces Entrevistas y Levantamiento de Requisitos La Ingeniería de Requisitos es aquel conjunto de técnicas que ayuda a los ingenieros de software a entender mejor el problema en el que trabajarán. ¿Cuál es el corazón de la Ingeniería de Requisitos? Un conjunto de tareas guía. ¿A que conduce ese conjunto de tareas? Cuál será el impacto del software sobre el negocio. Qué es lo que el cliente quiere. Cómo interactuarán los usuarios finales con el software. Roger S. Pressman

Author: germansanchez

Post on 17-Dec-2015

70 views

Category:

Documents


0 download

Embed Size (px)

DESCRIPTION

ingeneria en software

TRANSCRIPT

  • 30/04/2015

    1

    Ingeniera de SoftwareLevantamiento de Requisitos

    Vicky Latorre C.

    Levantamiento de Requisitos

    EntrevistaOtras Tcnicas

    Anexos

    Puedes Leer la Mente?

    Entrevistas y Levantamiento de Requisitos

    Si la respuesta es NO entonces

    Entrevistas y Levantamiento de Requisitos

    La Ingeniera de Requisitos es aquel conjunto de tcnicas que ayuda a los ingenieros de software a entender mejor el problema en el que trabajarn.

    Cul es el corazn de la Ingeniera de Requisitos? Un conjunto de tareas gua.

    A que conduce ese conjunto de tareas?

    Cul ser el impacto del software sobre el negocio.

    Qu es lo que el cliente quiere.

    Cmo interactuarn los usuarios finales con el software.

    Roger S. Pressman

  • 30/04/2015

    2

    Entrevistas y Levantamiento de Requisitos

    Porque es importante?

    Programas elegantes

    resolviendo

    Los problemas

    incorrectos.

    Primero hay que

    entender

    Exactamente lo que el cliente

    quiere antes de

    comenzar a disear.

    Y cmo se aplica?

    Siguiendo una serie de pasos, tareas o fases.

    Comenzando por una fase de inicio

    y terminando con la coincidencia entre la

    concepcin del problema que tiene el ingeniero de software

    y la percepcin del cliente.

    Entrevistas y Levantamiento de Requisitos

    Cliente-Usuario lo que digo no es realmente lo que quiero

    decirTu peor pesadilla

    Y el problema es que

    El dinero es quizs lo ms importante en el desarrollo de proyectos informticos

    El dinero esta en peligro, adems no olvidemos que la reputacin esta en juego

    Entrevistas y Levantamiento de Requisitos

    Ralph Young

    Otro detalle importante

    Se pierde el tiempo con la Ingeniera de requisitos?

    NO se pierde! Es realmente un punto importante que no debe omitirse.

    Roger S. PressmanRalph Young

    Gestin de

    Requisitos en

    CMMI(www.sei.cmu.edu/cmmi/models/)

  • 30/04/2015

    3

    Entrevistas y Levantamiento de Requisitos

    Que Hacer?

    identificar y delimitar el problema a resolver.

    Todo aporta... Las entrevistas son una parte importante de esto.

    Tambin hay otros recursos complementarios: formularios, sistemas legados, etc.

    1.-Inicio

    Entrevistas: Introduccin

    Entrevistas y Levantamiento de Requisitos

    Sirven

    para:1. Conocer, clarificar, o limitar el problema a

    resolver.

    2. Identificar a los actores involucrados.

    3. Construir la confianza del cliente.

    4. Establecer los requisitos del sistema sinambigedades.

    5. Validar el trabajo ya hecho.

    Las entrevistas son el primer paso, en el desarrollo de un proyecto de software.

    Entrevistas y Levantamiento de Requisitos

    ConsideracionesPrimera

    entrevista abierta (como para abordar

    el tema) y revisarla (si es

    posible en grupo).

    Segunda entrevista focalizada,

    diseada para sacarle el resto de la

    informacin al cliente.

    Se pueden hacer ms

    entrevistas si es necesario.

    Haga la MENOR

    CANTIDAD POSIBLE de entrevistas.

    Graben las entrevistas.

    Entrevistas: Introduccin

    1.-Inicio

    Entrevistas y Levantamiento de Requisitos

    Consideraciones

    Revisar los tems ms

    importantes (respecto a

    los requisitos) con el cliente

    (se debe obtener un

    OK).

    Validen con los usuarios, los requisitos entregados

    por el cliente.

    Usuarios y clientes deben

    estar alineados.

    Usuarios y Clientes deben

    sentirse parte del proceso.

    Trabajen rpido y

    focalizados.

    Traigan y analicen todos los

    recursos que puedan:

    formularios, sistemas legados,

    manuales de procesos, etc.

    Entrevistas: Introduccin

    1.-Inicio

  • 30/04/2015

    4

    1.-Inicio

    Una conversacin informal

    Necesidad de negocios

    Se descubre un nuevo mercado

    Entrevistas: Introduccin

    Entrevistas y Levantamiento de Requisitos

    Preguntas libres de contexto

    Comprensin bsica del problema en cuestin

    Objetivo principal

    1.-Inicio

    Entrevistas: Introduccin

    Entrevistas y Levantamiento de Requisitos

    Entre 30 y 1 hora.

    Vestirse igual (o similar) al cliente.

    Dos entrevistadores (mximo).

    Slo uno pregunta, el otro toma nota.

    Llevar una pauta, con las preguntas.

    1.-Inicio

    Entrevistas: Introduccin

    Detalles sobre Entrevistas

    Grabar cada entrevista (audio).

    Obtener copia de todos los formularios involucrados en el proceso.

    Trigase el modelo de datos actual (detallado), en caso de existir sistemas legados.

    Llevar lpiz y papel, aunque no lo use (podra necesitarlo).

    No use jerga computacional, ni regionalismos.

    Trate al cliente con respeto SIEMPRE !!!

    No trate de demostrar cunto sabe usted de esto: la estrella es el Cliente !!!

    Escuche las opiniones del cliente, aunque sean descabelladas.

    No repita las preguntas, siempre primero revise la cinta de sesiones anteriores.

    1.-Inicio

    Entrevistas: Introduccin

    Detalles sobre Entrevistas

    Demustrele al cliente que ha comprendido su problema.

    No critique las falencias de los actuales sistemas, ni las del personal que lo construy o que lo opera.

    Si va a pedir algo que requiere un esfuerzo importante del cliente y/o usuario, entrgueles algo a cambio.

    Ganarse a la secretaria del cliente, es casi tan importante como ganarse al cliente.

  • 30/04/2015

    5

    Todo lo anterior.

    Entrevista abierta (guiada por el cliente).

    Que el cliente diga todo lo que tenga que decir.

    Seamos Positivos, hasta conocer ms el problema

    1.-Inicio

    Primera Entrevista

    Detalles sobre Entrevistas

    No prometamos nada hasta analizar elproblema en detalle. CONTENGMONOS!

    La primera entrevista se usa para tener unaidea aproximada del problema a resolver.

    Normalmente se obtiene mucha basura, por loque hay que separar la paja, del trigo

    Traigmonos toda la documentacin que podamos, para poder analizar mejor el problema a resolver, determinar su alcance e implicancias sobre otros sistemas.

    formularios actuales,

    modelo de datos,

    cantidad y tipo de usuarios del sistema,

    recursos de hardware y software que forman parte del ambiente operacional,

    restricciones del desarrollo (plazos, leng. de desarrollo o BD a utilizar, Browsers usados para Front-End, etc.)

    Entre la informacin que debemos traer de la 1 entrevista (dentro de lo posible) est:

    1.-Inicio

    Primera Entrevista

    Entrevistas y Levantamiento de Requisitos

    1.-Inicio

    Primera Entrevista

    Entrevistas y Levantamiento de Requisitos

    Preguntar si hubo gente que intent hacer esto antes?

    En caso afirmativo -> Qu pas?

    En caso Negativo - > Veamos si se hizo algo de este tipo, y cmo les fue?

    Trate de ver (con cuidado) cules son riesgos de este proyecto.

    Establezca claramente el nivel compromiso y dedicacin que el Cliente/Usuario deber tener con el proyecto

    Segunda/Tercera Entrevista

    Casi todo lo anterior.....

    Entrevista focalizada (guiada por el entrevistador).

    Se utiliza para completar la informacin relevada y clarificar aspectos oscuros.

    El cliente debe mantenerse en la lnea de lo que es relevante.

    Sea Realista, cueste lo que cueste.

    Entrevistas y Levantamiento de Requisitos

  • 30/04/2015

    6

    Entrevistas de Validacin

    Validar los requisitos conflictivos (al menos una vez).

    Validar todo lo que usted considere necesario, ... pero con cuidado...

    Validar el avance del proyecto, a travs de prototipos (buenos prototipos !!!).

    Valide slo lo que est escrito en los requisitos.... Cualquier otra cosa est fuera de lo que usted debe realizar.

    El tiempo del cliente tambin vale ....

    Entrevistas y Levantamiento de Requisitos

    Sea efectivo y directo en las entrevistas.

    Instlele el software (prototipo) al cliente, si esnecesario, y asegrese de que los prototipos seanvalidados.

    El cliente/usuario debe tener una manera fcil dereportar lo que le gusta y lo que no.

    El uso de prototipos involucra una etapa de entrenamiento queusted debe ofrecer, e incluir en el presupuesto.

    El cliente/usuario debe estar consciente de sucompromiso/dedicacin al proyecto.

    Entrevistas de Validacin

    Entrevistas y Levantamiento de Requisitos

    Qu debe hacer el sistema?,

    Determinacin de los servicios del

    sistema

    Quines y cuntos son los usuarios?,

    Qu debera hacer cada uno con el

    sistema?

    Determinacin de los Usuarios del

    sistema.

    Qu calidad se espera que tenga el

    software?.

    Determinacin de los req. de calidad

    del software.

    Cules son los formularios que

    actualmente contienen la

    informacin a procesar por el

    sistema?

    Determinacin de datos y servicios

    bsicos a manejar por el sistema.

    Qu Cosas Preguntar (por ej.)?

    Entrevistas y Levantamiento de Requisitos

    Cul es el escenario en el que funcionar

    el sistema?.

    Determinacin del Ambiente Operacional.

    Qu datos estn

    involucrados en el sistema?.

    Determinacin del mbito del

    sistema.

    Existen restricciones a

    cerca del funcionamiento o del proceso de

    desarrollo del sistema?

    Determinacin de Restricciones.

    ... Cada una de estas preguntas

    pueden ser desglosadas en

    varias ...

    Qu Cosas Preguntar (por ej.)?

    Entrevistas y Levantamiento de Requisitos

  • 30/04/2015

    7

    Las entrevistas sirven para construir confianza / acuerdos entre el proveedor y los clientes/usuarios.... aprovchelas!!!

    Preprese MUY BIEN para cada entrevista... Su imagen y la de su empresa depende en gran medida de ello.

    Demuestre que usted es serio, y que sabe hacer su trabajo.

    Demuestre compromiso con el proyecto.

    Aclare y limite el problema (junto con el cliente)... Y luego pngalo por escrito (docum. de requisitos), y que el cliente lo firme!!!

    Conclusiones

    Entrevistas y Levantamiento de Requisitos

    Sea cuidadoso al consultar, ... pero no se quede con ninguna duda.

    Sea efectivo en su trabajo

    No pierda tiempo, ni improvise.

    Documente todos los acuerdos, y ojal que stos sean pblicos (para clientes/usuarios y desarrolladores).

    Genere y mantenga una visin compartida del proyecto.

    No a las justificaciones

    No a las crticas.

    Conclusiones

    Entrevistas y Levantamiento de Requisitos

    Tcnicas de elicitacin grupalReuniones

    Extensiones de entrevista. Muy activas. De corta duracin e intensas con un determinado foco

    - Braisntorm: lluvia de ideas

    - Workshop de requisitos: existe un moderador - JAD(Join application design): se avanza en un principio de construccin, ms organizado

    y racional con generacin de documentos, compromisos, fechas.

    Favorecen la aparicin de mltiples opiniones, creacin, feedback y consenso colectivo.

    Puede haber dispersin, incomodidad en el grupo, pensamiento generado a nivel de grupo. Altos costos.

    Otras Tcnicas de Levantamiento de Requisitos

    Tcnicas de recoleccin

    Prototipacin

    se puede usar cuando hay un alto grado de incertidumbre en cuanto a los requisitos o cuando se necesitan un temprano feedback de los stakeholders.

    Se puede combinar con otras tcnicas, por ejemplo usar un prototipo para provocar una discusin y feedback en una tcnica de elicitacin grupal o ser la base para un cuestionario anlisis de protocolo.

    Otras Tcnicas de Levantamiento de Requisitos

  • 30/04/2015

    8

    Tcnicas de recoleccin

    Tcnicas guiadas por modelos

    proveen un modelo especfico del tipo de informacin que se va a recolectar y usan ese modelo para dirigir la actividad de elicitacin. Ej.: mtodos orientados a objetivos como KAOS, o mtodos basados en escenarios como CREWS.

    Otras Tcnicas de Levantamiento de Requisitos Tcnicas cognitivas

    Tcnicas originalmente desarrolladas para la adquisicin de conocimiento para sistemas basados en conocimiento.

    Anlisis de protocolo

    se analiza al experto mientras este describe como hace su tarea. Se intenta captar la racionalizacin utilizada en la ejecucin de una tarea.

    Ventajas: obtiene una directa verbalizacin de las tareas cognitivas. Embebida en el contexto de trabajo, bueno para revelar problemas de interaccin con sistemas existentes.

    Desventajas: se enfoca solo en la performance, desconociendo aspectos sociales, se basa en lo que dice y no lo que hace.

    Card Sorting

    se pide a expertos que ordenen cartas (con descripciones de objetos de un dominio) y expliquen el porqu de ese orden

    til para la clasificacin del conocimiento pero presupone un conocimiento de las entidades de un dominio.

    Otras Tcnicas de

    Levantamiento de Requisitos

    Observacin

    El ingeniero se convierte en espectador del proceso.

    Ventajas: revela detalles obviados por otras tcnicas, fcil de ejecutar

    Desventajas: depende de la visin del espectador. Gran consumo de tiempo. La rica descripcin que se obtiene es difcil de procesar.

    Tcnicas de recoleccin

    Otras Tcnicas de

    Levantamiento de Requisitos

    Enfoque antropolgico (Tcnicas de etnografa)

    se integra con el medio ambiente, el analista se convierte en el cliente..

    Ventajas: visin de dentro para afuera, muy contextualizada

    Desventajas: consume mucho tiempo, poca sistematizacin.

    Tipos de Tcnicas de recoleccin

    Otras Tcnicas de

    Levantamiento de Requisitos

  • 30/04/2015

    9

    Tcnicas sociales

    enfocndose en los aspectos sociales y no en la tecnologa, demanda muchos recursos y tiempo.

    Buena en el largo plazo,

    Ej. anlisis de conversacin que identifica patrones en las conversaciones e interacciones

    Tipos de Tcnicas de recoleccin

    Otras Tcnicas de

    Levantamiento de Requisitos

    Ingeniera reversa

    Requiere que haya un sistema existente con documentacin (o cdigo) disponible.

    Desventajas: no refleja la actualizacin de la informacin, informacin muy detallada ( a un bajo nivel)

    Tipos de Tcnicas de recoleccin

    Otras Tcnicas de

    Levantamiento de Requisitos

    Reuso

    Debe haber componentes reutilizables disponibles, se debe definir lo que se va a reutilizar, necesita de mecanismos de recuperacin.

    Anlisis de dominio

    Si bien favorece la calidad y la productividad, no siempre es fcil de lograr en la realidad.

    Tipos de Tcnicas de recoleccin

    Otras Tcnicas de

    Levantamiento de Requisitos

    Tcnicas de Elicitacin

    Que tcnicas usar?

    Depende de la situacin, clientes,

    recursos.

    Se debe analizar el contexto y respetar

    limitaciones Integracin

    Tcnicas de Levantamiento

    de Requisitos

  • 30/04/2015

    10

    Resumen de lo visto

    Antes que llevemos a cabo las actividades de diseo y construccin de un sistema basado en computadora, es

    necesario entender, formular, determinar, negociar y validar los

    requisitos.

    Es como querer empezar a levantar paredes, colocar el techo de una casa

    que construyamos sin haber levantado los cimientos adecuados, pues si esto se olvida, la casa se vendr abajo; lo

    mismo ocurre con un proyecto de software cuyos requisitos no estn bien

    hechos.

    Para establecer requisitos adecuados en un proyecto, debemos llevar a cabo de forma paralela varias actividades. Para ello empezamos escuchando lo

    que el cliente quiere, o por ese momento, lo que el cliente cree querer, as como establecer las

    restricciones del proyecto

    Extras

    Muy importante: Es lo mismo?

    Son iguales?

    Ingeniera de Requisitos

    Anlisis de Requisitos

    Extras Ingeniera de Requisitos

    Es aquel conjunto de tcnicas que ayuda a

    los ingenieros de software a entender mejor

    el problema en el que trabajarn.

    Anlisis de Requisitos

    Es aquel que genera la especificacin de caractersticas operacionales de software

    ; Indica la interfaz del software con otros elementos del sistema, y establece las

    restricciones que debe tener el software.

    El Ing. de Software se extiende sobre requisitos bsicos establecidos en la Inge-

    nieria de requisitos.

    Extras

  • 30/04/2015

    11

    41

    Caso de la vida real 1.

    Cliente con poco tiempo.

    Cliente mentiroso.

    Desarrolladores cmodos.

    Mala relacin con el cliente

    El cliente ha amenazado conacciones legales.

    El proyecto ha cambiadomucho.

    El cliente se tomo las cosaspersonales.

    El proyecto se ha vuelto undesafi

    Consecuencias de no aplicar la Ingeniera de requisitos adecuadamente.

    Extras

    42

    Caso de la vida real 2.

    Cliente abusador.

    Cliente paranoico.

    Desarrolladorestemperamentales.

    Mala relacin con el cliente.

    El cliente no nos dejo respirar.

    Reciba de 7 a 15 emails diarios yde 5 a 6 llamadas diarias.

    El cliente cambio de parecermuchas veces.

    El cliente llamaba a las 10/11 dela noche al celular.

    Consecuencias de no aplicar la Ingeniera de requisitos adecuadamente.

    Extras

    43

    Requisitos del softwareImportancia de los requisitos

    Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe realizarse.

    Unos requisitos bien elaborados y validados con el cliente evitan descubrir al terminar el proyecto que el sistema no era lo que se peda.

    Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearn para su validacin.

    Resulta muy difcil demostrar al cliente que el producto desarrollado hace lo que el pidi si su peticin no est documentada y validada por l.

    Base objetiva para la estimacin de recursos (coste, personal en nmero y competencias, equipos y tiempo)

    Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras apuestas. Las estimaciones en el fondo son clculos de probabilidad que siempre implican un margen de error; por esta razn disponer de la mayor informacin posible reduce el error.

    Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.)

    Ms all de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas sobredimensionados o con serias deficiencias de rendimiento.

    Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y malentendidos.

    Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repeticin de partes ya desarrolladas, etc.

    Beneficios de los buenos requisitos.

    Extras

    44

    Requisitos del softwarePropiedades de los buenos requisitos

    Cada requisito debe poder implementarse dentro de las capacidades ylimitaciones conocidas del sistema y su entorno. El director tcnico debercomprobar la viabilidad de los requisitos antes de comprobar el documento.

    Posibles

    Un requisito es necesario si es algo:

    que el cliente realmente necesita

    requerido para la conformidad con un requisito

    requerido para la conformidad con un interfaz, externo o estndar.

    Para evitar requisitos innecesarios, el cliente debe valorar cada funcionalidad y como afectar al sistema si est o no.

    Necesarios

    Extras

  • 30/04/2015

    12

    45

    Requisitos del softwareImportancia de los requisitos

    Sus defectos repercuten en todas las fases

    REQUISITOS

    Estimacin Planificacin Diseo Construccin V & V

    Los errores en los requisitos se comportan como una enfermedad contagiosa que siempre repercute en todas las fases del proyecto.

    Estimacin: No es posible estimar con rigor costes y recursos necesarios para desarrollar algo que no seconoce.

    Planificacin: No se puede confiar en la planificacin para el desarrollo de algo que no se sabe biencomo es.

    Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en restricciones ofuturas evoluciones, producen arquitecturas que ms tarde se confirmarn como errneas y sernmodificadas.

    Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de prueba y error quederrochan horas y paciencia de programacin sobre patrones de recodificacin continua yprogramacin heroica.

    Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones tienen errores debulto, o peor an, no estn reflejadas en una especificacin de requisitos, no ser posible validar elproducto con el cliente.

    Extras

    46

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Implicacin insuficiente

    del cliente

    Requisitos crecientes

    y cambiantes

    Requisitos ambiguos

    Requisitos

    innecesarios

    Requisitos mnimos

    (insuficientes)

    Requisitos mnimos

    (insuficientes)

    Omisin de las necesidades

    de grupos de usuarios

    Problemas en la validacin

    del producto obtenido

    Degradacin de la estructura

    y arquitectura del producto

    Prdida de tiempo en

    re-codificacin

    Trabajo innecesario

    Problemas en la validacin

    del producto obtenido

    Error en la estimacin

    y planificacin

    Usuarios insatisfechos

    Extras

    47

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Algunos clientes no comprenden la importancia detrabajar con rigor en la obtencin de los requisitos, paragarantizar la calidad de los resultados.

    Tambin es frecuente que los desarrolladores prefierancomenzar a trabajar en la construccin del sistema,porque les resulta ms atractivo que reunirse con elcliente.

    Hay situaciones en las que resulta difcil encontrarrepresentantes del cliente que conozcan a fondo elproblema, o que por tratarse de un sistema o negocionuevo, nadie en el entorno del cliente tenga claras todaslas funcionalidades que se necesitan.

    Implicacin insuficiente del cliente

    Extras

    48

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Requisitos crecientes y cambiantes

    Independientemente del punto del ciclo de vida en que nos encontremos, el sistema cambiar y la

    tendencia al cambio persistir a lo largo de todo el ciclo de vida Software Configuration Management,

    Prentice-Hall, 1980.

    Es normal que los requisitos evolucionen durante el desarrollo del sistema, pero los cambios deben partir de una descripcin inicial correcta, y gestionarse convenientemente, midiendo su

    impacto en la planificacin del proyecto, y consensundolo con todos los participantes.

    La evolucin de los requisitos durante el desarrollo de los proyectos puede incrementar o modificar funcionalidades ya implementadas, desbordando los

    costes y agendas planificados.

    Extras

  • 30/04/2015

    13

    49

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Requisitos crecientes y cambiantes

    Partir de una especificacin de requisitos incompleta incrementar el nmerode modificaciones que sufrir el proyecto durante el desarrollo.

    Si los desarrolladores han diseado un sistema que no corresponde con lasexpectativas del cliente, la introduccin sistemtica (generalmente con agendasapretadas, o sin modificar las agendas iniciales), generar parches deprogramacin, con insercin de cdigo adicional que puede trastocar principiosbsicos de diseo y degradar la arquitectura del sistema obteniendo finalmenteun producto con serias deficiencias tcnicas.

    [1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.

    Extras

    50

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Requisitos ambiguosLa ambigedad es un defecto habitual de las descripciones de requisitos.Si lectores diferentes obtienen interpretaciones diferentes, o si un lector puedeinterpretar los requisitos de formas diferentes, stos son ambiguos.La ambigedad crea expectativas diferentes entre las partes del proyecto, y hace que losdesarrolladores programen funcionalidades que no se ajustan a lo que los usuariosnecesitan.

    La consecuencia inevitable de este problema es la re-programacinLa reprogramacin puede consumir ms del 40% del coste total de un desarrollo y se haestimado que hasta un 85% de las revisiones pueden deberse a errores en los requisitos[1]

    .Para evitarla hay que confirmar que se comparte la visin obtenida con la que tienen lasdiferentes fuentes de requisitos, y que los distintos participantes obtienen la mismainterpretacin de la documentacin de requisitos.

    [1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.

    Extras

    51

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Requisitos innecesariosEs frecuente la tendencia de algunos desarrolladores a incluir funcionalidades que nofiguran en la especificacin de requisitos, con la suposicin de que los usuarios loagradecern. Muchas veces los usuarios no les encuentran utilidad y quedan finalmenteprogramadas pero sin uso, suponiendo un coste de desarrollo innecesario.Las sugerencias y posibilidades aportadas por el equipo de desarrollo pueden descubrirmejoras importantes para el cliente o los usuarios, pero no deben implementarse sinconsultarlas y validarlas previamente.

    Desde el punto de vista del equipo de desarrollo la mejor perspectiva es respetar lasencillez y funcionalidad, y no ir ms all de los requisitos, sin la aprobacin del cliente.Tambin es frecuente que el cliente pida funcionalidades que a primera vista puedenparecer necesarias, pero que en realidad no aaden funcionalidad al producto, y que sinembargo suponen un esfuerzo importante de desarrollo. Identificar estas funcionalidades,y pensar dos veces si realmente se necesitan puede ahorrar trabajo innecesario

    Extras

    52

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Requisitos insuficientes (mnimos)

    Muchas veces el cliente tiene tan slo el concepto general del producto que desea, y no comprende por qu es tan importante detallar los requisitos.

    La tentacin en estos casos es partir de una descripcin mnima, o incluso de una explicacin verbal, e ir preguntando y revisando a los programadores conforme el desarrollo avanza.

    Esta forma de trabajo puede resultar apropiada slo para la construccin de sistemas experimentales o prototipos, pero en general suele terminar con la frustracin de los desarrolladores y el desconcierto y desesperacin del cliente.

    Este planteamiento tambin genera la situacin muy frecuente de contar a los desarrolladores la idea general de un nuevo producto, para pedirles una estimacin del tiempo necesario para desarrollarlo.

    Extras

  • 30/04/2015

    14

    53

    Requisitos del softwareImportancia de los requisitos

    Los defectos comunes en los requisitos y sus consecuencias.

    Omisin de las necesidades de algunos

    grupos de usuariosEntre los usuarios de un sistema es

    frecuente que se incluyan grupos de personas con necesidades diferentes, que empleen

    funcionalidades distintas, e incluso que presenten diversos perfiles de

    experiencia y conocimientos.

    Al identificar las posibles fuentes de requisitos hay que localizar todos los posibles usuarios y obtener informacin de sus

    caractersticas, necesidades y expectativas.

    Extras

    1.- Inicio

    2- Obtencin

    3.-Elaboracin

    4.- Negociacin

    5.-Especificacin 6.-Validacin

    7.-Gestion de requisitos

    Ingeniera de Requisitos PASOS, TAREAS O FASES

    Extras