Universidad Peruana de Ciencias Aplicadas

Ensayo: Desarrollo y Gestin

de Requerimientos




Profesor: Aderhold Calderon, Gerd Daniel Holger

Integrantes:

Yengle Acua, Miguel Alexander
Parraga Huapaya, Renzo Adrian
Uribe Linares, Carlos Augusto
Hilario Calixto, Carmen
Guerrero Carhuavilca, Andrea Midori











2014
Universidad Peruana de Ciencias Aplicadas
DOMINIOS DE LA INGENIERA DE REQUERIMIENTOS
La Ingeniera de Requerimientos se divide en Desarrollo y Gestin de requerimientos.
Asimismo, el Desarrollo de requerimientos se sub-divide en elicitacin, anlisis,
especificacin y validacin. A continuacin se desarrollaran las sub-divisiones.
Desarrollo de Requerimientos
1. Elicitacin
Evoca una respuesta de alguien como reaccin a preguntas tales como: Cmo es el
sistema actual?, Cules son sus problemas?, Qu objetivos de mejora hay?, Qu
estrategias para lograr estos objetivos existen?, etc. El objetivo de la elicitacin es
adquirir conocimientos relevantes del problema, que se utilizarn posteriormente para
producir una especificacin formal del software necesario para resolverlo.
1


Adems, es importante que exista una buena comunicacin entre el desarrollador y el
cliente. Mantener reuniones con clientes sin conocer las caractersticas de su actividad
har que probablemente no se entiendan sus necesidades y que su confianza inicial
hacia el desarrollo se vea deteriorada enormemente. Es por ello que se han desarrollado
numerosas tcnicas para que el inicio del proceso sea exitoso. A continuacin se
resumen algunas de las ms conocidas:

Entrevistas: Son la tcnica ms utilizada, y de hecho inevitables en cualquier
desarrollo. En las entrevistas se pueden identificar claramente tres fases:
preparacin, realizacin y anlisis.
2


Brainstorming: Es una tcnica de reuniones en grupo cuyo objetivo es la
generacin de ideas en un ambiente libre de crticas o juicios. Ayuda a generar
una gran variedad de vistas del problema y a formularlo de diferentes formas.
3


Casos de Uso: Son una tcnica para especificar el comportamiento de un sistema:
Un caso de uso es una secuencia de interacciones entre un sistema y actores que
usan alguno de sus servicios. Facilitan la elicitacin de requerimientos y son
fcilmente comprensibles por los clientes y usuarios.
4


J AD(J oint Application Development): Se desarrolla a lo largo de un conjunto
de reuniones en grupo durante 2 o 4 das. En estas reuniones se ayuda a los
clientes y usuarios a formular problemas y explorar posibles soluciones,
involucrndolos y hacindolos sentirse partcipes del desarrollo.

2. Anlisis
En esta etapa se analizan los diversos puntos de vista y se utiliza una combinacin de
mtodos, personas y herramientas. El resultado final constituye la documentacin de los
requerimientos. stos deben expresarse de forma clara y estructurada de manera que
puedan ser entendidos tanto por expertos como por el usuario, quien deber participar

1
Cfr. Gil 2002:12
2
Cfr. Gil 2002:17
3
Cfr. Gil 2002:18
4
Cfr. Gil 2002:20
Universidad Peruana de Ciencias Aplicadas
en la futura validacin. Como resultado del anlisis se desarrolla la especificacin de
requerimientos del software. La revisin es esencial para asegurar que el realizador del
software y el cliente tengan la misma percepcin del sistema.

3. Especificacin
Es la documentacin completa y detallada, puede ser vista como un contrato entre
usuarios y desarrolladores de software, que define el comportamiento funcional deseado
del artefacto de software (y otras propiedades de ste, tales como performance,
confiabilidad, etc.), sin mostrar cmo ser alcanzada tal funcionalidad. Esto ms
adelante permitir llegar a determinar si se ha llegado a comprender el software, en los
casos que se lleguen a modelar se pueden dejar plasmados manuales.
5


4. Validacin
Es el proceso que certifica que el modelo de los requerimientos es consistente con las
intenciones de los clientes y los usuarios; sta es una visin ms general que el concepto
comn de validacin, pues se produce en paralelo con la elicitacin y la especificacin,
tratando de asegurar que tanto las ideas como los conceptos presentados en una
descripcin se identifican y explican con claridad. La validacin no slo se aplica al
modelo final de los requerimientos, sino tambin a los modelos intermedios.
6


Gestin de requerimientos
Es el proceso de control y cambios en los requerimientos. Establece y controla la lnea
base de los requerimientos. Ayudan al equipo de trabajo a identificar, controlar y seguir
los requisitos y los cambios en cualquier momento. Muchas de estas actividades son
idnticas a las tcnicas de gestin de configuracin de software.
7


NIVELES DE REQUERIMIENTOS
Los Niveles de Requerimientos son empleados para poder comprender un problema,
describirlo y obtener soluciones en base a una documentacin previa de las necesidades
del cliente o empresa. Por un lado, existen mtodos sistemticos y estrategias de
recoleccin de datos para realizar esta documentacin. Por ejemplo el mtodo CORE
8

(Controlled Requirements Expression) y el proceso de anlisis de requerimientos de
software de Pressman
9
en el cual se observan 5 etapas: reconocimiento, evaluacin,
modelizacin, especificacin y revisin.

No obstante, existen tres niveles en la Ingeniera de Requerimientos que sern
explicados a continuacin:



5
Cfr. Gil 2002 : 12
6
Cfr. Gil 2002 : 12
7
Cfr. Prez 2005 : 61
8
Cfr. Gil 2002 : 10
9
Cfr. Gil 2002 : 9
Universidad Peruana de Ciencias Aplicadas
Necesidades
Este primer nivel ayuda a entender la problemtica de los Stakeholders. Por un lado, los
mtodos de recoleccin de datos que se apliquen, como preguntas o cuestionarios,
deben reflejar sus requisitos. Por ello, gestionar las necesidades del proyecto en forma
estructurada
10
y documentada brindar informacin para el desarrollo de soluciones.

Caractersticas
En este segundo nivel se muestra todo lo recolectado y se establecen sistemas a
construir. Para ello, gracias a la previa documentacin y recoleccin de informacin que
se realiz, se proporcionan y ejecutaran modelos que puedan satisfacer las necesidades
de los Stakeholders.

Requerimientos
En este ltimo nivel, el software debe de cumplir con todo lo que se ha establecido en
los niveles anteriores. Cumplir con las necesidades de los Stakeholders como la
funcionalidad, la eficiencia, entre otros son algunas de las caractersticas que debe
poseer el producto final.


TIPOS DE REQUERIMIENTOS
Segn la metodologa RUP los requerimientos funcionales y los no funcionales estn
detallados en un documento llamado RES (Reporte de especificacin de Software).
Requerimientos funcionales
Son todas la funcionalidades que tendr o se agregaran en el transcurso de la
elaboracin del sistema. Describen las transformaciones que el sistema realiza sobre las
entradas para producir salidas, especifican los servicios que debe proporcionar la
aplicacin. Tambin, se define como el comportamiento interno de la aplicacin puede
realizar clculos, registros, modificacin, etc.
Requerimientos no funcionales
Est relacionado con las caractersticas que de una u otra forma puedan limitar el
sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario,
fiabilidad, mantenimiento, seguridad, portabilidad, estndares, es el cmo, cundo,
cuanto, del qu. Son aquellas caractersticas que tiene que tener el sistema, la
plataforma en donde ha sido programado, la capacidad, el soporte de base de datos, etc.
Tipos de requerimientos no funcionales:
Consideracin de Diseo : motor de base de datos por ejemplo utilizar SQL
server, la metodologa usada como RUP, el lenguaje como java, basado en

10
Cfr. Prez 2005 : 14
Universidad Peruana de Ciencias Aplicadas
plataforma web o escritorio, con que SO(sistema operativo) est compatible y el
servidor usado como Tomcat entre otros.
Facilidad de uso: si ser entendible y amigable para cualquiera usuario.
Seguridad: en algunas aplicaciones se usara Login en donde se contar con
una contrasea para acceder al sistema
Requerimientos fsicos: la capacidad de la pc en donde se ejecutara el sistema
sin ningn problema

CARACTERSTICAS DE LOS REQUERIMIENTOS
Un conjunto de requerimientos en estado de desarrollo, deben presentar una serie de
caractersticas tanto individualmente como en grupo. A continuacin se presentan las
ms importantes:
Especfico: Debe ser especfico por escrito como un contrato o un acuerdo.
Necesario: Un requerimiento es necesario si su omisin provoca una deficiencia
en el sistema a construir, y adems su capacidad, caractersticas fsicas o factor
de calidad no pueden ser reemplazados por otras capacidades del producto o del
proceso.
Conciso: Un requerimiento es conciso si es fcil de entender. Su redaccin debe
ser simple y clara para aquellos que vayan a consultarlo en un futuro o
verificarlo.
Completo: Un requerimiento est completo si no necesita ampliar detalles en su
redaccin, es decir, si se proporciona la informacin suficiente para su
comprensin.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretacin. El lenguaje debe ser entendible para el lector.
Verificable: Si un requerimiento no est terminado y no se puede comprobar,
entonces como sabemos si est terminada o no. Un requerimiento es verificable
cuando puede ser cuantificado de manera que permita hacer uso de los siguientes
mtodos de verificacin: inspeccin, anlisis, demostracin o pruebas.
Por lo tanto, el requerimiento debe de ser:
Especificados por escrito; como todo contrato o acuerdo, posibles de comprobar o
verificar; si un requerimiento no se puede comprobar; entonces cmo sabemos si
cumplimos con l o no? o si es factible o no?, descritos como una caracterstica del
sistema a entregar; esto es que es lo que el sistema debe de hacer (y no como debe
de hacerlo) y finalmente lo ms abstracto y conciso posible para que el lector
entienda y no tenga dudas.

Universidad Peruana de Ciencias Aplicadas
BIBLIOGRAFA
ARIAS CHAVEZ, Michael (2006) La ingeniera de requerimientos y su importancia en
el desarrollo de proyectos de software (consulta: 23 de agosto de 2014)
( http://revistas.ucr.ac.cr/index.php/intersedes/article/download/790/851).
GIL, Gustavo (2002) Herramienta Para Implementar LEL y Escenarios (TILS) (Tesis al
Dpto. de Informtica). La Plata: Universidad Nacional de La Plata Argentina.

GUZMAN, Gisella (2010) Anlisis y Diseo de Sistemas I. Lima: Fondo Editorial
Cibertec de la Universidad Peruana de Ciencias Aplicadas.

PREZ, Lourdes (2005) Ingeniera de Requerimientos. Pachuca: Universidad
Autnoma del Estado de Hidalgo.