Ingenieria de Requerimientos IESTPH

7/25/2019 Ingenieria de Requerimientos IESTPH

http://slidepdf.com/reader/full/ingenieria-de-requerimientos-iestph 1/166

1

Ingeniería deRequerimientos

Ing. Domingo Lizana Chauca



2

01: FUNDAMENTOS DE LAINGENIERÍA DE REQUERIMIENTOS



3

Qué vemos?????

• Analizar cuidadosamente estos gráficos, que

vemos?????



4

Que vemos????

• Sigamos…


http://slidepdf.com/reader/full/ingenieria-de-requerimientos-iestph 5/166 5

Que vemos????

• Sigamos



R ealidad f alsa…



Def iniciones

• Que es un r equer imiento? – IEEE: una condición o ca pacidad que debe se encontrada por un sistema o

componente del mismo para satisf acer un contrato, estándar, especificación u otr a

f or malidad im puesta en un documento. El conjunto de todos los r equer imientosforman la base para el desarrollo ded un sistema de sof t.

•

Qué es la IR ? – La Ingenier ía de R equer imientos se def ine como un conjunto de actividades en

las cuales, utilizando técnicas yherr amientas, se analiza un problema y seconcluye con la es pecif icación de una solución (a veces más de una).



Def iniciones

– IR se concentra en la identif icación del propósito de un sistema desoftware y el contexto en el cual el mismo se utiliza. IR actúa como el

puente entre las necesidades del mundo r eal de usuar ios, clientes yotros elementos afectados por el sistema de software y lasca pacidades y opor tunidades alcanzadas por las tecnologías del sof t.

– La IR es el proceso de descubr ir el propósito, identif icando losaspectos de inter és y sus necesidades y documentando esto en f or maamena para analizar , comunicar y poster iormente implementar .

– la definición de r equer imientos es una valor ación clar a de lasnecesidades que un sistema debe alcanzar . Debe decir que necesitael sistema, basado en condiciones corr ientes y pr evisi bles. De bedecir que rasgos del sistema ser vir án para satisf acer el contexto delmismo. Además debe decir como el sistema debe ser construido.



Im por tancia de la IR

• Pr oblemas – Incr ementa la de pendencia sobre el sof twar e

– El soft es ahora el mayor elemento de costo de sistemas de misión

cr ítica

•

Ej software de aviones, centr ales nuclear es, etc.• Aún para soft de negocios su desarrollo puede ser cr ítico

– Gran des per dicio pr oducido por fallos en pr oyectos

– Altas y graves consecuencias en casos de f allos• Cohetes f r ancés



Im por tancia de la IR

• Factor es claves – Cer tif icación de costos

• Pér didas pr oducidas durante el testeo, por err or eslatentes

– R ehacer gran cantidad de trabajo r emoción de

def ectos

– Cam bios en los r equer imientos• Por parte del usuar io / cliente.



Soluciones

• No existe una solución mágica – El soft es com ple jo por su tamaño – El soft es invisible y abstr acto – El soft no se f a br ica, se hace

•

Análisis y modelado temprano es im por tante – Los defectos se remueven en forma más bar ata

• Modelado y análisis temprano no es suf iciente – Se necesita comunicar los r equer imientos a todos – Se necesitan congeniar múlti ples agentes involucr ados – Se necesitan entender el contexto del sistema



12

Costo

de

corregirerror

Soluciones – Se necesita entender el contexto del proceso de desarr ollo

– Se necesita mantener la fecha de evolución de los

r equer imientos

Costo Re lativ o de corre gir un error

1000

100

10

1

Rquerimientos Diseño codigo prueba unidad prueba de sistema sistema operand o



13

R equer imientos e IS

• Visión gener al de los componentes deldesarrollo del sof t

• IS proceso que consiste de múlti plesactividades

• Car acter ísticas del desarrollo de sof t – El proceso de desarrollo del sof t

involucr a generar dif er entes modelos – Puede verse como una ser ie de pasos – Los pasos son ob jetivos conducidos y

pueden verse como tr ansiciones entr er e pr esentaciones

Implementación

Diseño detallado

Diseño arquitectónico

Especificación de Esp. del sistemarequerimiento



14

Im por tancia de los

Requerimientos • El argumento de Ingenier o – El ingeniero debe desarrollar soluciones a problemas – Una buena solución puede solo ser desarrollada si el ingeniero tiene un

buen entendimiento del problema • El argumento económico

– Los costos de errores aumentan si pasa más tiem po sin detectar los

• Ar gumento em pír ico – Los errores latentes de entender y manejar r equer imientos son la mayor

causa de exceso de costos• Ar gumento de segur idad

– Los mayores r iesgos de segur idad están centrado enr equer imientos inadecuados o mal entendidos



15

Correspondencia

Correctitud

Verificación

Valida

ción

Lo esencial en el proceso de R eq.

• Entender el pr oblema – Tomar r equer imientos,

com pr ender los, etc.

• For malmente descr i bir el

pr oblema – Especificar, modelar , etc.

• Conf r ontar el pr oblema con lar ealidad – Validar , solucionar conf lictos,

negociar – Adminitr ar los

r equer imientos

Mundo Real

Problema

Implementación

Sistema



20

Ver if icación y validación

• Para V y V se necesita tener en cuenta – Las propiedades del hardware (C) – Las propiedades del programa (P) – Las propiedades del dominio del problema (D) – Los r equer imientos (R )

Dominio de laaplicación

Dominio de lamáquina

Intersección

– La es pecif icación (S) [ propiedades de la máquina en el dominio dea plicación]

• Se debe demostrar que P satisf ace R proceso de dos pasos – P y C implican S? (ver if icación) – S y D implican R? (validación)



21

Tipos de dominios de problema

• Diseño nor mal o r evolucionar io – Normal problemas clásicos,

soluciones conocidas• Existen estándar es

suf icientemente probados• El Ingeniero elige el método

más a propiado o el queconsider a más a propiado

– R evolucionar io nunca f uehecho o se hizo anter ior mentemal • Muchos problemas de r iesgos

conviene hacer???

• Tipos de sof twar e – Estáticos o dinámicos

• Tenemos toda lainf or mación a priori ose adquier e durante el

proceso – Secuencial o par alelo

• En que se com plica??

– Com ple jidad de • Datos• Control • algor itmo



22

Las tres dimensiones de la IR

Especificación

Completa

Aceptacion

cercana

Vaga vista personal

Vista

común

Informal Semi

formal Formal Representación



23

Procesos, métodos,técnicas... • Una notación es un lengua je de r e pr esentación para una

ex pr esión. Ej. Lógica de pr imer órden, UML • Una técnica identif ica como hacer una actividad par ticular , y,

eventualmente, descr i be el producto de esa actividad con unanotación par ticular . Ej DFD

• Un método provee una descr i pción técnica para llevar a cabo un

conjunto de actividades• Un modelo de proceso es una descr i pción abstracta de cómo

llevar a cabo una colección de actividades, poniendo énf asis en eluso de recursos y de pendencias entre actividades.

• Un proceso es una instancia del modelo de proceso anter ior , quedescr i be el com por tamiento para uno o más agentes y el mane jo

de recursos por parte de los mismos



24

R esumiendo

• La IR es la rama de la IS concentrada con losob jetivos del mundo r eal para un sistema( problema), que tiene en cuenta sus f uncionesy sus limitaciones. Tam bién se centra en lasr elaciones de los factores de inf luencia par a pr ecisar la es pecif icación del com por tamientodel soft y su evolución a lo lar go de tiem po.



25

R esumiendo

• IR actividad humana, trabaja sobr e – Ciencia cognitiva: psicología cognitiva provee un

entendimiento de las dif icultades per sonales que se puedentener para descr i bir necesidades

– Antr opología: a pr oximación metodológica para obser varactividades humanas y com pr ender las me jor .

– Sociología: entender el contexto de la sociedad y los cam bioscultur ales causados (en par ticular por las computadoras y suuso)

– Lingüística: por un pr oblema de comunicaciones entr e

per sonas



26

FASES DE LA INGENIERÍADE REQUERIMIENTOS



27

FASE 01

ELICITACIÓN DE REQUERIMIENTOS



28

Elicitación

• Es el proceso de adquir ir (“eliciting”) todo el

conocimiento r elevante necesar io par a producir un modelo de los r equer imientosde un dominio de pr oblema

• Objetivo: entender el dominio del pr oblema

en par ticular • ¿Dónde encontrar el conocimiento? • Problemas:

– For ma no utilizable del conocimiento – Dif icultad cuando se trata de un ex per to

humano



29



30



31



32



33



34



35



36



37



38



39



40



41



42

El dominio del Pr oblema • Am biente operacional. Per mite def inir el am biente sobre el cual el sistema estar á

operando y todos sus com ponentes.• Sistemas de hardware. Estos sistemas comprenden, los sistemas de cómputo, las

redes utilizadas y sus protocolos, así como cualquier otros sistemas eléctr icos ymecánicos.

• Sistemas de Software. Estos sistemas comprenden los sistemas oper ativos, bases de

datos, lengua jes, sistemas de manejo de ar chivos, software de aplicación, sistemasde segur idad, entre otros.

• Inter f aces Hombre-Maquina. Estos sistemas son aquellos con los que los usuar iostendrán contacto dir ecto para llevar a cabo sus la bor es.

• Conexiones externas. Estos sistemas son aquellos que provienen del exter ior del

sistema y que r eci ben datos del sistema o a quienes el sistema envía datos.

• Procedimientos operacionales. Estos procedimientos def inen las f unciones quer ealiza el sistema actual.

• Ca pacidad del Sistema Actual. Este aspecto per mite identif icar cual es la ca pacidad

de procesamiento y de almacenamiento r equer idos por el sistema.



43

Búsqueda y Recolección de Inf or mación • Inf or mación sobre el sistema actual. Esta inf or mación provee detalles sobre el

sistema que se quier e r em plazar y que actualmente está en f uncionamiento.• Necesidades de los clientes y usuarios. La inf or mación r ecolectada anter ior mente,

der ivada de las entr evistas con los clientes, usuar ios y con los inter esados en el

sistema, debe documentar se.

• Estándar es organizacionales. Esta inf or mación comprende todos aquellos manualesde procedimientos que la or ganización sigue en sus procesos.

• Regulaciones Nacionales e Internacionales. Esta inf or mación es aquella que provea

estándares o normas para r eglamentar al sistema o a los productos de software aconstruir . Usualmente todo país cuenta con un or ganismo de gobierno que r egula lasactividades de las or ganizaciones y que provee r eglas de com petencia y de calidad.

• Inf or mación sobre el dominio de la aplicación. Esta inf or mación comprende toda

aquella inf or mación que per mita descubr ir el dominio.



44

Ejm: Definición de Límites y R estr icciones

Diagrama de Contexto de un Sistema de Inscr i pciones.



45



46



47

Stak eholder s = Inter esados

• Clientes: Estos nor malmente son quienes contratan, f inancian o autor izan el

desarrollo del proyecto.

• Usuarios: Estos son aquellos que ter minar án operando el software r equer ido,

después de que el sistema esté com pletamente desarrollado.

• Ingenieros de Desarrollo de Software: Son todos aquellos involucr ados en el

desarrollo del software, en cualquier a de sus etapas (diseño, im plementación,

pruebas o mantenimiento).

• Ingenieros del cliente. Son todos aquellos es pecialistas que asesoran o tr a ba jan

dentro de la or ganización del cliente y que ayudan a es pecif icar los detalles técnicos

de la aplicación a desarrollar .• Administr ador es o jefes del proyecto de software: Son aquellos que dir igen y/o

administr an el proyecto de sof twar e.

• Contr atistas externos. Son aquellos desarrollador es externos a quienes se lescontrata para r ealizar una parte del sistema.

• Reguladores externos: es todo aquel per sonal que indir ectamente verifica que todo

r eglamento o ley que a plique al desarrollo del proyecto se cum pla.



48

Roles y Actividades

R ol Actividades

Analista de Requerimientos, Expertodel dominio, usuario

Este personal estará a cargo de entenderel problema y su definición.

Analista de requerimientos, usuario Están a cargo de especificar a detallelos requerimientos.

Ingeniero de desarrollo de software,administrador del proyecto

Están a cargo de seleccionar posibles prototipos del sistema.

Ingeniero de requerimientos, Ingenierode desarrollo de software

Estarán a cargo de desarrollar el sistemao prototipo.

Usuario, experto del dominio, analistade requerimiento e Ingeniero deDesarrollo

Estarán a cargo de evaluar el sistemafinal o prototipo.



49

Fuentes de O btencion de R equer imientos

Fuentes potenciales y las formas de obtención derequerimientos.

• Entrevistas y discusiones con clientes y usuarios.• Documentos que describen sistemas actuales o

productos de la competencia.• Reportes de problemas técnicos del sistema actual. • Estudio de la organización ó cuestionarios de usuarios.• Observación de los usuarios futuros y de su medioambiente.• Análisis de los escenarios de las tareas del usuario. • Análisis de Eventos y Respuestas.



50

E jem plos de R equer imientos

Requerimientos denegocio

• Incr ementa el porcentaje del mercado en 30 %.• Ahorr a 20% en costos de producción por la

automatización instalada.• Ahorr a 40% en costos de mantenimiento.

Casos de uso yescenar ios

• Yo necesito imprimir una etiqueta de correo para el

paquete.• Yo necesito administr ar una cola de r eactivos químicos

que esperan ser analizados.• Yo necesito cali br ar las maquinas para control numér ico.

Reglas delnegocio

• Debe de seguir el estándar de acuerdo con alguna ley o

política de la or ganización.• El formato del saldo de conta bilidad esta def inido en losmanuales de la or ganización.



51

E jem plo de R equer imientos

R equer imientosf uncionales

• Si el volta je rebasa los 20 v. enciende la alar ma amar illa.• El sistema envía un e-mail de conf ir mación cuando r eci becualquier e-mail.• El sistema debe ordenar los productos del inventar io en orden alf a bético.

Requerimientos deinterfaces externas

• Las señales de volta je se leen de los conver tidor esanalógico-digital.•

L

os mensajes se envían a través de laInternet.• El software debe controlar el ta blero de diagr amas

eléctr icos.• Los ar chivos r eci bidos electrónicamente deben leer se del disco externo • El usuar io debe poder ver paginas de web amiga bles.



52

E jem plos de R equer imientos

Propiedad Medida

Velocidad Tr ansacciones por segundo Tiem po de respuesta a eventos

Tamaño Numero de líneas de código Numero de Bytes de Memor ia dis poni ble

Facilidad de uso Tiem po de entr enamiento Numero de ayudas

Conf ia bilidad Error es per mitidos por unidad de tiem po Media de tiem po por f allo Disponibilidad en tiem po

R obustes Tiem po para r esta blecer despues de f allo.Porcentaje de fallos que causan caida

Por ta bilidad Facilidad de transportar a otro S.O o

lengua je.



53

E jem plos de R equer imientosR estr icciones • Los ar chivos r eci bidos no deben exceder los 10 M bytes.

•

La Base de Datos debe manejar ar chivos en f or mator elacional.

• El envío de paquetes en la red, debe de usar encr i ptación de 128 Bits.

Definiciones de datos • Los números enteros capturados no deben sobre pasar el

valor de 10,000.• El numero de asientos inicial a vender por la aerolínea debe ser 400.• El valor de temperatura limite es de 40 gr adoscentígr ados.

Ideas de solución Un cliente podr ía indicar que para propor cionar segur idad al

sistema ante ataques externos, este debe pedir un pasword,

o podr ía construir se un “firewall” o hacer que los datosusen encr i ptación.



54



55



56



57



58

Técnicas de Elicitación



59



60



61



62



63



64



65

b é i



66

Una buena Técnica: Análisis Participativo (JAD)

• JAD (Joint Application Development)

• Asociación entre usuario y profesionalesde informática



67

Los 5 pasos del JAD

• Definición del Pr oyecto

• Investigación

• Pr e par ación

•

La Sesión • El Documento Final



68

Par tici pantes

• S ponsor e jecutivo : Es el que toma las decisiones pr inci pales ycontr ola el pr oyecto

• Facilitador: Debe ser imparcial, es el que guiar á al team a

traves de todo el proceso de Jad, debe ser ob jetivo, “ no

viciado” y neutr al

• Escriba: Documenta todas las decisiones• Par tici pantes Full-Time : Son todos aquellos par tici pantes que

se encuentran envueltos para tomar decisiones sobre el

pr oyecto



69

Sponsor E jecutivo

• Antes de la sesión : Debe discutir con el Facilitador par a

def inir el pr opósito, ob jetivos y estr ategias en la dir ección del

pr oyecto

• Durante la sesión : Toma parte cuando la sesión es de alto

nivel de decisión

• Despues de la sesión : Avala las r esoluciones tomadas por el JAD



70

Facilitador

• Es el que hace que el “motor ” del JAD

• Su unico inter és en el producto final debe ser que f uncione

ef ectivamente, ef icientemente y cum pla con lo que el usuar io

necesita

• Debe or ganizar a nivel de pr oyecto

• Debe saber comunicar se • Lider ar gr upos

• Resumir discusiones

• Debe ser sensi ble a la dinámica del grupo y a las políticas de la

em pr esa



71

Facilitador

• Antes de la sesión: Debe r eunir se con el S ponsor e jecutivo para def inir

el propósito, ob jetivos y estr ategias en la dir ección del proyecto, luego

trabajar con las personas en las distintas areas de inter es y tomar

inf or mación sobre los r equer imientos. El r esultado de estasactividades se vuelca en un “Documento de Tr a ba jo” para utilizarlo en la sesión

• Durante la sesión: Guía a los par tici pantes según la agenda, estáatento a las discusiones , guía la conver sación de acuerdo a losr equer imientos. Deter mina lo que el escr i ba debe documentar .

• Después de la sesión: Supervisa la cr eación , revisión y distr i bución del

documento f inal



72

Escr i ba

• Debe conocer el area de tr a ba jo

• Debe tener ca pacidad de análisis

• Manejar herr amientas que asistan a su trabajo (CASE,

procesadores de texto, herr amientas gráficas, etc)

• Dominio del lengua je técnico

• Escribir clar o en letr a manuscr ita

• Puede ser un programador, analista u otra persona que

maneje bien el dominio es pecíf ico de estudio



73

Escr i ba

• Antes de la sesión: El Facilitador le indica cual será su rol yacordará con éste cuales serán las herr amientas que seutilizar án para capturar la inf or mación r equer ida

• Durante la sesión: Documentar lo que le indique el Facilitador

• Después de la sesión: Revisar las notas con el Facilitador y

ayudar a preparar el documento f inal

i



74

Participantes de una sesión tí pica

• Vice Pr esidente, Controla la Corpor ación

• Analista de Sistemas Senior

• Progr amador

• Dir ector Financiero

• Super visor

• Data Entr y • Dir ector de Costos y Pr esupuesto

• Dir ector de planif. de im puestos

• Dir ector de Com pr as

• Dir ector de per sonal

• Project Manager

• Programador Senior / Analista

Sponsor Ejecutivo

Facilitador

Escriba

Team (user)

Team (user)

Team (user)Team (user)

Team (user)

Team (user)

Team (user)

Team (Sistemas)

Team (Sistemas)

ili i l Si



75

Familiar izar se con el Sistema

• Encontr ar se con la gente que maneja el negocio – Observar el entorno de tr a ba jo

– Observar el flujo de tr a ba jo

– Revisar las salidas

– Discutir los cambio

•

Encontr ar el Sistema de Inf or mación • El Facilitador debe “empaparse” del manejo del negocio

A d d l S ió C i i



76

Agenda de la Sesión - Comisiones

• Síntesis de subsistemas analizados por comisiones

• Definir nuevos elementos de datos

• Diseñar nuevas pantallas

• R eveer y modif icar reportes existentes

• Definir r utinas de calculo

• Resolver cuestiones a bier tas

Agenda de la Sesión - Planificación



77

Agenda de la Sesión Planif icación estr atégica

• R e pasar los O b jetivos

• Definir acier tos f inancier os y ob jetivos

• Discutir cómo r educir los costos

• Definir acier tos de mar k eting y ob jetivos

• Discutir pr oblemas de imagen de la com pañía

• Definir el modelo em pr esar ial

• Discutir como medir el éxito del plan

• Preparar un plan de acción

Agenda de la Sesión - R equer imientos



78

g a S q

de datos • Discutir pr oblemas con el sistema existente

• Definir y descr i bir cada ti po de entidad

• Definir las r elaciones entre entidades

• Definir lo volúmenes de cada ti po de entidad

• Preparar la descr i pción de los elementos de datos

• R eveer el modelo Entidad - R elación

P ió



79

Pr e par ación

• Documento de tr a ba jo

• Ayudas visuales (gráficos, esquemas,etc.)

• Organizar el lugar de trabajo (fig 7.6)

•

Entr enar al escr i ba • Preparar y planificar cómo se llevar á a cabo la

sesión

Se ió



80

Sesión

• Modelos de Datos

• Modelos de Pr ocesos

• R e por tes

•

Pantallas• Suposiciones

• Cuestiones a bier tas

Psicología de la Sesión



81

Psicología de la Sesión

• Logr ar com pr omiso de los usuar ios ger enciales y dir ectivos

• No extender las sesiones mucho tiem po

• Ignor ar peleas entre dir ectivos

• No usar un Facilitador poco ca pacitado

• No dejar que las herr amientas manejen la sesión (ej CASE)

• Tr atar de no utilizar lengua je técnico)

• Estar bien pr e par ado

• Tomar se el tiem po necesar io para distr i buir el documento f inal

Dinámica de grupo



82

Dinámica de gr upo

• Elegir bien a los par tici pantes

• No dejar que los par tici pantes busquen r eem plazos por decisión

pr opia

• El grupo debe contar entre 7 y 15 per sonas

• Utilizar la agenda como “hoja de r uta”

Cómo manejar conflictos



83

Cómo manejar conf lictos

• Pedir la opinión del resto del gr upo

• Dejar el conflicto como una “cuestión a bier ta”

• Tomar un inter valo

• Analizar el conflicto en una forma estructurada (r emitir se a los

ob jetivos)

• Llamar al S ponsor E jecutivo

Repertorio del Facilitador



84


• Comunicar se bien – Escuchar lo que se dice

– Interpr etar

– R elacionar e integr ar en el contexto

– El f acilitador es r es ponsa ble de preparar documentos

• Se par ar la idea de la per sona • Mostrar un inter és natur al

• Escuchar bien




85


• Mantener el contr ol – Controlar la sesión

– Or ientar la sesión hacia los ob jetivos

– Manejar situaciones de conf licto

• Motivar al gr upo

• Ser r á pido para conectar se

• Enf ocar se en el punto de inter és

• Mantener su rol clar o



86

FASE 02 ESPECIFICACIÓN DEREQUERIMIENTOS



87



88



89



90



91



92



93



94



95



96



97



98



99



100



101



102

FASE 03 VALIDACIÓN DE REQUERIMIENTOS



103

PRIMERA UNIDAD



104

TEMA 03: TIPOS DEREQUERIMIENTOS

Requerimientos Funcionales

Los r equer imientos f uncionales de un sistema

describen lo que el sistemadebe hacer Estos



105

descr i ben lo que el sistema debe hacer. Estosr equer imientos dependen del ti po de sof twar e

que se desarrolle, de los posi bles usuar ios delsoftware y del enfoque gener al tomado por la

or ganización al redactar r equer imientos.

Requerimientos No Funcionales

Los r equer imientos no f uncionales, como su

nombre sugier e, son aquellos r equer imientosque no se r ef ier en dir ectamente a lasf unciones es pecíf icas que propor ciona el

sistema, sino a las propiedades emergentes de éste como la fiabilidad, el tiem po de r es puestay la ca pacidad de almacenamiento.



106

GESTIÓN DEL PROYECTO DE



107

REQUERIMIENTOS



108



109



110



111



112



113



114



115



116



117



118



119



120



121



122



123



124



125



126



127



128



129



130



131

Gestión Eficaz de un Pr oyecto



132

Las 4 P´s:

• Per sonal

•Pr oducto

•Pr oceso

•Pr oyecto

Per sonal

•Gestores super ior es



133

•Gestores (técnicos) del pr oyecto

•Prof esionales

•

Clientes•Usuar ios f inales

Pr oducto

Se requieren estimaciones cuantitativas y un



134

plan organizado, pero no se dispone deinformación sólida. Un análisis detallado delos requisitos del software proporcionaría lainformación necesaria para las estimaciones,

pero el análisis a menudo lleva semanas omeses. Aún peor, los requisitos pueden serfluidos, cambiando regularmente a medidaque progresa el proyecto. Y, aún así, se

necesita un plan «¡ya!».

Pr oceso

Cuando se selecciona un modelo de proceso,



135

el equipo define entonces un plan de proyectopreliminar basado en un conjunto deactividades estructurales. Una vez establecidoel plan preliminar, empieza la descomposición

del proceso. Es decir, se debe crear un plancompleto reflejando las tareas requeridas alas personas para cubrir las actividadesestructurales.

Pr oyecto •La gente del software no comprende las necesidades de losclientes.•



136

El ámbito del producto está definido pobremente.•Los cambios están mal realizados.•La tecnología elegida cambia.•Las necesidades del negocio cambian [o están maldefinidas].•Las fechas de entrega no son realistas.•

Los usuarios se resisten.•Se pierden los patrocinadores [o nunca se obtuvieronadecuadamente].•El equipo del proyecto carece del personal con lashabilidades apropiadas.•Los gestores [y los desarrolladores] evitan buenas prácticas

y sabias lecciones.

SEGUNDA UNIDAD TEMA 05: HERRAMIENTAS Y

É Í



137

TÉCNICAS DE LA INGENIERÍA DEREQUERIMIENTOS

Sistemas Existentes

Esta técnica consiste en analizar distintos sistemas

d ll d l i d l



138

ya desarr ollados que estén r elacionados con elsistema a ser constr uido. Por un lado, podemosanalizar las inter f ases de usuar io, observando el ti po

de inf or mación que se maneja y cómo es mane jada.Esto puede ser útil para descubr ir inf or mación

im por tante a tener en cuenta, inf or mación que talvez el cliente/usuar io haya f allado en comunicar .

Grabaciones de Video y de Audio

Bá i t i t tili l



139

Básicamente existen dos formas de utilizar lasgr a baciones: como r egistr o y apoyo de las entr evistas,

y para analizar algún proceso en par ticular . En cuanto a

su f unción de apoyo, es im por tante por cuanto per mite

centrar la atención en la entr evista en sí en vez de

distr aer se tomando notas de todo lo que sedice. Además, per mite analizar los temascon más detenimiento y con una visión

más global.

Ar queología de Documentos

C l li ió d h i t d



140

Con la aplicación de esta herr amienta se tratan dedeter minar posi bles r equer imientos sobre la base de

ins peccionar la documentación utilizada por la

empresa; por e jem plo, boletas, facturas, r emitos, etc.Esta herr amienta sir ve más que nada como

com plemento de lasdemás técnicas, y nos ayuda aobtener inf or mación que de otra manera ser ía

sumamente difícil conseguir .

A pr endiz

Esta herr amienta se basa en la idea del maestro y el

a r di b f d b l b j r al



141

a pr endiz, y es una buena forma de observar el trabajo r eal.Aquí, el a pr endiz es representado por el alumno, y el

usuar io/cliente cum ple el rol de maestro. El a pr endiz sesienta con el maestro a aprender por medio de la

obser vación, haciendo preguntas como ¿por qué hizo eso?

y ¿qué significa eso?, y tam bién r ealizando algún tr a ba jo bajo la super visión del maestro. Esta técnica puede ser

com binada con la herr amienta de modelo conce ptual.

O bser vación

Es sumamente difícil descr i bir cómo hacer el nudo de un

calzado deportivo t fácil t lo



142

calzado de por tivo, pero es sumamente fácil mostrar los pasos para hacer lo. Observar cómo se hacen las cosas esuna buena manera de entender lo que estas r equier en.Conectar se íntimamente con la cultur a de la or ganización,

vivirla, es una herr amienta que debe ser tomada en

cuenta. Tam bién podemos r ealizar filmacionesdel lugar de trabajo, para luego obser var las yanalizar las, buscando patrones, procesos, pr oblemas, etc.

Run Use Case WorkShop (Taller es de Tr a ba jo basados en los Casos de Uso)

E to tallere d t b j realizan t el cliente/u uario el equipo de



143

Estos taller es de trabajo se r ealizan entre el cliente/usuar io y el equi po der equer imientos. La pr imer parte del WorkShop consiste en generar losescenar ios. Para esto se necesita la inf or mación que tiene para br indar el

usuar io/cliente. La idea es conversar por medio de los casos de uso yextraer de los usuar ios las cosas esenciales que suceden cuando ocurre un

evento deter minado. Así, tratamos de def inir la ser ie de usuar ios yreconocer los pasos que se r ealizan para el caso de uso en estudio. Luego

preguntamos si los pasos r egistr ados están bien o si hay que cam biar los o

me jor ar los. Como r esultado de este proceso obtenemos un excelente

bosquejo del caso de uso. Una vez finalizada la etapa anter ior , el equi po der equer imientos retorna a la oficina a es pecif icar y deducir losr equer imientos, a par tir del conocimiento pr eviamente adquir ido.

Pr ototi pos

Durante la actividad de extr acción de r equer imientos, puede

ocurr ir que algunos r equer imientos no estén demasiado clar os o

que no estemos muy seguros de haber entendido correctamente



144

que no estemos muy seguros de haber entendido corr ectamentelos r equer imientos obtenidos hasta el momento, todo lo cual

puede llevar a un desarr ollo no eficaz del sistema final. Entonces,

para validar los r equer imientos hallados, se construyen pr ototi pos.Los pr ototi pos son simulaciones del posi ble producto, que luego

son utilizados por el usuar io final, per mitiéndonos conseguir una

im por tante r etr oalimentación en cuanto a si el sistema diseñado

en base a los r equer imientos r ecolectados le per mite al usuar io

r ealizar su trabajo de manera ef iciente y ef ectiva.

Glosar io

El glosar io es una sim ple lista de tér minos en donde se

explica s significado En esta lista se incluyen definen



145

explica su significado. En esta lista se incluyen y def inentodos los tér minos que r equier en ex plicación,

mejorando así la comunicación inter gr upal y la

ocmunicación con el cliente, y mitigando el r iesgo de

malos entendidos. Los tér minos que se incluyen

pr ovienen de todas las áreas del proyecto: casos de uso,ter minología pr opia del negocio, etc. El glosar io se vaactualizando durante el transcurso del proceso de IR ,

per f eccionándolo en cada nuevo ciclo.



Check list (Lista de Ver if icación)

Esta herramienta es muy fácil de utilizar y proporciona



147

Esta herr amienta es muy fácil de utilizar y pr opor cionauna gran utilidad. En gener al es una lista de pr eguntasque se debe usar para evaluar cada r equer imiento. Se

verifica y marca los puntos de esta lista mientr as leen el

documento de r equer imientos. Cuando se descubr en

pr oblemas potenciales, deben ser anotados, ya sea en los márgenes del documento, ya sea en una lista de análisis.

ESPECIFICACIÓNDE

REQUERIMIENTOS



148

REQUERIMIENTOS

Documento Formal de Especificación de Requerimientos:

Standard de IEEE 830 1. Intr oducción



149

1. 1.1. Propósito 1.2. Alcance 1.3. Definiciones, acrónimos y a br eviatur as1.4. R ef er encias1.5. Over view

2. Descripción gener al 2.1. Per s pectiva del producto 2.2. Funciones del producto 2.3. Car acter ísticas del usuar io 2.4. R estr icciones gener ales2.5. Supuestos y de pendencias

3. Requerimientos es pecíf icos A péndices

1.Introducción

1.1. Pr opósito

Delinear el propósito de la SRS y es pecif icar a quién se dir ige



150

y g1.2. Alcance Identif icar los productos de SW, explicar que hará y que no hará cada uno,

descr i bir la a plicación 1.3. Definiciones, acrónimos y a br eviatur as Incluir las def iniciones de los tér minos, acrónimos y a br eviatur as r equer idas

para interpr etar la SR S.

1.4. R ef er encias Proveer una lista com pleta de todos los documentos r ef er enciados1.5. Over view Describir qué contiene el resto de la SRS y explicar cómo está or ganizada la SR S

2.Descripción General

Descr i be los factores gener ales que afectan al producto y a

los r equer imientos, facilita su com pr ensión



151

q p

2.1. Perspectiva del pr oducto – Relación con otros productos o proyectos – Productos inde pendientes – Com ponentes de un sistema o de un proyecto: – Hardware y equi pamiento per if ér ico – Diagrama de bloques –

R estr icciones de diseño 2.2. Funciones del pr oducto

– R esumen de las f unciones que ejecutará el sof twar e. – Com pr ensi bilidad – Diagrama de bloques – No esta blece r equer imientos es pecíf icos,

2.Descripción General

2.3. Car acter ísticas del usuar io



152

– Car acter ísticas gener ales del usuar io – R estr icciones im puestas por los inter actuantes – R equer imientos es pecíf icos o r estr icciones sobre la solución

2.4. Restricciones gener ales – Límites al desarrollador – R equer imientos es pecíf icos o r estr icciones sobre la solución

2.5. Supuestos y de pendencias – Factor es que afectan los r equer imientos – R estr icciones de diseño – Cam bios quepueden afectar los r equer imientos en la SR S.

Descripción General

2.4. Restricciones gener ales Límites a las opciones para diseñar el sistema:



153

Límites a las opciones para diseñar el sistema: • Políticas r egulator ias• Limitaciones de hardwar e • Inter f ases con otras a plicaciones• O per aciones par alelas• Funciones de auditor ía • Funciones de control • R equer imientos de lengua jes de alto nivel • Protocolos de “signal handshake” (ej: XO N/XOFF) • Criticalidad de la a plicación • Consider aciones de segur idad (Safety and Secur ity)

3.Requerimientos específicos • El sector mayor y más im por tante de la SR S

• Presentación y conceptualización del desarrollo de los



154

Pr esentación y conce ptualización del desarr ollo de losr equer imientos

• El contexto de la ingenier ía de r equer imientos.

Requerimientos específicos - I 3.1. R equer imientos f uncionales

3.1.1. R equer imientos f uncionales 13.1.1.1.Introducción 3.1.1.2.Inputs3.1.1.3.Procesos3.1.1.4.Outputs



155

3.1.1.4.Out puts.....3.1.n. R equer imientos f uncionales n

3.2. R equer imientosde inter f ase externa 3.2.1. Inter f ases del usuar io 3.2.2. Inter f ases del hardwar e 3.2.3. Inter f ases del sof twar e 3.2.4. Inter f ases de comunicaciones

3.3. R equer imientos de per f or mance 3.4. R estr icciones de diseño

3.4.1. Cum plimiento de standards3.4.2. Limitaciones de Hardwar e ....

3.5. Atr i butos3.5.1. Dis poni bilidad 3.5.2. Segur idad 3.5.3. Manteni bilidad 3.5.4. Tr ansf er i bilidad/conver sión ...

3.6. Otros r equer imientos3.6.1. Base de Datos3.6.2. O per aciones

3.6.3. Ada ptación del lugar

Requerimientos específicos - II 3.1. R equer imientos f uncionales

3.1.1. R equer imientos f uncionales 13.1.1.1. Es pecif icación

3.1.1.1.1.Introducción 3.1.1.1.2.Inputs3.1.1.1.3.Procesos



156

3.1.1.1.4.Out puts3.1.1.2. Inter f ases externas

3.1.1.2.1. Inter f ases del usuar io 3.1.1.2.2. Inter f ases del hardwar e 3.1.1.2.3. Inter f ases del sof twar e 3.1.1.2.4. Inter f ases de comunicaciones

...3.1.n. R equer imientos f uncionales n

3.2. R equer imientos de per f or mance

3.3. R estr icciones de diseño 3.4.1. Cum plimiento de standards3.4.2. Limitaciones de Hardwar e ....

3.4. Atr i butos3.5.1. Dis poni bilidad 3.5.2. Segur idad 3.5.3. Manteni bilidad 3.5.4. Tr ansf er i bilidad/conver sión ...

3.5. Otros r equer imientos3.6.1. Base de Datos

3.6.2. O per aciones3.6.3. Ada ptación del lugar

Requerimientos específicos - III 3.1. Requerimientos funcionales

3.1.1. Requerimientos funcionales 13.1.1.1.Introducción3.1.1.2.Inputs3.1.1.3.Procesos3.1.1.4.Outputs3.1.1.5.Requerimientos de Performance3.1.1.6.Restricciones de diseño

3.1.1.6.1. Cumplimiento de standards3.1.1.6.2. Limitaciones de Hardware

...3.1.1.7.Atributos

3 1 1 7 1 Disponibilidad



157

3.1.1.7.1. Disponibilidad3.1.1.7.2. Seguridad3.1.1.7.3. Mantenibilidad3.1.1.7.4. Transferibilidad/conversión...

3.1.1.8. Otros requerimientos3.1.1.8.1. Base de Datos3.1.1.8. 2. Operaciones3.1.1.8. 3. Adaptación del lugar...

3.1.n. Requerimientos funcionales n3.2. Requerimientos de interfase externa

3.2.1. Interfases del usuario3.2.1.1. Requerimientos de performance3.2.1.2. Restricciones de dsiseño

3.2.1.2.1. Cumplimiento de standards3.2.1.2.2. Limitaciones de hardware...

3.2.1.3. Atributos3.2.1.3.1. Disponibilidad3.2.1.3.2. Seguridad3.2.1.3.3. Mantenibilidad3.2.1.3.4. Transferibilidad/conversión...

3.2.2. Interfases de hardware3.2.3. Interfases de software

3.2.4. Interfases de comunicaciones

Requerimientos específicos - IV 3.1. R equer imientos f uncionales

3.1.1. R equer imientos f uncionales 13.1.1. I ntroducción 3.1.2.I nputs3.1.3.Procesos

3.1.4.Out puts3.1.5.I nterfases externas3.2.5.1. I nterfases del usuar io 3 2 5 2 Interfases de hard are



158

3.2.5.2. I nterfases de hardwar e 3.2.5.3. I nterfases de sof twar e 3.2.5.4. I nterfases de comunicaciones

3.1.6.R equer imientos de Per f or mance 3.1.7.R estr icciones de diseño

3.1.1.7.1. Cum plimiento de standards3.1.1.7.2. Limitaciones de Hardwar e ...

3.1.1.8.Atr i butos3.1.1.8.1. Dis poni bilidad 3.1.1.8.2. Segur idad 3.1.1.8.3. Manteni bilidad 3.1.1.8.4. Tr ansf er i bilidad/conver sión

...3.1.1.9. Otros r equer imientos3.1.1.8.1. Base de Datos3.1.1.8. 2. O per aciones3.1.1.8. 3. Ada ptación del lugar ...

3.1.n. R equer imientos f uncionales n ...

SEGUNDA UNIDAD TEMA 07: PROTOTIPOS



159

Constr ucción de pr ototi pos de sof twar e

•

Por lo gener al los clientes y usuar ios f inalesdel software encuentran muy difícil



160

ydel software encuentran muy dif ícil

expresar sus r equer imientos r eales.

• Es casi im posi ble pr edecir la manera en que

un sistema afectará el trabajo diar io, comointer actuar á con otros sistemas y qué

oper aciones del usuar io se de ber ían

automatizar .


•

Sin embargo es posi ble probar el sistema siestá disponible un prototipo de él



161

g pestá dis poni ble un prototi po de él.

• Un prototi po es una ver sión inicial de un

sistema de software que se utiliza par a

demostrar los conceptos, probar lasopciones de diseño y entender mejor el

“ pr oblema” y su solución.


• Un pr ototi po de software apoya dosactividades del proceso de ingenier ía de



162

pr equer imientos: 1. O btención de r equer imientos: los usuar ios

ex per imentan como el sistema ayudará su

tr a ba jo.2. Validación de r equer imientos: el prototi po puede r evelar errores u omisiones en losr equer imientos pr opuestos.

El proceso de desarr ollo de pr ototi pos



163

Establecerobjetivos del pr ototi po

Definirf uncionalidad

del pr ototi po

Desar r ollar pr ototi po

Evaluar

pr ototi po

Plan deconstr ucción

del pr ototi po

Definición general Pr ototi po

e jecutable Informe deevaluación




164

Construcciónde pr ototi posevolutivos

Sistema

entr egado

Requerimientos

gener alesConstrucciónde

pr ototi posdesecha bles

Prototipo ejecutable +especificación del sistema


• Existe gran dif er encia entre los dos ti pos de prototi pos:



165

1. El pr ototi po evolutivo entrega a los usuar iosf inales un sistema f uncionando. Se usa con losr equer imientos que mejor se com pr enden.

2. El prototi po desecha ble valida o der iva losr equer imientos del sistema. Se usa con losr equer imientos que no se conocen bien.Per íodo de vida cor to.

Prototi po evolutivo

Desarr olloespecificación

Construir elsistema prototipo Utilizar el sistema



166

es pecificacióna bstr acta

sistema pr ototi po pr ototi po

NO

Entregar SÍ

sistema ¿ Sistema

apto ?

Proceso de desarrollo incr emental

Definir productos a

entregar delsistema



167

Diseñar

arquitectura delsistema

Es pecificar

incrementodelsistema

Constr uirincrementodel

sistema

Validar

incr emento

NO

Entregar sistema

final

SÍ

¿Sistema

com pleto? Validar sistema

Integr arincr emento

Prototi pos desecha bles

R equer imientosgener ales

Desarr ollar pr ototi po

Evaluar

pr ototi poEs pecificar

sistema



168

Com ponentesr eutilizables

Desarr ollarsof twar e

Validar

sistema

Sistema desof twar e

entr egado



169

Ingenieria de Requerimientos IESTPH

Documents

Transcript of Ingenieria de Requerimientos IESTPH