PROCESOS DE LA INGENIERA
DE REQUISITOS
INGENIERA DE
REQUERIMIENTOS
Ing. Sfora Romn Snchez
INTRODUCCIN
La I.R. cumple un papel primordial en el proceso de
produccin de software, que se enfoca a un rea fundamental:
la definicin de lo que se desea producir
Su tarea principal consiste en la generacin de
especificaciones correctas que describan con claridad, sin
ambigedades, en forma consistente y compacta, el
comportamiento del sistema, de esta forma, se pretende
minimizar los problemas relacionados al desarrollo de
sistemas.
TIPOS DE REQUISITOS
Nueva
Abstraccin
Usuarios: Servicio del sistema debe ser
comprensible para el cliente.
Sistema: Descripcin detallada de funciones
, uso de notaciones especializadas.
Dominio: Declaraciones cercanas al diseo e
implementacin
Naturaleza
Funcionales: Descripcin de qu funciones
hace el sistema.
No funcionales: Descripcin de cmo debe
funcionar el sistema
REQUISITOS FUNCIONALES Y NO FUNCIONALES
Requisitos funcionales: describen lo que el
sistema debera hacer
Ej.: el sistema debe proveer autenticacin de la identidad
de un usuario
Ej.: el sistema debe emitir una factura
Requisitos no funcionales: establecen
restricciones de cmo estos requisitos
funcionales son implementados.
EJ.: El proceso de autenticacin debera completarse en
menos de 4 segundos.
EJ.: La emisin de factura debe poder hacerse desde
cualquier terminal de trabajo.
REQUERIMIENTO
Definicin: Condicin o necesidad de un usuario para
resolver un problema o alcanzar un objetivo.
Es necesario si su omisin provoca una deficiencia en el sistema a
Necesario
construir.
Conciso
Si es fcil de leer y entender
Si no necesita ampliar detalles en su redaccin, esto es si proporciona
Completo
la informacin suficiente para su comprensin.
No
ambiguo
El lenguaje usado en su definicin, no debe causar confusiones.
Cuando puede ser cuantificable, de manera que permita hacer uso de
Verificable
mtodos como la inspeccin, anlisis, demostracin o pruebas
QU ES UN REQUISITO?
Un requisito podra describir:
Una facilidad a nivel usuario
Ej.: el procesador de palabras debe incluir un verificador de
ortografa y un comando de correccin
Una propiedad muy general del sistema
Ej.: el sistema debe asegurar que la informacin personal
nunca se haga disponible sin autorizacin
Una restriccin especfica del sistema
Ej.: el sensor debe ser activado 10 veces por segundo
Una restriccin para el desarrollo del sistema
Ej.: el sistema debe ser desarrollado usando Ada
Cmo llevar a cabo algn clculo
Ej.: la nota final debe ser calculada sumando las notas del
examen, proyecto y cursada del estudiante basado en la siguiente
frmula
nota final = nota_exam + 2 * nota_proy + 2/3 *
nota_cursada
Propiedades del dominio: Cosas en el dominio de aplicacin
que son verdaderas independientemente que se construya o no
el sistema de software
Requisitos: Cosas en el dominio de aplicacin que se desean
sean verdaderas mediante la construccin del sistema de
software
Especificacin: Descripcin de comportamiento (y datos) que
el programa tiene que tener para cumplir los requisitos slo
puede ser descrito en trminos de los fenmenos
compartidos por la maquina y el dominio de aplicacin
ROL DE LOS REQUISITOS
Acuerdo desarrolladores-stakeholders
Aspecto contractual
Multipartes (comunicacin, conflicto y
cambio de visiones)
Base para el diseo del software
Minimizar defectos tanto como sea posible
Proyecto Tcnicamente factible
Soporte para verificacin y validacin
Soporte a la evolucin del sistema
Stakeholder:
Entidad que ser afectada por el
sistema y que tienen una influencia
directa
o
indirecta
sobre
los
requisitos del sistema.
Usuarios finales del sistema
Gerentes involucrados en los procesos organizacionales
influenciados o que influencian al sistema
Ingenieros
responsables
por
el
desarrollo
y
mantenimiento del sistema,
Clientes de la organizacin
Cuerpos externos tales como autoridades reguladoras o
de certificacin.
.
STAKEHOLDERS
Posibles stakeholders de un sistema
automatizado de sealizacin ferroviaria:
Los Operadores responsables de ejecutar el
sistema de sealizacin
Tripulacin del tren
Gerentes ferroviarios
Pasajeros
Ingenieros de instalacin y mantenimiento de
equipos
Autoridades de certificacin de seguridad
PROCESO DE RE
Conjunto de actividades que son seguidas con el
objetivo de descubrir, modelar, validar y mantener
un documento de requisitos.
Sistemas de informacin
existentes
Necesidades de los
stakeholders
Standard de la
organizacin
Regulaciones, polticas e
informacin del dominio
proceso
Requisitos acordados
Modelos del sistema
y su entorno.
QU DEBE HACER EL INGENIERO DE
REQUISITOS?
Punto de inicio
Nocin de existencia de un problema que debe ser
resuelto, ej:
Insatisfaccin con estado corriente del sistema/negocio
Oportunidad del negocio
Potencial ahorro de tiempo, recursos, costos, etc.
Un ingeniero de requisitos en un agente de cambio
El ingeniero de requisitos debe:
identificar el problema/oportunidad
Cual es el problema que se debe resolver? (Identificar los lmites)
en donde se debe resolver (Comprender el contexto)
De quien es el problema ? (Identificar los stakeholders)
Por qu necesita se resuelto? ((Identificar los objetivos de los
stakeholders)
Cmo podra ayudar un S.S. ( Plantear escenarios)
Cuando necesita resolverse? (Identificar restricciones de desarrollo)
Que podra evitar que lo resolvamos? (Identificar riesgos y viabilidad)
ACTIVIDADES DEL PROCESO DE
INGENIERA DE REQUISITOS
Elicitacin
Modelado
Anlisis
Gestin
Identificacin de
Fuentes Inform.
Recoleccin de
hechos
Comunicacin
Representacin
Verificacin
Organizacin
Validacin
Almacenamiento
(registracin)
Negociacin
Identificacin de
cambios
Anlisis de
cambios
Realizacin de
cambios
ACTIVIDADES EN EL PROCESO
Dependiendo del tamao DE
del proyecto
y del modelo de proceso de
LA
IR
software utilizado para el ciclo de desarrollo, las actividades de la IR
varan tanto en nmero como en nombres.
Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniera de Software
MODELO
Oliver and Steiner
EIA / IS-632
IEEE Std 1220-1994
CMM nivel Repetitivo
1996
(2)
Evaluar la
informacin
disponible
Definir mtricas
efectivas
Crear un modelo del
comportamiento del
sistema
Crear un modelo de
los objetos
Activi
dades
Ejecutar el anlisis
Crear un plan
secuencial de
construccin y
pruebas
Anlisis de
requerimientos Requerimientos
Identificacin de
requerimientos
Anlisis del Problema
Anlisis
funcional
Identificacin de
restricciones del
sistema a desarrollar
Comprender las
necesidades de los
involucrados
Anlisis de los
requerimientos
Definir el sistema
Anlisis funcional
Representacin de los
requerimientos
Analizar el alcance del
proyecto
Evaluacin y
estudio de
funciones
Comunicacin de los
requerimientos
Modificar la definicin
del sistema
Validacin de
requerimientos
Administrar los
cambios de
requerimientos
Estudio y evaluacin
del diseo
Sntesis
Anlisis y
control del
sistema
Anlisis de
RUP
Estudio de los
requerimientos
Validacin de
requerimientos
Verificacin de
funciones
Sntesis
EJERCICIO
Definir 10 requerimientos necesarios para el
desarrollo del problema planteado.
PERSONAL INVOLUCRADO
Usuario Final. Es la persona que usar el sistema desarrollado.
Ser quien utilice, disponga y se encuentre familiarizado con los
procesos que debe realizar el software; as tambin, es el que
utiliza las interfaces y los manuales de usuario.
Usuario Lder. Es el individuo que comprende el ambiente del
sistema o el dominio del problema en donde ser empleado el
software desarrollado.
Personal de Mantenimiento. Para proyectos que requieran un
mantenimiento eventual, stas personas son las responsables de
la administracin de cambios, de la implementacin y resolucin
de anomalas. Su trabajo consiste en revisar y mejorar los procesos
del producto finalizado.
PERSONAL INVOLUCRADO
Analistas y programadores. Son los responsables del desarrollo
del producto, en s ellos interactan directamente con el cliente.
Personal de pruebas. Se encarga de elaborar y ejecutar el plan
de pruebas para asegurar que las condiciones presentadas por el
sistema son las adecuadas. Son quienes validan si los
requerimientos satisfacen las necesidades del cliente.
EJERCICI
O
Mostrar una tabla con la cantidad de personal
requerido para el desarrollo y solucin del problema
planteado.
Tipo de personal
Cantidad
Justificacin
ACTIVIDADES DE LA INGENIERA DE
REQUERIMIENTOS
A pesar de las diferentes interpretaciones que cada
desarrollador tenga sobre el conjunto de actividades
mostradas en la tabla anterior, podemos identificar y extraer
cinco actividades principales que son:
Evolucin
Validacin
Especificacin
Evaluacin y
negociacin
Anlisis
del
problema
1. ANLISIS DEL PROBLEMA
El objetivo de esta actividad es entender las verdaderas
necesidades del negocio para el cual se har el proyecto.
Durante el anlisis del problema, se realiza una serie de
pasos para garantizar un acuerdo entre los involucrados,
basados en los problemas reales del negocio, los pasos
serian los siguientes:
Comprender el problema que se est resolviendo
Construir un vocabulario comn
Identificar a los afectados del sistema
Definir los lmites y restricciones del sistema
1. ANLISIS DEL PROBLEMA
El objetivo de esta actividad es entender las verdaderas
necesidades del negocio para el cual se har el proyecto.
Durante el anlisis del problema, se realiza una serie de
pasos para garantizar un acuerdo entre los involucrados,
basados en los problemas reales del negocio, los pasos
serian los siguientes:
Comprender el problema que se est resolviendo
Construir un vocabulario comn
Identificar a los afectados del sistema
Definir los lmites y restricciones del sistema
PARA PROYECTO
Redactar el problema planteado.
Elaborar el vocabulario comn.
Identificar los afectados del sistema.
Definir los lmites y restricciones del problema a
solucionar.
2. EVALUACIN Y NEGOCIACIN DE
REQUERIMIENTOS
Las principales actividades son:
Descubrir problemas potenciales.
Clasificar los requerimientos (Prioridad de cada requerimiento
depender de las necesidades que tenga el negocio)
Busca identificar la importancia que tiene un requerimiento
en
trminos de implementacin.
Mandatario
Deseable (se necesitan pero no son indispensables)
Innecesario
Una vez hecha esta categorizacin de los requerimientos, puedo tomar
como estrategia general el incluir los mandatorios, discutir los deseables y
descartar los innecesarios.
Antes de decidir la inclusin de un
requerimiento, tambin debe analizarse su costo, complejidad, y una
cantidad de otros factores.
Las principales actividades son:
Evaluar factibilidades y riesgos
Factibilidades tcnicas
Factibilidades operacionales
Factibilidades econmicas
Factibilidades tcnicas (pueden implementarse los
requerimientos con la tecnologa actual?);
Factibilidades operacionales (puede ser el
sistema utilizado sin alterar el organigrama
actual?);
Factibilidades econmicas (ha sido aprobado por
los clientes el presupuesto?).
Incremento en la comunicacin entre el equipo de
desarrollo y los afectados. Para una comunicacin
efectiva, hay una serie de consideraciones a tener en
cuenta:
Documentar todos los requerimientos a un nivel de
detalle apropiado.
Mostrar todos los requerimientos a los involucrados
en el sistema.
Analizar el impacto que causen los cambios a
requerimientos antes de aceptarlos.
Establecer las relaciones entre requerimientos que
indiquen dependencias.
Negociar con flexibilidad para que exista un
beneficio mutuo.
Enfocarse en intereses y no en posiciones.
EJERCICIO.
Entregar documento en donde se enlisten los
requerimientos del sistema planteando los puntos
vistos anteriormente, dicho documento ser la
carta de presentacin de los equipos.
Exponer ante los compaeros los requerimientos
fundamentales para llevar a buen trmino la
solucin del problema a plantear. (tiempo de
exposicin max. 10 minutos)
3. ESPECIFICACIN DE REQUERIMIENTOS
DE SOFTWARE.
Es la actividad en que se genera el documento y
contiene una descripcin completa de las
necesidades y funcionalidades del sistema, que
ser desarrollado; describe el alcance del sistema
y la forma como har sus funciones, definiendo
los requerimientos.
En la especificacin se definen:
Todos los requerimientos de hardware
Todos los requerimientos de software
Diagramas
Modelos de sistemas y cualquier otra cosa que sirva de
soporte y gua para fases posteriores.
Los clientes y usuarios utilizan la SRS para comparar si lo
que se est proponiendo, coincide con las necesidades de la
empresa.
Los analistas y programadores la utilizan para
determinar el producto que debe desarrollarse.
El personal de pruebas elaborar las pruebas funcionales
y de sistemas en base a este documento.
Para el administrador del proyecto sirve como
referencia y control de la evolucin del sistema.
4. VALIDACIN DE LOS REQUISITOS
Permite demostrar que los requerimientos definidos en el
sistema son los que realmente quiere el cliente, adems
revisa que no se haya omitido ninguno, que no sean
ambiguos, inconsistentes o redundantes.
La validacin de requerimientos es importante pues de
ella depende que no existan elevados costos de
mantenimiento para el software desarrollado
No debe confundirse la actividad de
evaluacin de requerimientos con la
validacin de requerimientos. La
evaluacin verifica las propiedades de
cada requerimiento, mientras que la
validacin revisa el cumplimiento de las
caractersticas de la especificacin de
requisitos.
Durante la actividad de validacin pueden hacerse preguntas en
base a cada una de las caractersticas que se desean revisar. A
continuacin se presentan varios ejemplos:
Estn incluidas todas las funciones requeridas por el cliente?
(completa)
Existen conflictos en los requerimientos? (consistencia)
Tiene alguno de los requerimientos ms de una
interpretacin? (no ambigua)
Est cada requerimiento claramente representado?
(entendible)
Pueden los requerimientos ser implementados con la
tecnologa y el presupuesto disponible? (factible)
Est la SRS escrita en un lenguaje apropiado? (clara)
Existe facilidad para hacer cambios en los requerimientos?
(modificable)
Est claramente definido el origen de cada requisito?
(rastreable)
Pueden los requerimientos ser sometidos a medidas
cuantitativas? (verificable)
5. EVOLUCIN DE LOS REQUERIMIENTOS
La actividad de evolucin es un proceso externo que
ocurre a lo largo del ciclo de vida del proyecto.
Los requerimientos cambian por diferentes razones:
Porque al analizar el problema, no se hacen las
preguntas correctas a las personas correctas.
Porque cambi el problema que se estaba
resolviendo.
Porque los usuarios cambiaron su forma de
pensar o sus percepciones.
Porque cambi el ambiente del negocio.
