2017

FUNDAMENTO DE
INGENERIADE
SOFTWARE

INSTITUTOTECNOLGICO DE VERACRUZ
GUSTAVO ANGEL SNCHEZ SNCHEZ
 INICIO
Tienepor objetivo identificar el mbito general del proyecto. Comienza con una
serie de conversaciones informales entre los participantes del mismo (cliente,
usuarios, grupo de desarrollo).
Esta fase suele estar acompaada de los documentos de definicin de la visin
global y la visin de dominio del sistema.

Segn Carpers Jones dice por lo general, las semillas de los desastres ms
importantes en software se siembra en los primeros tres meses desde el comienzo
del proyecto

En algunos casos una conversacin informal es todo lo que se necesita para

precipitar un esfuerzo importante de ingeniera del software. Pero en general, la
mayora de los proyectos comienza cuando se identifica una necesidad de negocios
o se descubre un nuevo mercado o servicio potencial. Los participantes de la
comunidad de negocios(es decir, los gerentes, gentes de mercadotecnia, gentes de
producto) definen un caso de negocios para la idea, tratan de identificar la
amplitud y profundidad del mercado, hacen un anlisis preliminar de factibilidad, e
identifican una descripcin funcional del mbito del proyecto. Toda esta
informacin est sujeta a cambios (una situacin probable) pero es suficiente para
suscitar conversaciones con la organizacin de ingeniera del software.
Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres
de contexto, el objetivo es establecer una comprensin bsica del problema, las
personas que quieren una solucin, la naturaleza de la solucin que se desea, y la
efectividad de la comunicacin preliminar entre el cliente y el desarrollador.
 OBTENCIN
Sugiere a los ingenieros actividades de recopilacin de requisitos de manera
organizada.Parece muy simple preguntar al cliente, a los usuarios y otros
interesados cules son los objetivos para el sistema o producto, que es lo que se
debe lograr, de que forma el producto satisface las necesidades del negocio y por
ltimo como se utilizara el sistema o producto da a da. Pero no es simple, es muy
difcil ya que se identifican una serie de problemas que ayudan a entender porque
es difcil la obtencin de requisitos:

Problema de mbito: El lmite del sistema est mal definido o los

clientes/usuarios especifican detalles tcnicos innecesarios que pueden
confundir, en lugar de clarificar, los objetivos generales del sistema.

Problemas de comprensin: Los clientes/usuarios no estn seguros por

completo de que es lo se necesita, comprenden poco acerca de las
capacidades ylimitaciones de sus ambiente de computo, no comprende
del todo dominio del problema, tienen dificultades al comunicar
necesidades al ingeniero de sistema, omiten informacin que consideran
obvia, especifican requisitos que chocan con las necesidades de otros
clientes/usuarios, o especifican requisitos ambiguos o inestable.

Problemas de volatilidad:Los problemas cambiara conform transcurre el

tiempo.
Para ayudar a superar estos problemas, los ingenieros de requisitos deben
realizar en forma organizada la actividad de recopilacin de requisitos
 ELABORACIN
Los ingenieros de software crean un modelo de anlisis con la informacin
obtenida del cliente en las fases de inicio y obtencin. El modelo de anlisis define
el dominio de la informacin, las funciones y el compartimiento del

problema.

La informacin conseguida con el cliente durante el inicio y obtencin se expande y

se refina durante la elaboracin. Esta actividad de la ingeniera de requisitos se
enfoca en el desarrollo de un modelo tcnico refinado de las funciones,
caractersticas y restricciones del software.

La elaboracin del modelado del anlisis y su componente de una serie de tareas de

modelado y refinamiento. La elaboracin se conduce mediante la creacin y
refinamiento de escenarios del usuario que describen la forma en que el usuario
final(y otros actores) interactuaran con el sistema. Cada escenario del usuario se
analiza para obtener clases del anlisis: entidades del dominio de negocios visibles
para el usuario final. Se definen los atributos de cada clase de anlisis y se
identifican los servicios que requiere cada clase. Se identifican las relaciones y la
colaboracin entre las clases y se produce una variedad de diagramas de UML
complementarios.

El resultado final de la elaboracin es un modelo de anlisis que definen el dominio

de la informacin, las funciones y el comportamiento del problema.

NEGOCIACIN
Durante esta etapa el ingeniero de requisitos debe negociar con el cliente los
alcances y lmites del sistema. De forma iterativa los requisitos se priorizan,
modifican, combinan o eliminan buscando acuerdos que beneficien a todas las
partes.
Dados los recursos limitados del negocio, no resulta inusual que los clientes y
usuarios pidan ms de lo que se puede lograr. Tambin es relativamente comn
que diferentes clientes o usuarios propongan requisitos que entran en conflicto
entre s al argumentar que su versin es esencial para nuestra necesidades
especiales.
El ingeniero de requisitos debe conciliar estos conflictos por medio de un proceso
de negociacin. Se pide a los clientes, usuarios y otros interesados que ordenen sus
requisitos y despus discutan los conflictos relacionados con la prioridad. Se

identifican y analizan los riesgos asociados con cada requisito. Se hacen

estimaciones preliminares del esfuerzo requerido para su desarrollo y despus se
utilizan para evaluar el impacto de cada requisito en el costo del proyecto y sobre el
tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan,
combinan o modifican de forma que cada parte alcance cierto grado de satisfaccin.

ESPECIFICACIN
Es el producto final de la ingeniera de requisitos, y se convierte en la materia
prima para las actividades posteriores en el proceso de desarrollo del sistema. La
formalidad y especificacin varan dependiendo de la complejidad del proyecto.

En el contexto de los sistemas basados en computadora (y en software), el trmino

especificacin tiene significados diferentes para personas distintas. Una
especificacin puede ser un documento escrito, un conjunto de modelos grficos,
un modelo matemtico formal, una coleccin de escenarios de uso, un prototipo o
cualquier combinacin de estos.
Algunos sugieren que para una especificacin se debe desarrollar y utilizar una
plantilla estndarargumenta que esto conduce a que los requisitos sean
presentados de una manera msconsciente y por ende ms entendible. Sin
embargo, algunas veces es necesario ser flexible mientras se desarrolla una
especificacin.
Respecto de sistema grande el mejor enfoque podra ser un documento escrito que
combinara descripciones en el lenguaje natural y modelos grficos. Por otro lado,
en cuanto a productos o sistemas ms pequeos, podra ser que no se necesite ms
que escenarios de uso, cuando dichos sistemas residan en ambientes tcnicos que
se comprendan bien.
La especificacin es el producto de trabajo final que genera a ingeniera de
requisitos. Sirve como base para las actividades de ingeniera de software
subsecuentes.
 Describe la funcin yel desempeo de un sistema basado en computadora y las
restricciones que regirn su desarrollo.

VALIDACIN
Un equipo de validacin toma el producto de la fase de especializacin, lo revisa
para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la
consistencia de los requisitos.

La calidad de los productos de trabajo procedentes de la ingeniera de requisitos se

evala durante un paso de validacin. La validacin de requisitos examina la
especificacin para asegurar que todos los requisitos de software se han
establecidos de manera precisa; que se han detectado las inconsistencias omisiones
y errores y queestos han sido corregidos, y que los producto de trabajo cumplen con
los estndares establecidos para el proceso, proyecto y producto.
El mecanismo primario para la validacin de requisitos es la revisin tcnica formal.
El equipo de revisin que valida los requisitos incluye ingenieros de software,
clientes, usuarios y otros interesados que examinan la especificacin y buscan
errores en el contenido o la interpretacin, reas que tal vez requieran una
clasificacin, informacin faltante, inconsistencia (que es problema importante)
cuando se desarrollan productos o sistemas grandes), conflictos entre los
requisitos, o requisitos irreales (inalcanzables).

GESTIN DE REQUISITOS
Ayuda al equipo de proyecto a rastrear los requisitos segn las caractersticas de los
mismos, el cdigo fuente relacionado, dependencia entre requisitos, subsistemas e
interfaces internas y externas; de forma que pueda identificarse con rapidez para
entender cmo afectar una modificacin diferentes aspectos del sistema a
construir.

La gestin de requisitos es un conjunto de actividades que ayudan al equipo de

proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en
cualquier momento mientras se desarrolla el proyecto.Muchas de estas actividades
son idnticas a las actividades de la gestin de la configuracin del software(GGS).
La gestin de requisitos comienza con la identificacin. Cada requerimiento se
asigna a un solo identificador. Una vez identificados los requisitos se desarrollan
las tablas de rastreabilidad que son las siguientes:

Tabla de rastreabilidad de las caractersticas. Muestra la manera en que los

requisitos se relacionan con las caractersticas del sistema/producto observables
para el cliente.
Tabla de rastreabilidad de la fuente. Identifica la fuente de cada requisito.
Tabla de rastreabilidad de dependencia.Indica la forma en que los requisitos
estn relacionados entre s.
Tablas de rastreabilidad del subsistema. Establece categoras entre los
requisitos de acuerdo con el (los) subsistema(s) que gobierna(n).
Tablas de rastreabilidad de la interfaz. Muestra la forma en que los
requisitos se relacionan con las interfaces internas y externas del sistema.
En muchos casos, esas tablas de rastreabilidad se mantienen como parte de la base
de datos de los requisitos de forma que pueda buscrsele con rapidez para entender
como el cambio en un requisito afectara diferentes aspectos del sistema que se
construir.

Los requerimientos en un proyecto no solo comprenden las tareas de captura y

manejo de los cambios a lo largo de todo el proyecto, tambin comprenden de
estas otras tareas:

1. I d e nt i f i car l o s s t a k e ho l d e rs ( s e refiere a quienes pueden

afectar o son afectados por las actividades de una empresa): Se describe
una lista de toda la persona interesada en el desarrollo del sistema.
2. Entender las necesidades de los usuarios y clientes necesarias para planear el sistema y
sus expectativas.
3. I d e n t i f i c ar l o s r e q u e r i m ie n t o s: Inicialmente los requerimientos
provienen de los objetivos que plantea el negocio. En esta actividad los
requerimientos se indican por medio de sentencias. En un escenario de
negocio se usa para entender los requerimientos del negocio.
4. Aclarecer y refinar los requerimientos:Esta actividad se ejecuta
cuando se tiene plena seguridad plena certeza de que los requerimientos
indican las necesidades reales del cliente y que estos pueden ser usados por
el resto de equipos en el proyecto.
5. A n a li z a r lo s r e q u er i m i e n t os : Se realiza cuando los requerimientos
se encuentran bien definidos y cumplen con el criteriode un buen
requerimiento.
6. Definir los requerimientos de forma estndar para los
stakeholders:Debido a que cada stakeholders tiene una perspectiva
diferente del sistema y susrequerimientos, es importante esforzar un poco
de tiempo en la descripcin de losrequerimientos usando un vocabulario
adecuado.
7. E s p eci fi car l o s re q u e r i m ie n t o s : Cada requerimiento debe
expresarse en forma detallada de tal manera que pueda ser incluido en otros
documentos de especificacin o en otros proyectos.
8. P r i or i z a r lo s r e q u e r i m ie n t o s: Todos los requerimientos tienen
niveles diferentes de importancia para los clientes yusuarios. Unos tienen
prioridad crticas, otros no tanta y otros de bajo nivel de prioridad.La
priorizacin de los requerimientos es una actividad que nos va a permitir
desarrollar nuevas versiones de nuestro proyecto de forma continua sin
verse retrasadas por tiempo ensus salidas.
9. D e r iv ar l os r e q u er i m i e n t o s : Esta actividad nos permite detallar
requerimientos no visibles para nuestros clientes ousuarios que no se han
logrado identificar, pero que son importantes para el
funcionamientoadecuado del requerimiento en detalle.
10. Particionarlos requerimientos:donde se clasifican los requerimientos en
diferentes criterios: Hardware, software yentrenamiento.
11. Asignar los requerimientos:Esta actividad asigna los requerimientos a
diferentes subsistemas y componentes internos.
12. Hacer seguimiento a los requerimientos:Se desarrolla la capacidad de
permitir que un requerimiento satisfecho pueda ser referenciado dentro del
sistema.
13. Manejar los requerimientos:Se desarrolla un sistema de control de los
requerimientos, necesario para adicionar, modificar y borrar
requerimientos, al igual que la implantacin de un repositorio para estos.
14. Probar y verificar los requerimientos:En esta actividad se validan los
requerimientos, diseos, cdigo,etc... Para asegurarse quelos requerimientos
estn bien.
15. Validar los requerimientos:Finalmente se confirman los requerimientos
Bibliografia

http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm
http://es.scribd.com/doc/270431/Ingenieria-requerimientos
http://www.monografias.com/trabajos6/resof/resof.shtml
http://redalyc.uaemex.mx/pdf/666/66661111.pdf
http://ldc.usb.ve/~abianc/materias/ci4712/apuntes3.pdf
http://es.scribd.com/doc/19083744/INGENIERIA-DE-REQUERIMIENTOS
http://www.monografias.com/trabajos5/inso/inso2.shtml
http://www.arcos.inf.uc3m.es/~ii_si/IngReqCIII.pdf
http://www.rodolfoquispe.org/blog/que-es-la-ingenieria-de-requisitos.php