Sesion 3_0 Proceso Sw Requerimientos

8/3/2019 Sesion 3_0 Proceso Sw Requerimientos

1/54

El Proceso De Software:Requerimientos

Lic. Csar Alcntara Loayza


2/54

CAL/ProcesoSW_Requerimientos

Ciclo de Vida

Mas informacin sobre ciclo de vida ver: SEI Interactive,http://www.sei.cmu.edu/interactive/

Features/1999/March/Background/Background.mar99.htm
http://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htmhttp://www.sei.cmu.edu/interactive/Features/1999/March/Background/Background.mar99.htm


3/54


Antecedentes

Los reportes CHAOS del Standish Group desde1994 y 1997 establecieron que lo que contribuyemas a las fallas en los proyectos estn

relacionados con los requerimientos. En Diciembre de 1997, El diario Computer

Industry report sobre un estudio de SequentComputer Systems, Inc. De cerca de 500

Gerentes de IT en los U.S. Y U.K. En los que el76 por ciento habian experimentado fallas en losproyectos. La causa mas frecuente fuerequerimientos cambiantes del usuario."


4/54


Requerimiento

Un requerimiento de software se puede definircomo: una capacidad del softwarenecesaria paraque el usuario resuelva un problema o alcance un

objetivo. Una capacidad de software debe ser encontrada o

poseida por un sistemao componente de sistemapara satisfacer un contrato, especificacin,estandar u otra documentacin formalmenteimpuesta.

una condicin o capacidad que el sistema [enconstruccin] debe satisfacer.


5/54


Gestin de RequerimientosLa Gestin de requerimientos es: Un forma sistemticade obtener,

organizar y documentar losrequerimientos de un sistema.

Un proceso que establece y mantiene

un acuerdoentre el cliente y el equipode proyecto acerca de los cambios derequerimientos del sistema.


6/54


Gestin de requerimientos Mejorar el control de proyectos

complejos

Mejorar la calidad del softwarey lasatisfaccin del cliente. Saber que debeconstruir y probar.

Reduce los costos y demorasdelproyecto.

Mejora la comunicacindel equipo.


7/54


Gestin de requerimientos Es frecuentemente dificil decir como

hace el sistema lo que se supone debe

hacer. Esta dificultad se debe a la faltade un hilo visible y consistente a lolargo del sistema cuando ejecuta sustareas. En el proceso unificado los

casos de uso proporcionan aquel hilo(thread) definiendo el comportamientoque llevar a cabo el sistema.


8/54


Flujo de trabajo de Requerimientos


9/54


Problemas RequerimientosUna lista de problemas relacionada con la gestin de los

requerimientos:

Los requerimientos no siempre son obviosy provienende muchas fuentes.

Los requerimientos no son siempre fciles de expresarclaramente con palabras.

Existe muchos tipos diferentes de requerimientosendiferentes niveles de detalle.

El nmero de requerimientos puede ser inmanejable sino es controlado.


10/54


Problemas Requerimientos Los requerimientos estn relacionados entre si, y con

otros entregables del proceso en una variedad deformas.

Los requerimientos tienen propiedad nicaso valorespropios. Por ejemplo, ellos no son igualmenteimportantes tampoco igual de fciles de hallar.

Existen muchas partes interesadas y responsables, lo

que significa que los requerimientos necesitan sermanejados por grupos de personas nter funcionales.

Los requerimientos cambian.

Los requerimientos son sensibles al tiempo.


11/54


Analizar El Problema


12/54


Analizar El Problema Capturar un Vocabulario comn.

Desarrollar la visin. Encontrar actores y casos de uso.

Desarrollar un plan para la gestin de

requerimientos.


13/54


Productos de las actividades Glosario

Visin Modelo de casos de uso

Plan para la gestin de requerimientos.

Atributos de los requerimientos


14/54


Flujo de trabajoEl propsito del este flujo de trabajo es: Obtener un acuerdo sobre el problema

que se est resolviendo, Identificar a los stakeholders, Definir los lmites del sistema, y Identificar restricciones impuestas sobre

el sistema.


15/54


El conjunto de Artefactos de Requerimientos captura ypresenta informacin usada en la definicin de lascapacidades requeridas del sistema.

Flujo de trabajo


16/54


Comprender Necesidades De

Los Stakeholders


17/54


Flujo de actividades Capturar un vocabulario comn

Desarrollar la visin

Obtener los requerimientos delstackeholder.

Encontrar actores y casos de uso.

Manejar dependencias.

Revisar los cambios requeridos.


18/54


Productos de las actividades Glosario

Visin Requisitos de los stackeholders

Modelo de casos de uso

Especificaciones suplementariasAtributos de los requerimientos


19/54


Definir El Sistema


20/54


Flujo de actividades Desarrollar la visin

Capturar un vocabulario comn

Encontrar actores y casos de uso

Manejar dependencias


21/54


Productos del trabajo Glosario

Modelo de casos de uso Especificaciones suplementarias



22/54


Manejar Alcance Del Sistema


23/54


Flujo de Actividades Desarrollar la visin

Manejar las dependencias Priorizar los casos de uso

Revisar los cambios solicitados


24/54


Productos del trabajoVisin



25/54


Refinar Definicin Del Sistema


26/54


Flujo de actividades Detallar cada caso de uso

Detallar los requerimientos de SW Modelar las interfaces del usuario

Prototipear las interfaces del usuario


27/54


Productos del trabajo Especificaciones suplementarias

Casos de uso

Especificacin de los requerimientos desoftware

Storybard del caso de uso

Prototipo de interfases de usuario

Atributos de requerimientos


28/54


Manejo De Cambios En Los

Requerimientos


29/54


Flujo de actividades Manejar dependencias

Revisar solicitudes de cambio Revisar los requerimientos

Estructurar el modelo de casos de uso

Registro de la revisin


30/54


Productos del trabajo Modelo de casos de uso

Atributos de requerimientos


31/54


Tcnica Gestin deRequerimientos

Analizar el problema Obtener un acuerdo sobre el problema a ser

resuelto.

Identificar los stackeholders.

Definir los lmites del sistema.

Identicar restricciones a imponerse sobre elsistema.

Comprender las necesidades del Stakeholder. Fuentes : Clientes, socios, usuarios finales,

expertos del dominio, entre otros.


32/54


Es importante saber como determinar cuales deberianser las fuentes, como tener acceso y como obtenerinformacin de ellas. Los individuos que sirven como

fuente primaria de esta informacin son los llamados"stakeholders" en el proyecto.

Las tcnicas para obtener requerimientos incluyenentrevistas, tormenta de ideas, prototipeo conceptual,cuestionarios, y anlisis competitivo. El resultado deobtener requerimientos es una lista de requisitos onecesidades que son descritos textual o grficamentey que tienen prioridades relativas entre si.

Tcnica Gestin de

Requerimientos


33/54


Definir el sistema Significa traducir y organizar las

necesidades comprendidas del stakeholderen una descripcin significativa del sistemaa desarrollar.

El resultado de la definicin del sistema esuna descripcin del sistema tanto enlenguaje natural como grfico.

Tcnica Gestin de

Requerimientos


34/54


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 losrecursos disponibles(tiempo, personas y dinero)

Es una actividad continua. Usando los atributos de los requerimientos, tales

como prioridad, esfuerzo, y riesgo, como basepara negociar la inclusin de un requerimiento esuna tcnica particularmente til para gestional elalcance.

Tcnica Gestin de

Requerimientos


35/54


Refinar la definicin del sistema. Inluye dos consideraciones clave:

desarrollar una descripcin mas detalladade la definicin del alto nivel del sistema, yverificar que el sistema cumple con lasnecesidades del stakeholder y se comportacomo est descrito.

Tcnica Gestin de

Requerimientos


36/54


Manejar el cambio de requerimientos. Independientemente de cuan cuidadosamente

maneje sus requerimientos, ellos cambian. El cambio no es el enemigo, el cambio nogestionado si lo es.

Establecer una base de inicio, mantener la pista

histrica de cada requerimiento, determinar cualesdependencias son importantes seguir (trazar),establecer vnculos de trazabilidad entre itemsrelacionados y mantener el control de versiones.

Tcnica Gestin de

Requerimientos


37/54


Conceptos G. requerimientos Tipos de requerimientos

Identificando los tipos de requerimientos, el equipopuede organizar un gran nmero de requerimientos

en grupos significativos y mas manejables. Usualmente, un tipo de requerimiento puede ser

partido, o descompuesto en otros tipos. Las reglasdel negocio y las declaraciones de visin pueden ser

tipos de requerimientos de alto nivel de los cualesse deriven los tipos de requerimiento denecesidades del usuario, de caractersticas y deproducto.


38/54


Conceptos G. Requerimientos Equipos Interfuncionales


39/54


Atributos multidimensionales Cada tipo de requerimiento tiene atributos, y cada

requerimiento individual tiene diferentes valoresde atributo. Por ejemplo, a los requerimientospueden asignarsele prioridades, identificarse por lafuente y la lgica, delegarse a equipos especificos

dentro de un rea funcional, dar unadenominacin del grado de dificultad, o estarasociado con una iteracin particular del sistema.

Conceptos G. Requerimientos


40/54


En tipos de requerimientos mas detallados, losatributos de prioridad y esfuerzo pueden tenervalores ms especficos (e.g., tiempo estimado,

lineas de cdigo, etc.) con los cuales refinas masel alcance.

Historia de cambios A medida que los requerimientos evolucionan, es

importante entender su historia: que ha cambiado,porque, cuando, y an cual autorizacin.

Conceptos G. Requerimientos


41/54


Requerimientos Para facilitar su manejo se debera hacer: Acordar un vocabulario comn para el proyecto. Desarrollar una visin del sistema que describa el

problema a ser resuelto, asi como suscaractersticas 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.


42/54


Requerimientos Escoger los formatos en los que se describirn losrequerimientos.

Identificar a los miembros del equipo que sern los

autores, contribuyentes, o simples revisores de uno omas tipos de requerimientos.

Establecer un procedimiento para proponer, revisar yresolver cambios en el requerimiento.

Desarrollar un mecanismo para registrar las historia delrequerimiento. Crear reportes de avance y situacin para los

miembros del equipo y la gerencia.


43/54


Requerimientos FURPS+Existen muchas clases diferentes de requerimientos.Una forma de categorizar es descrita por el modeloFURPS+, Utilizando el acrnimo FURPS para

describir las categoras principales de requerimientoscon subcategoras como se muestra:

Funcionality (funcionalidad)

Usability (Facilidad de uso)

Reliability (Confiabilidad) Performance, (Rendimiento) y

Supportability (Soporte)


44/54


Requerimientos FURP+El "+" en FURPS+ le ayuda a recordar que tambin

incluye otros requerimientos como:

Restricciones de diseo, Requerimientos de implementacin,

Requerimientos de interface y

Requerimientos fsicos.


45/54


Requerimientos FURPS+Los Requerimientos Funcionales especificanacciones que un sistema debe ser capaz de ejecutar,

sin considerar restricciones fsicas. Estos se describenfrecuentemente en un modelo de casos de uso y enlos casos de uso. Los requerimientos funcionalesespecifican de esta forma el comportamiento deentrada y salida de un sistema.


46/54


Requerimientos FURPS+Los requerimientos funcionales pueden

incluir:

Conjuntos de caractersticas,

Capacidades, y

Seguridad.


47/54


Facilidad de Uso (Usability)

Puede incluir categoras como :

Factores de tipo humano,

Ergonmicos y estticos,

Consistencia en las interfaces de usuario, y

Materiales de entrenamiento y documentacin del

usuario. Ayudas sensitivas al contexto y en lnea.

Asistentes.

Requerimientos FURPS+


48/54


Requerimientos FURPS+Confiabilidad (Reliability) que se puedenconsiderar:

Frecuencia / severidad de fallas, Recuperabilidad, Predictibilidad, Exactitud y Tiempo medio entre fallas (MTBF).


49/54


Performance

Un requerimiento de rendimiento impone condicionessobre los requerimientos funcionales. Por ejemplo,

para una accin dada, pueden haber parmetros derendimiento:Velocidad Eficiencia, Disponibilidad,

Exactitud, Throughput, Tiempo de respuesta, Tiempo de recuperacin, o Utilizacin de recursos



50/54


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)



51/54


El + indica:

Restricciones de diseo

Requerimientos de implementacin: Estandares necesarios.

Lenguajes de implementacin.

Polticas de integridad de datos.

Ambientes operacionales



52/54


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 interaccin.



53/54


Requerimientos fsicos especificarequerimientos de hardware (redes) Formas Tamaos

Pesos

Material



54/54

Tabla de RequerimientosLISTA DE REQUERIMIENTOS DEL SISTEMA: OVINSYSTEM

Nro. Requerimiento Clasificacin Atributos

FURPS+Prioridad

(A, M, B)

Categora

(P, S, O)

Dificultad

(A, M, B)

Visibilidad

(V,O)

Riesgo

(A, M, B)Precedencia

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 preadas. F A P B V M R3

R5 Registrar grado de preez. 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

Documents

Sesion 3_0 Proceso Sw Requerimientos