Levantamiento De Requerimiento
-
Upload
germansanchez -
Category
Documents
-
view
89 -
download
0
description
Transcript of Levantamiento De Requerimiento
-
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