Requisito Funcional y sus niveles de granularidad

(1)

FATTO Consultoría y Sistemas - www.fattocs.com

FATTO CONSULTORIA Y SISTEMAS

GUILHERME SIQUEIRA SIMÕES 21/02/2017

Requisito Funcional y sus niveles de

granularidad

(2)

De preferencia al uso de una conexión de banda ancha

Este evento no tendrá video (webcam), solamente la presentación y audio

Si es necesario, ajuste el idioma de la sala en la barra de herramientas superior Tendrá una duración de ~45 min. de presentación y ~15 min. finales para preguntas Puedes enviar tus preguntas por el chat durante la presentación

Para aquellos que poseen certificación PMP, el webinar otorga un crédito de 1 PDU La grabación y material serán publicados posteriormente en nuestra página web y redes sociales:

(3)

FATTO Consultoría y Sistemas

3

 Misión: “Ayudar nuestros clientes a planificar y controlar mejor sus

proyectos de software.”

 Consultoría y Entrenamiento en Medición, Estimación y

Requerimientos de Software:

– Puntos de Función (IFPUG, NESMA , COSMIC) – Estimaciones de proyectos de software

– Ingeniería de Requerimientos

– Medición y auditoría en medición de software

– Análisis de productividad en proyectos de software

 El libro más vendido de FPA en Brasil fue escrito por nosotros

(4)

Cursos FATTO

FPA: Fundamentos, Beneficios e Implantación

8 horas (EAD y presencial)

Capacitación en FPA: Medición y Estimación

de Software

16 horas (EAD y presencial)

Workshop FPA: Metodología y Prácticas de Medición 16 horas (presencial) Ingeniería de Requerimientos de Software 24 horas Estimación de Proyectos de Software con COCOMOII 16 horas Taller de Medición de Puntos de Función Sesiones de 8 ~ 40 horas Medición y Estimación de Software con el Método

COSMIC 16 horas (presencial) Taller de Requerimientos Sesiones de 8 ~ 40 horas Preparación para el Examen CCFL (COSMIC)

(5)

Agenda

5

 Requisitos Funcionales y Requisitos No Funcionales

 Nivel de granularidad

 Requisito funcional con objetivo agregado

 Requisito funcional con objetivo de usuario

 Requisito funcional con objetivo de sub-función

(6)

Dimensiones de la especificación de

requisitos

Describen lo que el software hace:

procesos o tareas que apoyan una

práctica o procedimiento de uno usuario

Expresan atributos o restricciones inherentes a los requerimientos funcionales y como ellos serán atendidos

No Funcional “el cómo”

“el qué” Funcional

(7)

Nivel de granularidad del RF

7

 Es la mayor o menor extensión de la descripción del

comportamiento del software en una especificación funcional

 Distintos momentos de un proyecto exigen distintos niveles de

granularidad de la especificación

– Momentos preliminares exigen una visión amplia del alcance

(8)

Las estrategias de desarrollo

Planificación • Hito Requerimientos • Hito Diseño • Hito Implementaci ón • Hito Prueba • Hito Despliegue Planificació n Requerimie ntos Diseño Implementaci ón Prueba Despliegue Planificación Requerimie ntos Diseño Implementaci ón Prueba Despliegue Planificación Requerimie ntos Diseño Implementac ión Prueba Despliegue

iteración #1 iteración #2 iteración #3

(9)

Requisitos Funcionales (RF)

9

 Describen lo que el software debe hacer en términos de las tareas o

servicio del usuario, sin abordar su implementación

 Ejemplos:

– El sistema debe realizar operaciones con la cuenta corriente – El sistema debe transferir o valor de una cuenta a otra cuenta – El sistema debe validar la tarjeta y contraseña del cliente

– El sistema debe garantizar que el total de transacciones del cliente en el día no ultrapase a $5.000

 Perciban que estos requerimientos funcionales tienen diferentes

(10)

Niveles de Objetivo de los RFs

(Granularidad)

Funcionales

Niveles de objetivo

agregado usuario

(11)

Requerimientos Funcionales

Objetivos Agregados

11

 Son RFs de objetivos más generales y están en un nivel de

cobertura con foco en procesos de negocio de alto nivel. Resumen un conjunto de tareas del usuario.

 Ej.: pagar cuentas, consultar saldos, transferir montos

 En momentos preliminares talvez buena parte de los

requerimientos funcionales identificados estén en ese nivel de objetivo

 Por lo tanto, algunos requerimientos funcionales en este nivel

tienen un comportamiento tan estándar que dispensan el detalle en

requerimientos de menor nivel. Un ejemplo son CRUDS (Create,

(12)

Requerimientos Funcionales

Objetivos de Usuario

 Están en el nivel de una única tarea bajo la responsabilidad de un

único individuo en un momento que tiene todo lo que precisa en el tiempo para que la tarea sea hecha esté disponible

 Al final de la tarea, el usuario cumple su objetivo, se queda

satisfecho, no hay nada más que hacer. Si un trabajo involucra más de un individuo, es porque hay más de una tarea presente

 Ejemplos:

– Efectuar retiro en la cuenta corriente – Pagar factura de tarjeta de crédito

(13)

Requerimientos Funcionales

Objetivos de Usuario

13

a. Describen una historia con el intercambio de información entre el

usuario y la solución en busca de un objetivo específico

b. Resultados pueden ser usados en otras tareas por

usuarios con otras

responsabilidades

c. Resultados pueden ser usados en otros

momentos

Objetivo de usuario:

(14)

Requerimientos Funcionales

Objetivos de Sub-función

 Análogo a los objetivos agregadores, sin embargo en sentido

inverso, hay requerimientos descritos en un nivel inferior a los de los objetivos del usuario: son pasos y reglas

(15)

Requerimientos Funcionales

Objetivos de Sub-función

15

 Un paso describe el comportamiento esperado por el sistema en el

intercambio de información con sus usuarios como parte de una tarea

 En ese mismo nivel de cobertura también están las reglas de

negocio

 Especificar en este nivel es interesante cuando hay comportamiento

compartido por varios RFs de nivel mayor. Esto convierte los

documentos de requerimientos más fáciles de adaptar a los cambios

 Ejemplos:

– Validar tarjeta y contraseña del cliente

(16)

¿Por qué Nivel de Granularidad?

 La evolución natural de los requerimientos es caminar de objetivos

más generales para más específicos y con mayor detalle

 En la especificación de requerimientos es improbable que se tenga

todos los RFs especificados en el mismo nivel de granularidad

 Percibir el nivel de granularidad ayuda al analista encontrar el detalle

adecuado para la especificación de requerimientos

(17)

 Obtener una visión amplia del alcance (sin la necesidad todavía de

detalles). Ej.: documento de visión, product backlog

– El RF especificado en el nivel de objetivo agregado es lo indicado – Los RFs en niveles más detallados pueden estar presentes, mas

limitados a los más críticos y relevantes para la necesaria comprensión del alcance por los usuarios

 Obtener una visión profundizada del alcance (en parte o todo). Ej.:

especificación de casos de uso, splitting de historias de usuario

– El RF especificado en el nivel de objetivo de usuario es lo más indicado – El RF en el nivel agregado significa trabajo de levantamiento pendiente – El RF en el nivel de sub-función es interesante para ayudar en la calidad

de la especificación (facilidad de cambios, consistencia, claridad).

Objetivos de la especificación

(18)

(19)

FATTO Consultoría y Sistemas - www.fattocs.com 19

PRÓXIMOS EVENTOS

• WEBINARS:

SNAP: El proceso de evaluación no funcional de software

Fecha: 21 de marzo de 2017 Inscripción: https://goo.gl/3dn3F0

Tutorial práctico del análisis de los puntos de función COSMIC de un app Google

Fecha: 18 de abril de 2017 Inscripción: https://goo.gl/oIiUlJ

• CURSOS SUGERIDOS:

Ingeniería de Requerimientos: Software orientado al negocio Modalidad: Online, duración de 24 horas, disponible por 45 días

(20)

¿PREGUNTAS?

¡Muchas gracias por la atención!

GUILHERME SIQUEIRA SIMÕES

E-mail: guilherme.simoes@fattocs.com

Linkedin: https://br.linkedin.com/in/guilhermesimoes/es Skype: guilherme.s.simoes