Sesion 3 0 proceso sw requerimientos

El Proceso De Software:
Requerimientos

Lic. César Alcántara Loayza

Ciclo de Vida

Mas información sobre ciclo de vida ver: SEI Interactive,
http://www.sei.cmu.edu/interactive/
Features/1999/March/Background/Background.mar99.htm
CAL/ProcesoSW_Requerimientos

Antecedentes
 Los reportes CHAOS del Standish Group desde
1994 y 1997 establecieron que lo que contribuye
mas a las fallas en los proyectos están
relacionados con los requerimientos.
 En Diciembre de 1997, El diario Computer
Industry reportó sobre un estudio de Sequent
Computer Systems, Inc. De cerca de 500
Gerentes de IT en los U.S. Y U.K. En los que el
76 por ciento habian experimentado fallas en los
proyectos. La causa mas frecuente fue
“requerimientos cambiantes del usuario."

Requerimiento
 Un requerimiento de software se puede definir
como: una capacidad del software necesaria para
que el usuario resuelva un problema o alcance un
objetivo.
 Una capacidad de software debe ser encontrada
o poseida por un sistema o componente de
sistema para satisfacer un contrato,
especificación, estandar u otra documentación
formalmente impuesta.
 “una condición o capacidad que el sistema [en
construcción] debe satisfacer“.

Gestión de Requerimientos
La Gestión de requerimientos es:
 Un forma sistemática de obtener,

organizar y documentar los
requerimientos de un sistema.
 Un proceso que establece y mantiene

un acuerdo entre el cliente y el equipo
de proyecto acerca de los cambios de
requerimientos del sistema.


Gestión de requerimientos
 Mejorar el control de proyectos
complejos
 Mejorar la calidad del software y la
satisfacción del cliente. Saber que debe
construir y probar.
 Reduce los costos y demoras del
proyecto.
 Mejora la comunicación del equipo.

Gestión de requerimientos
 Es frecuentemente dificil decir como
hace el sistema lo que se supone debe
hacer. Esta dificultad se debe a la falta
de un hilo visible y consistente a lo
largo del sistema cuando ejecuta sus
tareas. En el proceso unificado los
casos de uso proporcionan aquel hilo
(thread) definiendo el comportamiento
que llevará a cabo el sistema.

Flujo de trabajo de Requerimientos


Problemas Requerimientos
Una lista de problemas relacionada con la gestión de los
requerimientos:
• Los requerimientos no siempre son obvios y provienen
de muchas fuentes.
• Los requerimientos no son siempre fáciles de
expresar claramente con palabras.
• Existe muchos tipos diferentes de requerimientos en
diferentes niveles de detalle.
• El número de requerimientos puede ser inmanejable si
no es controlado.

Problemas Requerimientos
• Los requerimientos están relacionados entre si, y con
otros entregables del proceso en una variedad de
formas.
• Los requerimientos tienen propiedad únicas o valores
propios. Por ejemplo, ellos no son igualmente
importantes tampoco igual de fáciles de hallar.
• Existen muchas partes interesadas y responsables, lo
que significa que los requerimientos necesitan ser
manejados por grupos de personas ínter funcionales.
• Los requerimientos cambian.
• Los requerimientos son sensibles al tiempo.

Analizar El Problema


Analizar El Problema
 Capturar un Vocabulario común.
 Desarrollar la visión.
 Encontrar actores y casos de uso.
 Desarrollar un plan para la gestión de
requerimientos.


Productos de las actividades
 Glosario
 Visión
 Modelo de casos de uso
 Plan para la gestión de requerimientos.
 Atributos de los requerimientos


Flujo de trabajo
El propósito del este flujo de trabajo es:
 Obtener un acuerdo sobre el problema

que se está resolviendo,
 Identificar a los stakeholders,

 Definir los límites del sistema, y

 Identificar restricciones impuestas

sobre el sistema.

Flujo de trabajo
El conjunto de Artefactos de Requerimientos captura y
presenta información usada en la definición de las
capacidades requeridas del sistema.


Comprender Necesidades De
Los Stakeholders


Flujo de actividades
 Capturar un vocabulario común
 Desarrollar la visión
 Obtener los requerimientos del
stackeholder.
 Encontrar actores y casos de uso.
 Manejar dependencias.
 Revisar los cambios requeridos.

Productos de las actividades
 Glosario
 Visión
 Requisitos de los stackeholders
 Especificaciones suplementarias


Definir El Sistema


 Capturar un vocabulario común
 Encontrar actores y casos de uso
 Manejar dependencias


Productos del trabajo
 Glosario


Manejar Alcance Del Sistema


Flujo de Actividades
 Manejar las dependencias
 Priorizar los casos de uso
 Revisar los cambios solicitados



 Visión


Refinar Definición Del Sistema


 Detallar cada caso de uso
 Detallar los requerimientos de SW
 Modelar las interfaces del usuario
 Prototipear las interfaces del usuario


 Casos de uso
 Especificación de los requerimientos de
software
 Storybard del caso de uso
 Prototipo de interfases de usuario
 Atributos de requerimientos

Manejo De Cambios En Los
Requerimientos


 Manejar dependencias
 Revisar solicitudes de cambio
 Revisar los requerimientos
 Estructurar el modelo de casos de uso
 Registro de la revisión


 Atributos de requerimientos


Técnica Gestión de
Requerimientos
 Analizar el problema
 Obtener un acuerdo sobre el problema a ser
resuelto.
 Identificar los stackeholders.
 Definir los límites del sistema.
 Identicar restricciones a imponerse sobre el
sistema.
 Comprender las necesidades del
Stakeholder.
 Fuentes : Clientes, socios, usuarios finales,
expertos del dominio, entre otros.

Requerimientos
 Es importante saber como determinar cuales deberian
ser las fuentes, como tener acceso y como obtener
información de ellas. Los individuos que sirven como
fuente primaria de esta información son los llamados
"stakeholders" en el proyecto.
 Las técnicas para obtener requerimientos incluyen
entrevistas, tormenta de ideas, prototipeo conceptual,
cuestionarios, y análisis competitivo. El resultado de
obtener requerimientos es una lista de requisitos o
necesidades que son descritos textual o gráficamente
y que tienen prioridades relativas entre si.


Requerimientos
 Definir el sistema
 Significa traducir y organizar las
necesidades comprendidas del
stakeholder en una descripción
significativa del sistema a desarrollar.
 El resultado de la definición del sistema es
una descripción del sistema tanto en
lenguaje natural como gráfico.


Requerimientos
 Manejar el alcance del sistema.
 El alcance de un proyecto esta definido por
conjunto de requerimientos asignados a el.
 Manejando el alcance del proyecto fijamos los
recursos disponibles (tiempo, personas y dinero)
 Es una actividad continua.
 Usando los atributos de los requerimientos, tales
como prioridad, esfuerzo, y riesgo, como base
para negociar la inclusión de un requerimiento es
una técnica particularmente útil para gestional el
alcance.


Requerimientos
 Refinar la definición del sistema.
 Inluye dos consideraciones clave:
desarrollar una descripción mas detallada
de la definición del alto nivel del sistema, y
verificar que el sistema cumple con las
necesidades del stakeholder y se
comporta como está descrito.


Requerimientos
 Manejar el cambio de requerimientos.
 Independientemente de cuan cuidadosamente
maneje sus requerimientos, ellos cambian.
 El cambio no es el enemigo, el cambio no
gestionado si lo es.
 Establecer una base de inicio, mantener la pista
histórica de cada requerimiento, determinar cuales
dependencias son importantes seguir (trazar),
establecer vínculos de trazabilidad entre items
relacionados y mantener el control de versiones.


Conceptos G. requerimientos
 Tipos de requerimientos
 Identificando los tipos de requerimientos, el equipo
puede organizar un gran número de requerimientos
en grupos significativos y mas manejables.
 Usualmente, un tipo de requerimiento puede ser
partido, o descompuesto en otros tipos. Las reglas
del negocio y las declaraciones de visión pueden
ser tipos de requerimientos de alto nivel de los
cuales se deriven los tipos de requerimiento de
necesidades del usuario, de características y de
producto.


Conceptos G. Requerimientos
 Equipos Interfuncionales


 Atributos multidimensionales
 Cada tipo de requerimiento tiene atributos, y cada
requerimiento individual tiene diferentes valores
de atributo. Por ejemplo, a los requerimientos
pueden asignarsele prioridades, identificarse por
la fuente y la lógica, delegarse a equipos
especificos dentro de un área funcional, dar una
denominación del grado de dificultad, o estar
asociado con una iteración particular del sistema.


 En tipos de requerimientos mas detallados, los
atributos de prioridad y esfuerzo pueden tener
valores más específicos (e.g., tiempo estimado,
lineas de código, etc.) con los cuales refinas mas
el alcance.
 Historia de cambios
 A medida que los requerimientos evolucionan, es
importante entender su historia: que ha cambiado,
porque, cuando, y aún cual autorización.


Requerimientos
 Para facilitar su manejo se debería hacer:
 Acordar un vocabulario común para el proyecto.
 Desarrollar una visión del sistema que describa el
problema a ser resuelto, asi como sus
características principales.
 Obtener las necesidades de los stakeholders en al
menos cinco areas importantes: funcionalidad,
facilidad de uso, confiabilidad, rendimiento, y
soporte.
 Determinar que tipo de requerimientos usar.
 Seleccionar los atributos y valores para cada tipo
de requerimiento.

Requerimientos
 Escoger los formatos en los que se describirán los
requerimientos.
 Identificar a los miembros del equipo que serán los
autores, contribuyentes, o simples revisores de uno o
mas tipos de requerimientos.
 Establecer un procedimiento para proponer, revisar y
resolver cambios en el requerimiento.
 Desarrollar un mecanismo para registrar las historia del
requerimiento.
 Crear reportes de avance y situación para los
miembros del equipo y la gerencia.


Requerimientos FURPS+
Existen muchas clases diferentes de requerimientos.
Una forma de categorizar es descrita por el modelo
FURPS+, Utilizando el acrónimo FURPS para
describir las categorías principales de requerimientos
con subcategorías como se muestra:
• Funcionality (funcionalidad)

• Usability (Facilidad de uso)

• Reliability (Confiabilidad)

• Performance, (Rendimiento) y

• Supportability (Soporte)


Requerimientos FURP+
El "+" en FURPS+ le ayuda a recordar que también
incluye otros requerimientos como:
• Restricciones de diseño,
• Requerimientos de implementación,
• Requerimientos de interface y
• Requerimientos físicos.


Los Requerimientos Funcionales especifican
acciones que un sistema debe ser capaz de ejecutar,
sin considerar restricciones físicas. Estos se
describen frecuentemente en un modelo de casos de
uso y en los casos de uso. Los requerimientos
funcionales especifican de esta forma el
comportamiento de entrada y salida de un sistema.


Los requerimientos funcionales pueden
incluir:
• Conjuntos de características,
• Capacidades, y
• Seguridad.


Facilidad de Uso (Usability)
Puede incluir categorías como :
• Factores de tipo humano,

• Ergonómicos y estéticos,

• Consistencia en las interfaces de usuario, y

• Materiales de entrenamiento y documentación del

usuario.
• Ayudas sensitivas al contexto y en línea.

• Asistentes.


Confiabilidad (Reliability) que se pueden
considerar:
• Frecuencia / severidad de fallas,

• Recuperabilidad,

• Predictibilidad,

• Exactitud y

• Tiempo medio entre fallas (MTBF).


Performance
Un requerimiento de rendimiento impone condiciones
sobre los requerimientos funcionales. Por ejemplo,
para una acción dada, pueden haber parámetros de
rendimiento:
• Velocidad

• Eficiencia,

• Disponibilidad,

• Exactitud,

• Throughput,

• Tiempo de respuesta,

• Tiempo de recuperación, o

• Utilización de recursos

Soporte puede incluir:
• Sujeto a prueba,
• Que se pueda extender,
• Que se pueda adaptar,
• Que se pueda mantener,
• Que sea compatible,
• Que sea configurable,
• Que se pueda aplicar servicio,
• Que sea instalable, o
• Que se pueda localizar (internacionalizar)


 El + indica:
 Restricciones de diseño
 Requerimientos de implementación:

Estandares necesarios.
 Lenguajes de implementación.
 Políticas de integridad de datos.
 Ambientes operacionales


 Requerimientos de intefaz especifican
 Un item externo con el cual el sistema debe
interactuar.
 Restricciones en el formato, tiempos y otros
factores, usados en la interacción.


 Requerimientos físicos – especifica
requerimientos de hardware (redes)
 Formas
 Tamaños
 Pesos

Material


Tabla de Requerimientos
LISTA DE REQUERIMIENTOS DEL SISTEMA: OVINSYSTEM

Nro. Requerimiento Clasificación Atributos
Prioridad Categoría Dificultad Visibilidad Riesgo
FURPS+ Precedencia
(A, M, B) (P, S, O) (A, M, B) (V,O) (A, M, B)

R1 Registrar identificacion de ovinos. F A P M V M
R2 Generar reporte de hembras y machos. F A P B V B R1
R3 Actualizar registro de empadre. F A P B V M R2
R4 Actualizar registros de preñadas. F A P B V M R3
R5 Registrar grado de preñez. F A P B V M R4
R6 Registrar ovejas transferidas. F A P B V B R5,R1
R7 Actualizar registro de nacimiento. F A P B V M R6
R8 Generar reporte de paricion. F A P B V B
R9 Actualizar registro de corderos. F A P M V B R8
R10 Registro de pre-pruber. F A P B V M R9
R11 Registro de corderos por tipo de saca F A P B V M R10


Sesion 3 0 proceso sw requerimientos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (13)

Similar a Sesion 3 0 proceso sw requerimientos

Similar a Sesion 3 0 proceso sw requerimientos (20)

Más de Julio Pari

Más de Julio Pari (20)

Sesion 3 0 proceso sw requerimientos