m
 

§ Identificación de Requerimientos
 Õ  m 



§"ual problema necesita ser resuelto? (identificar límites)
§ Donde está el problema? (el contexto o el dominio del mismo)
Ô
 §
A Quienes involucra el problema? (identificar los actores)




 § Por qué necesita resolverse? (identificar las metas de los actores)
  § "omo debería ayudar el soft? (tomar o colectar los escenarios
 posibles)
 § Para cuando debe estar resuelto? (identificar limitaciones de
 desarrollo)

§ Qué debemos tener en cuenta para resolverlo? (identificar



riesgos).
§ Adquirir suficiente conocimiento
§ "onvertirse en un experto del dominio del problema

UNPSJB - 2005 Ingeniería de Software - "lase 3 2

 Õ


   




§ Õécnicas tradicionales
§ Introspección § Grupos enfocados
§ Mirar hacia dentro del § Brainstorming
problema § JAD/RAD
§ Documentos existentes § Prototipación
§ Análisis de datos § Aproximación basada en
§ Entrevistas representación
§ Agenda abierta § Basada en objetivos
§ Estructuradas § Basada en escenarios
§ "uestionarios § Basadas en casos de uso
§ Adquisición en grupos

UNPSJB - 2005 Ingeniería de Software - "lase 3 3

"




§ ºentajas § Qué mirar?
§ Puede obtener información § Õendencias en la selección de
rápidamente de muchas ejemplos
personas § Õendencias en la selección de
§ Puede administrarse respuestas
remotamente § Ejemplos de tamaño chico (con
§ Puede obtener actitudes y poca significancia estadística)
características de los actores § Preguntas ambiguas (muchos
§ Desventajas que no contestan la misma
§ Puede obtener un contexto muy pregunta)
pobre del problema § ^


 


§ No hay entrevistas con usuarios 


UNPSJB - 2005 Ingeniería de Software - "lase 3 4

^



§ Difícil la comparación de
§ Õipos
respuestas
§ Estructuradas
§ Administrar las
§ Existe una agenda previa con entrevistas no es una tarea
temarios sencilla
§ Libres
§ Que mirar?
§ Agenda abierta, no hay
temarios previos § Preguntas sin respuestas
§ ºentajas § "onocimiento tácito

§ Ricas en adquisición de § El contexto de discusión

información § Actitud de los
entrevistados respecto de
§ Desventajas
los temas abarcados
§ Muchos datos cualitativos
difíciles de analizar

UNPSJB - 2005 Ingeniería de Software - "lase 3 5

" 
  



m
  



§ El problema es D como § SRS
comunicar los § ropósito
requerimientos al resto de § Comunicar los requerimientos de forma
clara
los interesados
§ Se explica el dominio de la aplicación y del
§ El SRS hace esto sistema que se va a desarrollar
§ ºeremos § Contractual
§ Es un elemento legal
§ como construirlo, § Expresa un acuerdo
§ los problema que pueden § ínea base para la subsecuente evolución
surgir, de productos
§ Estándares de construcción § Soporta testeo, verificación y validación de
sistemas
§ uede contener información para verificar
que se alcancen los requerimientos

UN SJB - 2005 Ingeniería de Software - Clase 3 6

m
  



§ Línea base para el control de § Desarrolladores y
cambios programadores
§ "ambio de requerimientos § Õienen que implementar los
§ Evolución del soft requerimientos
§ Audiencia D a quien se dirige § Õesters
§ Usuario, clientes § Determinan que
requerimientos han sido
§ Más interesados en los
alcanzados
requerimientos
§ No interesados en req. del soft § Administradores de
§ Analistas de sistemas
proyectos
§ Miden y controlan el proceso
§ Escriben especificaciones que
de análisis y desarrollo del
interactúan
sistema

UNPSJB - 2005 Ingeniería de Software - "lase 3 7

m
  



§ Quién lo escribe
§ El proveedor
§ Debe ser general para tener una buena selección de pedidos
§ Debe dejar de lado los pedidos no razonables
§ El oferente
§ Debe ser específico para demostrar credibilidad y competencia técnica
§ General para evitar sobre compromiso
§ El desarrollador seleccionado
§ Refleja el entendimiento del desarrollador
§ Base del desarrollo

UNPSJB - 2005 Ingeniería de Software - "lase 3 8

 "   
 



§ "onsiderar dos proyectos
§ Uno pequeño, 1 pgm, 6 meses (A)
§ El programador charla con el cliente y escribe hasta 5 páginas de
requerimientos
§ Gran proyecto, 50 programadores, 2 años (B)
§ Equipo de analistas modelan requerimientos, SRS 500 páginas.

d

 d



d
 
   
 
  



  
 
 
 
 





         !   
   


 
 "
  

 

!

 #D 
  #D 
 
 %
&
UNPSJB - 2005 $D Ingeniería de Software - "lase 3 $D  9
 "   
 



§ s ect s D § ecesari
§ c te er c sas e se re iere
§ ºali ez (c rrectit )
§ a ig
§ x resar l s re . ct ales § Ca a se te cia se lee e a s la f r a
§ C letit § Defi ir tér i sc f s se gl sari
§ s ecificar t l e el § ºerifica le
siste a ecesita y e e acer § Õest e satisfacció r ca a clie te D debe
§ es er a t as las e tra as existir
si les § "ada req. Es especificado con
§ C letit estr ct ral comportamiento
§ C siste cia § Entendible (claro)
§ Por especialistas no informáticos
§ c tra ecirse
§ Modificable
§ sar tér i s e a era
§ Debe mantenerse actualizado
c siste te

UNPSJB - 2005 Ingeniería de Software - "lase 3 10

 ^


 
 



§ Ruido § Referencia hacia delante
§ Õener texto poco relevante como § Utilizar un concepto aún no definido
contenido § Pensamiento deseado
§ Silencio § Õexto que define un rasgo que no puede
§ Rasgo importante no cubierto en el texto ser validado
§ Sobre especificación § Puzzles
§ Õexto que describe una solución más que § Desparramar requerimientos por todos
un problema lados y luego poner referencias cruzadas
§ "ontradicción § Requerimientos mal definidos
§ Õexto que define un rasgo de varias § No conforme a estándares
formas incompatibles entre ellas § Õerminología inventada o inconsistente
§ Ambigüedad § Escribir de manera hostil para el lector
§ Õexto que se interpreta de dos o más
formas diferentes

UNPSJB - 2005 Ingeniería de Software - "lase 3 11

× 

 
 



§ Planes de desarrollo del proyecto
§"osto, staff, esquemas, métodos, herramientas, etc.
§ El tiempo de vida del SRS es hasta el final de la fase de operación
§ Õiempo de vida del plan desarrollo es más corto
§ Planes de aseguramiento del producto
§ "alidad, º º, QA, test
§ Diseño
§ Requerimientos y diseños pensados para gente diferente
§ Análisis y diseño son áreas diferentes

UNPSJB - 2005 Ingeniería de Software - "lase 3 12

§
"

Análisis de texto

 


 § "ontinuidad de los requerimientos
§ Se pueden hacer análisis textuales del imperativos
SRS § Palabras como Dzsigue abajodz, Dzcomo siguedz, etc.
§ Mide la estructura del SRS
§ Medir la forma de construcción
§ Palabras débiles
§ Establecer normas para organismo § "ausan incertidumbre
§ Ej; NASA usa nueve indicadores § Ej. Adecuado, aplicable
§ Imperativo § Directivas
§ Identifica palabras como Dzdebedz, Dzes § Indicación a tablas, figuras
requeridodz, etc. § Mide calidad del documento
§ Se mide cuan explícito es el S"R § Õamaño
§ Opción § Líneas de texto, párrafos, hojas
§ Palabras como Dzpuededz, Dzopcionaldz,etc. § Estructura del texto
§ Mide las opciones que presenta S"R
§ Mide el número de identificadores de
§ Estadísticas de legibilidad sentencias
§ Número de estilos por palabra, número de § Especificación de profundidad
palabras por sentencia, etc.
§ Mide profundidad de subsecciones
§ Marca la estructura del SRS

UNPSJB - 2005 Ingeniería de Software - "lase 3 13

 ^    

§ El sistema deberá reportar al operador todas las fallas que se
originen en funciones críticas o que puedan ocurrir durante la
ejecución de secuencias críticas y para las que no haya planes de
recuperación

* 
  '  (  (  (  (
*       ( (   ( (
 '
)
        ( ( ( (
î


 
 

UNPSJB - 2005 Ingeniería de Software - "lase 3 14

"  


 
§ Revisar especificaciones en § Notación semiformal (tablas,
lenguaje natural gráficos)
§ Usar personal con diferentes § Lenguajes de especificación
bases de conocimiento formales
§ Incluir gente de soft, gente que
§ Explorar por redundancia
entienda el problema, y usuarios
§ Poner un requerimiento más de
§ El revisor debe ser diferente al
autor una vez ayuda al lector a
comprender
§ Usar lenguajes de especificación
§ Pero es redundancia
§ "onjunto restringido del idioma
§ Se debe usar una notación más
formal y no repetir.

UNPSJB - 2005 Ingeniería de Software - "lase 3 15

"  


 m
§ Modificabilidad
§ Bien estructurado, indexado, con referencias cruzadas
§ Sin redundancia
§ No es modificable si no es trazable
§ Õrazabilidad
§ "ada requerimiento se puede rastrear hasta su fuente
§ "ada requerimiento se puede rastrear hasta su implementación
§ Notación útil
§ Que lo haga fácilmente comprensible

UNPSJB - 2005 Ingeniería de Software - "lase 3 16

^
 ^^^ m
§ IEEE introduce un estándar de 5 § Partes de un SR"
pasos: § Está compuesto de
§ Revisión cuatro secciones cada
una con subsecciones
§ Describe aproximaciones
recomendadas para la
especificación de § Leer cuidadosamente el
requerimientos. paper DzIEEE práctica
§ Referencias recomendada para
§ A otros modelos IEEE especificación de Req. De
§ Definiciones softdz (paper Q)
§ "onceptos básicos para la § La especificación del
práctica del modelo trabajo integrador deberá
§ "onsideraciones para producir hacerse siguiendo esta
un buen SRS metodología
§ Secuencia de 8 pasos para lograr
ese fín

UNPSJB - 2005 Ingeniería de Software - "lase 3 17