Ingeniería de Requerimientos Administración de Requerimientos.
Clase 04a requerimientos introduccion
-
Upload
demian-gutierrez -
Category
Technology
-
view
718 -
download
1
Transcript of Clase 04a requerimientos introduccion
1
Ninguna de las ideas expresadas en este curso debe considerarse una verdad absoluta que es aplicable a
todos los escenarios existentes
Por el contrario, la aplicabilidad de estas ideas depende del contexto
en el que se apliquen, del proyecto a desarrollar, del proceso de
desarrollo, etc.
“Pre-portada” (-2)
2
Olvide usted que está en un curso de Ingeniería del Software, imagine que tiene a un cliente enfrente, y que este cliente necesita un
software...
Asumo que usted sabe programar al menos.Imagine y describa todo lo que ocurre desde
que usted conoce al cliente hasta que termina el trabajo y le entrega su software
¿cómo haría para solucionar el problema?
“Pre-portada” (-1)
3
¿cómo haría para solucionar el problema?
para crear una solución, primero es necesario tener clarotener claro y comprendercomprender el problema...
“Pre-portada” (0)
4
REQUISITOS / REQUERIMIENTOS¡todo lo que el cliente quiere,exactamente lo que quiere,
a como de lugar y a cualquier precio!
Universidad de Los AndesDemián Gutierrez
Febrero 2013
5
Requisitos / Requerimientos
¿qué es un requisito?
6
Requisitos / Requerimientos
Los requisitos expresan lo que el sistema debe hacer para satisfacer las necesidades de sus clientes o
usuarios
“es un aspecto de un sistema o una descripción de aquello que el sistema es capaz de hacer a fin de
cumplir su propósito”[Pfleeger, 1998]
“Un requerimiento es un servicio que el sistema de software debe satisfacer o una restricción bajo la
cual el sistema debe operar”[Sommerville 2002]
si me lo preguntan, en lo personal, pienso que...
7
...es algo que el sistema debe ser capaz de hacer (o una restricción que debe cumplir) para que pueda cumplir su propósito y satisfacer a
sus usuarios
un requisito...
8
Lo que el cliente quiere que haga...
Todo lo que el cliente quiere que haga...
Nada más que lo que el cliente quiere que haga...
Los requerimientos se concentran en el cliente y el problema a resolver
Requisitos / Requerimientos
Definen (o deberían definir)sobre el sistema:
9
Es decir, dejen de pensar por los momentos en cómo los van a programar o implementar...
¡Los requisitos se concentran en “qué”
debe hacer el sistema, no en
“cómo” debe hacerlo!
Requisitos / Requerimientos
10
¿Qué Definen los Requisitos?
Las funciones que debe ejecutar
Los datos que debe capturar y
almacenar
La información que debe producir
La interfaz gráfica usuario-sistema (GUI)
La plataforma de operación del sistema (Hardware / Software)
La tecnología de información que debe usar
Las interfaces con otros sistemas
Seguridad, facilidad de uso, documentación,
utilidad, etc.
Aplicación
Interacción Usuario / Sistema
Restricciones de Operación
Atributos de Calidad
Requisitos
11
De Usuario
De Sistema
Tipos de Requisitos
Funcionales
No Funcionales
Dependiendo si definen o no funcionalidad
Dependiendo de a quienes están
dirigidos
¿Qué Tipos de Requisitos?
12
Requerimientos Funcionales / No Funcionales
La funcionalidad o los servicios que se espera que el sistema de software proveerá
La interacción entre el sistema de software y su ambiente o contexto
Como el sistema deberá actuar bajo ciertos estímulos o eventos
Los requerimientos Funcionales Describen:
13
Requerimientos Funcionales / No Funcionales
R-010:
El sistema debe permitir el registro de nuevos usuarios en el foro, los nuevos usuarios deben ser aprobados o rechazados
por un moderador antes de poder publicar mensajes
Ejemplos de Requerimientos Funcionales:
R-200:
Los usuarios deben poder intercambiar mensajes y comunicarse por medio del foro, toda la comunicación debe
estar moderada para evitar conductas inapropiadas por parte de los usuarios, mensajes basura y publicidad no deseada
14
Requerimientos Funcionales / No Funcionales
No se refieren directamente a las propiedades funcionales del sistema, sino a sus propiedades emergentes o a
restricciones adicionales en el sistema o en el proyecto de desarrollo de software.
Definen restricciones adicionales al sistema, tales como: Proceso de desarrollo a utilizar, herramientas, lenguaje de programación, limitaciones de presupuesto, de tiempo, de
interfaz, etcétera
Los requerimientos no Funcionales:
¿Propiedades Emergentes?
15
Requerimientos Funcionales / No Funcionales
Son aquellas que resultan del sistema como un todo y que es muy difícil o imposible atribuirle a un componente particular de
éste.
Por ejemplo, la fiabilidad, tiempo de respuesta, usabilidad, capacidad de almacenamiento, etcétera
Propiedades Emergentes:
El todo no siempre es la simple suma de sus partes...
16
Requerimientos Funcionales / No Funcionales
R-430:
El sistema debe ser utilizable por medio de una interfaz WEB
Ejemplos de Requerimientosno Funcionales:
R-233:
Se debe utilizar RUP como proceso de desarrollo del software
R-230:
El tiempo de respuesta del sistema al solicitar un reporte nunca debe ser mayor a 10 segundos
17
Clasificación de Requerimientos no funcionales(no interpretar literalmente, es sólo a modo de referencia)
Fuente: Sommerville 2002
Requerimientos Funcionales / No Funcionales
18
Tipos de Requisitos (Clasificaciones)
De Usuario
De Sistema
Tipos de Requisitos
Funcionales
No Funcionales
Dependiendo si definen o no funcionalidad
Dependiendo de a quienes están
dirigidos
19
Requerimientos de Usuario / de Sistema
Requerimientos de Usuario:
Son aquellos que están dirigidos a los usuarios y clientes del sistema (interesados en general).
Se redactan usando lenguaje natural (generalmente) de forma “no técnica” con el objetivo de que el
personal no técnico los pueda entender
Requerimientos de Sistema:
Son aquellos dirigidos a personal técnico: analistas, programadores, arquitectos, ingenieros, etcétera.
Generalmente están escritos en un lenguaje mucho más técnico pero mucho más preciso que los
requerimientos de usuario
20
Requerimientos de Usuario / de Sistema
Documento de Especificación de Requerimientos (DER)
Es el documento en el que usualmente se especifican los requerimientos de usuario
Documento de Definición de Requerimientos (DDR)
Es el documento en el que usualmente se especifican los requerimientos de sistema
21
Requisitos / Requerimientos
nuevamente...
¿por qué son importantes los
requisitos?
22
Requisitos
Requisitos incompletos
Falta de participación del usuario
Expectativas poco realistas
Cambios en los requisitos y las especificaciones
El sistema dejó de ser necesario
Se estima que un alto porcentaje de proyectos de desarrollo de software fallan por:
23
Requisitos
Hoy en día la Ingeniería de Requisitos se considera una etapa clave en el
desarrollo de software
Actualmente, se considera que la satisfacción de los clientes es la mejor
métrica de calidad de un sistema
24
El Costo del Cambio (de requisitos)
Tomado del Taller de Ingeniería de Requisitos V 4.06, Ceisoft, Marzo 2006
Fase
Requerimientos 0
1
2
Codificación 3
5
Validación 20
100
Costo($)
DiseñoArquitectónico
DiseñoDetallado
Pruebasde Unidades
Puestaen Marcha /Operación
sin embargo, los métodos ágiles en generaldesafían este punto de vista
25
¿Por qué tienen éxito losproyectos de software?
Tomado del Standish Group Report (1995)
¡¡¡Dos de las tres primeras causasestán asociadas a los requisitos!!!
Factores de éxito en el Proyecto % Respuestas
1 Usuarios involucrados con el proyecto 15,90%
2 Soporte de los Ejecutivos 13,90%
3 Requerimientos Claros 13,00%
4 Planificación Adecuada 9,60%
5 Expectativas Realistas 8,20%
6 Hitos pequeños y poco espaciados en el tiempo 7,70%
7 Personal competente 7,20%
8 Control sobre el proyecto por parte del personal 5,30%
9 Visión clara y objetivos 2,90%
10 Trabajo duro, personal enfocado y comprometido 2,40%
11 Otras 13,90%
100,00%
Encuesta realizada a Gerentes Ejecutivos del área deDesarrollo de Software y TICs
26
¿Cuáles han sido las mayoresamenazas en un proyecto de software?
¡¡¡Las tres primeras causasestán asociadas a los requisitos!!!
Encuesta realizada a Gerentes Ejecutivos del área deDesarrollo de Software y TICs
Factores que amenazaron el Proyecto % Respuestas
1 Falta de información de los usuarios 12,80%
2 Especificación de requerimientos incompleta 12,30%
3 Requerimientos y especificación compleja 11,80%
4 Falta de soporte ejecutivo 7,50%
5 Mala tecnología, mal uso de la tecnología 7,00%
6 Falta de recursos 6,40%
7 Expectativas poco realistas 5,90%
8 Objetivos poco claros 5,30%
9 Tiempos de desarrollo poco realistas (planificación) 4,30%
10 Tecnología nueva (desconocimiento) 3,70%
11 Otras 23,00%
100,00%
Tomado del Standish Group Report (1995)
27
¡¡¡Dos de las tres primeras causasestán asociadas a los requisitos!!!
¿Por qué fallan losproyectos de software?
Factores que acabaron/cancelaron el Proyecto % Respuestas
1 Falta de información de los usuarios 13,10%
2 Especificación de requerimientos incompleta 12,40%
3 Falta de recursos 10,60%
4 Expectativas poco realistas 9,90%
5 Falta de soporte ejecutivo 9,30%
6 Requerimientos cambiantes 8,70%
7 Falta de planificación 8,10%
8 El proyecto no se necesito más 7,50%
9 Falta de gestión adecuada de IT 6,20%
10 Problemas tecnológicos 4,30%
11 Otras 9,90%
100,00%
Encuesta realizada a Gerentes Ejecutivos del área deDesarrollo de Software y TICs
Tomado del Standish Group Report (1995)
28
Requisitos / Requerimientos
bien... pero...¿cómo se obtienen
los requisitos?
29
Requisitos
Proceso de establecimiento de los servicios que debe proporcionar un
sistema, así como de las restricciones sobre las cuales debe operar
Ingeniería => Enfoque Sistemático
¿Ingeniería de Requisitos?
30
Procesos de la Ingeniería de Requisitos
Captura Análisis ValidaciónEspecificación
Una visión:
Otra visión (Según Pfleeger):
... y hay otras...(ver Sommerville cap. 6 / Pressman cap. 7)
Análisisdel
Problema
Descripcióndel
ProblemaPrototipado
Documentacióny Validación
Elicitación y Análisis Definición yEspecificación
31
Procesos de la Ingeniería de Requisitos
Es la actividad por medio de la cual se obtienen (capturan) los requerimientos
ObservaciónDirecta
EntrevistasModelo deNegocios
Lectura /Análisis de
DocumentosOtras...Prototipos
Captura Análisis ValidaciónEspecificación
32
Procesos de la Ingeniería de Requisitos
¿Quién está detrás de la solicitud de este trabajo? (Clientes)
¿Quién usará la solución? (Usuarios)
¿Cuál será el beneficio económico de una solución exitosa?
¿Existe otra fuente para la solución requerida?
Tomado de Pressman 2005 / cap 7
33
Procesos de la Ingeniería de Requisitos
¿Cómo podría caracterizarse un buen resultado generado por una solución? (¿Cómo sé que una
solución es buena?)
¿Cuáles problemas debería atacar la solución?
¿Podría usted mostrar o describir el ambiente de negocios en el que se utilizará la solución?
¿Hay aspectos o restricciones especiales del rendimiento que afecten la manera de enfocar la
solución?
Tomado de Pressman 2005 / cap 7
34
Procesos de la Ingeniería de Requisitos
En este punto, cuando el cliente ya está hablando, uno se transforma en “pepito
preguntón”:
¿Por qué?¿Y por qué?
¿Qué es esto?¿Y esto otro?
¿Cómo hacen esto?¿Y esto otro?
¿Quién hace esto?...
Opinión personal
35
Procesos de la Ingeniería de Requisitos
¿Es usted la persona adecuada para contestar esta pregunta? ¿Sus respuestas son oficiales?
¿Mis preguntas son relevantes para su problema?
¿Estoy haciendo demasiadas preguntas?
¿Alguien más puede proporcionar información adicional?
¿Debería preguntarle alguna otra cosa?
Tomado de Pressman 2005 / cap 7
36
Procesos de la Ingeniería de Requisitos
¿Cómo se soluciona el problema actualmente?
¿Entre que bandas de costos se debería mover una solución para ser rentable?
... otras de seguro ...¿Se le ocurre alguna?
Opinión personal
37
Procesos de la Ingeniería de Requisitos
Recuerde:
Una vez que comprenda algo, repitalo al cliente con sus propias
palabras, y si éste lo entiende, entonces usted estará seguro de que
lo ha entendido correctamente
Opinión personal
38
Procesos de la Ingeniería de Requisitos
Consejo:Nunca vaya a una reunión de negocios o a una entrevista de requerimientos sólo.
¡Dos es un número mágico!¿Por qué cree usted que esto es así?
Consejo:Tome notas / grabe la entrevista de ser posible, y mantenga las grabaciones
para futuras referencias
Opinión personal
39
Procesos de la Ingeniería de Requisitos
Es la actividad por medio
de la cual se extiende el
modelo de requisitos, se
buscan y localizan
errores, inconsistencias,
limitaciones, carencias,
etcétera...
Discusiones,Entrevistas,
Talleres
Inspeccionesde Documentos
Muchas de lastécnicas de la actividad
de captura
Desarrollo deprototipos
Captura Análisis ValidaciónEspecificación
40
Procesos de la Ingeniería de Requisitos
Captura Análisis ValidaciónEspecificación
Es la actividad por medio de la cual se documentan (escriben / se ponen en “blanco y
negro”) los requerimientos
Documentode Definición deRequerimientos
Documentode Especificación de
Requerimientos
¡Si los requerimientos no están por escrito(de alguna manera), entonces NO SIRVEN!
41
Procesos de la Ingeniería de Requisitos
Captura Análisis ValidaciónEspecificación
Es la actividad por medio de la cual se VALIDAN los requerimientos con el cliente
Discusiones /Entrevistas /
Talleres
Inspeccionesde Documentos
Muchas de lastécnicas de la
actividadde captura
!Esta actividad es crítica. Si los requerimientos no se han validado, entonces NO SIRVEN!
42
Requisitos / Requerimientos
¿quiénes participan en la ingeniería de requerimientos?
43
Participantes en el Desarrollo de Software
CLIENTE /EJECUTIVO /
USUARIO (Patrocina el desarrollo del
sistema y utiliza el sistema)
DESARROLLADOR(Construyeel Sistema)
¿seránel cliente y
el usuario la misma persona
en todos los casos?
44
Participantes en el Desarrollo de Software
CLIENTEEJECUTIVOS(Patrocina el
desarrollodel sistema)
USUARIO(Utiliza elSistema)
DESARROLLADOR(Construyeel Sistema)
TieneObligacionesContractuales
ProporcionaFinanciamiento
ProporcionaSistemas de
Software
TieneNecesidades
Pfleeger(1998)
45
Participantes en el Desarrollo de Software
Clientes
Usuarios
Otros entes, personas,
instituciones, afectadas o
interesadas en el sistema
DESARROLLADOR(Construyeel Sistema)
Otros desarrolladores y participantes en el
proyecto
A todas las personas
involucradas o interesadas se
les llama Stakeholder
46
Interesados / Actores / Protagonistas(Stakeholders)
Líderes deproyecto
diseñadores
InstitucionesGubernamentales
Gerentes
analistas
Consultores /asesores
EmpresaContratante
Usuarios
programadores
Consumidores
Clientes
arquitectosClientes dela Empresa
Proveedores
Comunidad
47
Requisitos / Requerimientos
¿problemascon los requisitos?
¡DILBERT!
48
Requisitos (Problemas de los)
¡Para poder desarrollar software senecesitan usuarios, comprometidos,
disponibles (e involucrados en el desarrollo)!
49
Requisitos (Problemas de los)
El cliente / usuario no siempre sabe o tiene claro lo que quiere
El cliente / usuario no se compromete con el proyecto
Se dan malas interpretaciones en los requerimientos¿Ha jugado usted alguna vez al “telefonito”?Usuario -> Cliente /Ejecutivo -> Analista ->
-> Especificación -> Diseño -> Implementación -> Usuario
Los requisitos cambian constantemente(El cliente / usuario cambia de idea constantemente)
Fenómeno del “analista sabelotodo”: El analista cree que sabe que es lo que necesita el cliente y por lo tanto no le consulta
50
Requisitos (Problemas de los)
El cliente / usuario no entiende a los analistas(Lenguaje técnico del analista)
Los analistas no entienden al cliente / usuario(Lenguaje asociado al dominio del cliente / usuario)
¿qué es el dominio del cliente?¿dominio de aplicación?
Requisitos que: No reflejan las necesidades reales del cliente, son inconsistentes, incompletos, no factibles, etcétera
Requisitos que el cliente no necesita realmente
51
Requisitos (Tres Leyes)(Según Demián Gutierrez)
Primera Regla:El usuario siempre tiene la razón
(Aunque se le puede intentar convencer de lo contrario)
Segunda Regla:El cliente siempre tiene la razón, siempre y cuando esto no
contradiga lo establecido en le primera regla
Tercera Regla:Usted (el desarrollador) tiene la razón, siempre y cuando esto
no contradiga la segunda o la primera regla
¿Conoce usted las tres leyes de la robótica de Asimov?
52
¡Ley Cero!
Ante la duda, siempre consulte al usuario / cliente involucrado
¡Nunca dé nada por sentado!
Requisitos (Tres Leyes)(Según Demián Gutierrez)
53
Gracias
¡Gracias!