IR02 Ingeniería de Requerimientos

Ingeniera de requerimientos
Ingeniera de Sistemas e Informtica
Propsito y contenido de la sesin

Propsito de la sesin
Describe la importancia de
la ingeniera de
requerimientos.
Contenido de la sesin
Introduccin a la
administracin de
requerimientos.
Recapitulando
Introduccin Ingeniera del Software

Desarrollo del hardware
Desde 1965 la Ley de Moore rige la evolucin de los microprocesadores
100.000.000
Pentium IV
Pentium III
10.000.000
Pentium II
Transistores
Pentium
486 DX
1.000.000
386
286
100.000
8086
10.000
8080
4004
8008
1970
1975
1980
1985
1990
1995
2000
Factores que imprimen aceleracin al ritmo de crecimiento del hardware:

Incremento de la capacidad de operacin.
Consecuencias de la ley de Moore
Incremento de la miniaturizacin.
Reduccin de costes en la produccin.
Comunicaciones entre sistemas

4

Crisis de software
Proyectos para el desarrollo de sistemas de software
Fracaso
2004
2000
1998
19%
53%
23%
28%
46%
40%
31%
xito
29%
49%
28%
1995
1994
Problemtico
26%
33%
27%
53%
16%
El proyecto se aborta o el sistema no se llega a utilizar

Desbordamiento de agendas o costes. Las funcionalidades no cubren las
expectativas. Problemas funcionales
Proyecto realizado en el tiempo previsto, con los costes previstos, con la
funcionalidad esperada y ofreciendo un funcionamiento correcto.
Fuente: Standish Group Survey,
5
Crisis de software

Crisis del software
Este problema se identific por primera vez en 1968, ao en el que la organizacin NATO desarroll
la primera conferencia sobre desarrollo de software, y en la que se acuaron los trminos crisis
del software para definir a los problemas que surgan en el desarrollo de sistemas de software, e
ingeniera del software para describir el conjunto de conocimientos que existan en aquel
estado inicial.
Algunas referencias tiles para comprender cules eran los conocimientos estables para el
desarrollo de software en 1968 son:
En 1962 se public el primer algoritmo para bsquedas binarias.
En 1968 los programadores se debatan entre el uso de la sentencia GoTo, y la nueva idea
de programacin estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribi
su famosa carta GoTo Statement Considered Harmful en 1968.
La primera publicacin sobre programacin estructurada no vio la luz hasta 1974, publicada
por Larry Constantine, Glenford Myers y Wayne Stevens.
El primer libro sobre mtrica de software fue publicado en 1977 por Tom Gilb.
C. Bhm y G. Jacopini publicaron en 1966 el documento que creaba una fundacin para la
eliminacin de GoTo y la creacin de la programacin estructurada.
El primero sobre anlisis de requisitos apareci en 1979
10

Ingeniera del software
Definicin original:
Establecimiento y uso de principios de ingeniera para obtener software
econmico que trabaje de forma eficiente en mquinas reales.
Fritz Baver, 1968 (conferencia NATO)
Otras definiciones
Disciplina para producir software de calidad desarrollado sobre las agendas y
costes previstos y satisfaciendo los requisitos.
S. Schach 1990, Software Engineering
(1) La aplicacin de mtodos sistemticos, disciplinados y cuantificables para el

desarrollo, operacin y mantenimiento de software; esto es, la aplicacin de la
ingeniera al software.
(2) El estudio de (1).
IEEE 1993
11

Ingeniera del software
Desde 1968 hasta la fecha han sido muchos los esfuerzos realizados por los departamentos de
informtica de las universidades, y por organismos de estandarizacin (SEI, IEEE, ISO) para
identificar las causas del problema y definir pautas estndar para la produccin y mantenimiento del
software.
Los esfuerzos se han encaminado en tres direcciones principales.
Identificacin de los factores clave que determinan la calidad del software.

Identificacin de los procesos necesarios para producir y mantener software.
Acotacin, estructuracin y desarrollo de la base de conocimiento necesaria para la
produccin y mantenimiento de software.
El resultado ha sido la necesidad de profesionalizar el desarrollo, mantenimiento y

operacin de los sistemas de software, introduciendo mtodos y formas de trabajo
sistemticos, disciplinados y cuantificables.
La forma de trabajo de programadores individuales surgida por la necesidad de los primeros
programas, ha creado una cultura de la programacin heroica, para el desarrollo de software que es
la principal causa de los problemas apuntados, y en la actualidad una de las principales resistencias
a la implantacin de tcnicas de ingeniera para el desarrollo de sistemas
12

Principales organizaciones de estandarizacin
ISO
Organizacin Internacional para la Estandarizacin. Fundada en 1947
Son miembros 87 pases.
En 1987 la Organizacin Internacional para la Estandarizacin (ISO) y la Comisin
Internacional Electrotcnica (IEC), establecieron un Comit Internacional (JTC1) para las
Tecnologas de la Informacin. La misin del JTC1 es la estandarizacin en el campo de
campo de los sistemas de tecnologas de la informacin, incluyendo microprocesadores y
equipos.
Los estndares o instrucciones tcnicas ms importantes para la Ingeniera del Software:
SEI
ISO/IEC 12207
ISO/IEC TR 15504
Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/).

Integrado en la Universidad Carnegie Mellon.
Los trabajos y aportaciones realizadas por el Instituto de Ingeniera del Software a la
Ingeniera del software son tambin referente mundial de primer orden, siendo la aportacin
ms significativa los modelos de madurez de las capacidades: CMM y CMMI; que en sus casi
15 aos de implantacin efectiva en entornos de produccin de software han demostrado su
efectividad en las dos finalidades que cubren: como marco de referencia para mejora de
procesos, y como criterio de evaluacin para determinar la madurez, y por tanto fiabilidad de
resultados previsibles de una organizacin de software.
13

Principales organizaciones de estandarizacin
IEEE Computer Society

IEEE Es el Instituto de Ingenieros en electricidad y electrnica (Institute
of Electrical and Electronics Engineers).
Su misin es preservar, investigar y promover la informacin de las
tecnologas elctricas y electrnicas.
Surgi en 1963 con la fusin del AIEE (Instituto Americano de Ingenieros Elctricos) y el
Instituto de Ingenieros de Radio (IRE).
La IEEE Computer Society (www.computer.org) es una sociedad integrada en IEEE, formada en
la actualidad por ms de 100.000 miembros en todo el mundo.
Su finalidad es avanzar en la teora, prctica y aplicacin de las tecnologas de la informacin.
Realiza conferencias, publicaciones, cursos de formacin, y desarrolla estndares.
Estndares para la Ingeniera del Software
IEEE ha desarrollado estndares para todas las reas de Ingeniera del Software.
Algunos de ellos, correspondientes a las principales reas especficas de la Ingeniera del
Software son:
IEEE
IEEE
IEEE
IEEE
IEEE
Std.
Std.
Std.
Std.
Std.
830 Prcticas recomendadas para las especificaciones de software.

1362 Gua para la especificacin del documento de requisitos ConOps
1063 Estndar para la documentacin de usuario de software.
1012 Estndar para la verificacin y validacin de software.
1219 Estndar para el mantenimiento del software
14

Principales estndares y modelos
La Ingeniera del Software es una ingeniera muy joven que necesitaba:
Definirse a s misma: Cules son las reas de conocimiento que la comprenden?

SWEBOK: Software Engineering Body of knowledge
Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

del software
ISO/IEC 12207: Procesos del ciclo de vida del software
De las mejores prcticas, extraer modelos de cmo ejecutar esos procesos para
evitar los problemas de la crisis del software
CMM / CMMI
ISO/IEC TR 15504
Definir estndares menores para dibujar criterios unificadores en requisitos,

pruebas, gestin de la configuracin, etc.
IEEE 830 - IEEE 1362 - ISO/IEC 14764
15

SWEBOK
El proyecto SWEBOK (Software Engineering Body of Knowledge) comenz sus actividades de
manera efectiva dentro del SWECC1 en 1997 (aunque el comit SWECC se cre en 1993).
En el proyecto tambin estn representados:
los dos principales organizaciones de estandarizacin en Ingeniera del Software: IEEE e ISO/IEC
JTC1/SC/.
Los autores de las tres principales obras de Ingeniera del Software: Steve Mc Connell, Roger
Pressman e Ian Sommerville.
Universidad de Qubec (Montreal)
Empresas y organizaciones como: Rational, SAP, Boeing, Construx, MITRE, Raytheon,
En 2001 el proyecto public ya una definicin consensuada del cuerpo de conocimiento aceptado en
la ingeniera del software (http://www.swebok.org).
Las fuentes de informacin para la identificacin de las reas de conocimiento han sido los ndices
de textos genricos sobre la Ingeniera del Software, los curricula para licenciatura y postgrado en
Ingeniera de Software, y los criterios de admisin que se utilizan en el postgrado. Todos estos
datos se han organizado siguiendo el estndar ISO/IEC 12207.
El cuerpo de conocimiento identificado por el proyecto SWEBOK se ha configurado como el estudio
ms relevante y como la referencia de ms autoridad en toda la comunidad informtica para la
acotacin y descripcin de los conocimientos que configuran la Ingeniera del software.
1 Software, Engineering Coordinating Comitee, Comisin creada por IEEE Computer Society y ACM (Association for Computer Machinery) para definir
el cuerpo de la Ingeniera del Software
16

SWEBOK
SWEBOK da el primer paso necesario para constituir a la Ingeniera del Software como profesin: la
delimitacin del cuerpo de conocimiento que comprende la profesin. Sin esta delimitacin no es
posible validar de forma universal exmenes de licenciatura, no es posible la preparacin para
acceder a la profesin, y no hay un consenso sobre el contenido de su currculo.
El proyecto parte de la suposicin de que es necesario establecer cul es el cuerpo de conocimiento
que deben conocer los ingenieros del software, y en su desarrollo ha agrupado este conocimiento
en 10 reas
Requisitos
Diseo
Construccin
Pruebas
Mantenimiento
Gestin de la configuracin
Gestin
Procesos
Herramientas y mtodos
Calidad
Es importante resaltar que estas reas no incluyen aspectos importantes de las tecnologas de la
informacin, tales como lenguajes especficos de programacin, bases de datos relacionales o redes
o tecnologa de redes y comunicaciones.
Esta es una consecuencia de la distincin que entre esencia y accidente se establece desde un
enfoque de ingeniera.
Por supuesto que un Ingeniero de Software debe conocer las tcnicas de cada momento, pero la
definicin de procesos y metodologa de trabajo es la esencia de la profesin. As por ejemplo, el
rea de conocimiento de requisitos, s que puede considerarse como esencia de la profesin. Los
problemas que pueden derivarse en un proyecto por una mala obtencin o gestin de los requisitos
son indistintos del hardware o lenguaje de programacin empleado. Eran los mismos hace dos
dcadas que ahora, y todo nos hace suponer que seguirn siendo idnticos dentro de otros cuatro
lustros.
17
Requisitos del software
18

Importancia de los requisitos
Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender

perfectamente los requisitos del software. Independientemente de lo bien diseado o
codificado que est un programa, si se ha analizado y especificado pobremente,
decepcionar al usuario y desprestigiar al que lo ha desarrollado.
Roger S. Pressman Ingeniera del Software Mc Graw Hill 1995
La parte ms difcil en la construccin de sistemas software es decidir

precisamente qu construir. Ninguna otra parte del trabajo conceptual es tan ardua
como establecer los requerimientos tcnicos detallados, incluyendo todas las
interfaces con humanos, mquinas y otros sistemas software. Ninguna otra parte
del trabajo puede perjudicar tanto el resultado final si se realiza de forma errnea.
Ninguna otra parte es tan difcil de rectificar posteriormente.
Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1995.
19

Qu porcentaje de proyectos concluyen con xito?

Un estudio realizado por Standish Group analiz el desarrollo de 8000 proyectos de software,
realizados por 350 empresas diferentes y concluy que slo el 16% de los proyectos de
software se realizan con xito.
El estudio identific como principales causas de los problemas:
Requisitos deficientes
La planificacin de agendas y estimaciones de costes no se realizaron en base a los
requisitos
Deficiencias en la aplicacin de procesos y desconocimiento del ciclo de vida del proyecto
Los criterios para determinar el xito de un proyecto son:
Sin desviaciones en las fechas previstas.

Sin desviaciones en los costes estimados.
Que el producto final cubra las expectativas y necesidades del cliente.
Que funcione correctamente.
20

Porqu fracasan los proyectos?
Requisitos incompletos: 13%

Cambios en requisitos: 9%
No implicacin de usuarios: 12%
Expectativas no realistas: 10%

Producto no necesario: 8%
TOTAL: 52%
21

50-200X
Coste de la
correccin
50-200X
Fase en la que se
detecta el fallo
Requisitos
1X
1X
Arquitectura
Diseo detallado
Construccin
Requisitos
Arquitectura
Diseo detallado
construccin
Produccin
Fase en la que se soluciona el fallo

22

Sus defectos repercuten en todas las fases

REQUISITOS
Estimacin
E1
Planificacin
Diseo
Construccin
V&V
Los errores en los requisitos se comportan como una enfermedad contagiosa que siempre repercute
en todas las fases del proyecto.
Estimacin: No es posible estimar con rigor costes y recursos necesarios para desarrollar
algo que no se conoce.
Planificacin No se puede confiar en la planificacin para el desarrollo de algo que no se
sabe bien como es.
Diseo: Los errores en requisitos, las modificaciones frecuentes, las deficiencias en
restricciones o futuras evoluciones, producen arquitecturas que ms tarde se confirmarn
como errneas y sern modificadas.
Construccin: Las deficiencias en los requisitos obligan a programar en ciclos de prueba y
error que derrochan horas y paciencia de programacin sobre patrones de recodificacin
continua y programacin heroica.
Validacin y verificacin: Terminado el desarrollo del sistema, si las especificaciones tienen
errores de bulto, o peor an, no estn reflejadas en una especificacin de requisitos, no
ser posible validar el producto con el cliente.
23

Los defectos comunes en los requisitos y sus consecuencias.

Implicacin insuficiente
del cliente
Problemas en la validacin
del producto obtenido
Requisitos crecientes
y cambiantes
Degradacin de la estructura
y arquitectura del producto
Requisitos ambiguos
Prdida de tiempo en
re-codificacin
Requisitos
innecesarios
Trabajo innecesario
Requisitos mnimos
(insuficientes)
Problemas en la validacin
del producto obtenido
Requisitos mnimos
(insuficientes)
Error en la estimacin
y planificacin
Omisin de las necesidades

de grupos de usuarios
Usuarios insatisfechos
24


Implicacin insuficiente del cliente
Algunos clientes no comprenden la importancia de trabajar con rigor en la obtencin de los
requisitos, para garantizar la calidad de los resultados.
Tambin es frecuente que los desarrolladores prefieran comenzar a trabajar en la
construccin del sistema, porque les resulta ms atractivo que reunirse con el cliente.
Hay situaciones en las que resulta difcil encontrar representantes del cliente que conozcan
a fondo el problema, o que por tratarse de un sistema o negocio nuevo, nadie en el
entorno del cliente tenga claras todas las funcionalidades que se necesitan.
Requisitos crecientes y cambiantes
Independientemente del punto del ciclo de vida en que nos encontremos, el sistema cambiar y
la tendencia al cambio persistir a lo largo de todo el ciclo de vida
Software Configuration Management, Prentice-Hall, 1980.
Es normal que los requisitos evolucionen durante el desarrollo del sistema, pero los cambios
deben partir de una descripcin inicial correcta, y gestionarse convenientemente, midiendo su
impacto en la planificacin del proyecto, y consensundolo con todos los participantes.
La evolucin de los requisitos durante el desarrollo de los proyectos puede incrementar o
modificar funcionalidades ya implementadas, desbordando los costes y agendas planificados.
25


Requisitos crecientes y cambiantes
Partir de una especificacin de requisitos incompleta incrementar el nmero de modificaciones
que sufrir el proyecto durante el desarrollo. Si los desarrolladores han diseado un sistema que
no corresponde con las expectativas del cliente, la introduccin sistemtica (generalmente con
agendas apretadas, o sin modificar las agendas iniciales), generar parches de programacin,
con insercin de cdigo adicional que puede trastocar principios bsicos de diseo y degradar la
arquitectura del sistema obteniendo finalmente un producto con serias deficiencias tcnicas.
Requisitos ambiguos
La ambigedad es un defecto habitual de las descripciones de requisitos.
Si lectores diferentes obtienen interpretaciones diferentes, o si un lector puede interpretar los
requisitos de formas diferentes, stos son ambiguos.
La ambigedad crea expectativas diferentes entre las partes del proyecto, y hace que los
desarrolladores programen funcionalidades que no se ajustan a lo que los usuarios necesitan.
La consecuencia inevitable de este problema es la re-programacin
La reprogramacin puede consumir ms del 40% del coste total de un desarrollo y se ha
estimado que hasta un 85% de las revisiones pueden deberse a errores en los requisitos[1] .
Para evitarla hay que confirmar que se comparte la visin obtenida con la que tienen las
diferentes fuentes de requisitos, y que los distintos participantes obtienen la misma
interpretacin de la documentacin de requisitos.
[1] Calculating the Return of Investment from More Effective Requirement Management, Leffingwell, Dean. 1997.
26


Requisitos innecesarios
Es frecuente la tendencia de algunos desarrolladores a incluir funcionalidades que no figuran en
la especificacin de requisitos, con la suposicin de que los usuarios lo agradecern. Muchas
veces los usuarios no les encuentran utilidad y quedan finalmente programadas pero sin uso,
suponiendo un coste de desarrollo innecesario.
Las sugerencias y posibilidades aportadas por el equipo de desarrollo pueden descubrir mejoras
importantes para el cliente o los usuarios, pero no deben implementarse sin consultarlas y
validarlas previamente.
Desde el punto de vista del equipo de desarrollo la mejor perspectiva es respetar la sencillez y
funcionalidad, y no ir ms all de los requisitos, sin la aprobacin del cliente.
Tambin es frecuente que el cliente pida funcionalidades que a primera vista pueden parecer
necesarias, pero que en realidad no aaden funcionalidad al producto, y que sin embargo
suponen un esfuerzo importante de desarrollo. Identificar estas funcionalidades, y pensar dos
veces si realmente se necesitan puede ahorrar trabajo innecesario
27


Requisitos insuficientes (mnimos)
Muchas veces el cliente tiene tan slo el concepto general del producto que desea, y no
comprende por qu es tan importante detallar los requisitos.
La tentacin en estos casos es partir de una descripcin mnima, o incluso de una explicacin
verbal, e ir preguntando y revisando a los programadores conforme el desarrollo avanza.
Esta forma de trabajo puede resultar apropiada slo para la construccin de sistemas
experimentales o prototipos, pero en general suele terminar con la frustracin de los
desarrolladores y el desconcierto y desesperacin del cliente.
Este planteamiento tambin genera la situacin muy frecuente de contar a los desarrolladores la
idea general de un nuevo producto, para pedirles una estimacin del tiempo necesario para
desarrollarlo.
Normalmente la visin general, sin descender a los detalles que implica, genera previsiones
optimistas que terminarn desbordadas al descubrir durante el desarrollo las implicaciones que
pasan inadvertidas en la concepcin inicial.
Las estimaciones prematuras, basadas en informacin limitada pueden fcilmente desbordarse
en ms del doble. Siempre que sea preciso ofrecer valoraciones previas es conveniente ofrecer
varias posibilidades (mejor caso, caso probable, peor caso), o incluir un porcentaje posible de
error probable.
28


Omisin de las necesidades de algunos grupos de usuarios
Entre los usuarios de un sistema es frecuente que se incluyan grupos de personas con
necesidades diferentes, que empleen funcionalidades distintas, e incluso que presenten diversos
perfiles de experiencia y conocimientos.
Al identificar las posibles fuentes de requisitos hay que localizar todos los posibles usuarios y
obtener informacin de sus caractersticas, necesidades y expectativas
29

Beneficios
E2
de los buenos requisitos.
Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que debe realizarse.
Unos requisitos bien elaborados y validados con el cliente evitan descubrir al terminar el
proyecto que el sistema no era lo que se peda.
Acuerdo entre desarrolladores, clientes y usuarios sobre los criterios que se emplearn para su
validacin.
Resulta muy difcil demostrar al cliente que el producto desarrollado hace lo que el pidi si su
peticin no est documentada y validada por l.
Base objetiva para la estimacin de recursos (coste, personal en nmero y competencias, equipos
y tiempo)
Si los requisitos no comprenden necesidades reales, las estimaciones no dejan de ser meras
apuestas. Las estimaciones en el fondo son clculos de probabilidad que siempre implican un
margen de error; por esta razn disponer de la mayor informacin posible reduce el error.
Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.)

Ms all de funcionalidades precisas, los requisitos recogen atributos de calidad necesarios
que en ocasiones son desconocidos por los desarrolladores, produciendo finalmente sistemas
sobredimensionados o con serias deficiencias de rendimiento.
Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y

malentendidos.
Tener un conocimiento preciso de lo que hay que hacer evita la prueba y error, repeticin de
partes ya desarrolladas, etc.
30

Ingeniera de requisitos
Conceptos clave.
Requisitos
del software
Requisitos
del sistema
Procesos de
ingeniera de
requisitos
Especificacin
Obtencin
Anlisis
Gestin
Validacin y
verificacin
31

Procesos
Obtencin
Anlisis
mbitos
Especif.
V&V
Gestin
Sistema
Software
La ingeniera del software y la ingeniera de requisitos son ingenieras muy recientes.

En la actualidad acaba de cerrarse la versin 1.0 de SWEBOK, que constituye el esfuerzo ms serio
y consensuado hasta la fecha para definir las reas de conocimiento que la integran.
En este estado de cosas no es extrao encontrar que, diferentes autores clasifican o presentan los
conceptos clave de forma diferente, si bien los conceptos bsicos siempre son los mismos:
Obtencin, anlisis, especificacin, validacin y verificacin y gestin.
As por ejemplo, Karl Wiegers centra su inters clasificatorio en la diferencia entre el desarrollo de lo
requisitos y su posterior gestin.
SWEBOK plantea una representacin esquemtica plana (no distingue entre gestin y desarrollo) y
centra su inters slo en los requisitos del software.
IEEE carga el peso de la clasificacin en la diferencia entre requisitos del sistema y del software.
Nuestro punto de vista contempla las 5 reas clave, que se trabajan tanto en el mbito de los
requisitos del sistema como en los requisitos del software.
32

Obtener informacin
Obtener informacin
Clasificarla, localizar
inconsistencias, dar
prioridades, pasar a
requisitos
OBTENCIN
ANLISIS
Registro y contrastacin
Controlar las
modificaciones
Escribir los
requisitos
Comprobar que son

formalmente
correctos y lo que el
cliente quiere
Registrar cambios,
estudiar su impacto,
actualizar
documentacin
ESPECIFICACIN
VERIFICACIN
&
VALIDACIN
GESTIN
Obtencin (elicitation)
El primer paso consiste en conocer y comprender las necesidades y problemas del cliente.
En la obtencin se identifican todas las fuentes de requisitos implicadas en el sistema y, en funcin
de las caractersticas del entorno y del proyecto se emplean las tcnicas ms apropiadas para la
identificacin de las necesidades que deben satisfacerse.
Anlisis
Una vez obtenida la informacin necesaria del entorno, es necesario sintetizarla, darle prioridades,
analizar posibles contradicciones o conflictos, descomponer el sistema y distribuir las necesidades
de cada parte, delimitar los lmites del sistema y definir su interaccin con el entorno.
33

Especificacin
Cuando ya se conoce el entorno del cliente y sus necesidades, es necesario plasmarlas en forma de
requisitos en los documentos que sirven de base de entendimiento y acuerdo entre cliente y
desarrollador, y que establecern tanto la gua desarrollo como los criterios de validacin del
producto final.
Documentar los requisitos es la condicin ms importante para gestionarlos correctamente.
Verificacin y validacin
Los requisitos deben ser formal y tcnicamente correctos (verificacin), y satisfacer las necesidades
del sistema, sin omitir ninguna ni incluir funcionalidades innecesarias (validacin).
El significado de estos dos trminos genera confusiones habitualmente. El criterio bsico que los
diferencia es que verificacin se refiere a la calidad formal, en este caso de los documentos de
requisitos (no son ambiguos, no son incompletos, son posibles, verificables, etc.) y validacin
comprende la adecuacin en el entorno de produccin, en el caso de la documentacin de
requisitos, la conformidad por parte del cliente de que reflejan lo que l quiere.
Gestin
Los requisitos cambiarn durante el desarrollo del sistema, y es necesario poder trazar en cada
cambio todas las partes afectadas, as como poder medir el impacto que cada modificacin implica
en la planificacin del proyecto.
34

mbitos de los requisitos
Sistema
Descripcin del sistema

ConOps
Software

SRS
mbitos
Descripcin
del sistema
Documento, tambin denominado ConOps y normalizado en el estndar IEEE Std. 1362-1998.

Definicin:
Documento dirigido a los usuarios, que describe las caractersticas de un sistema propuesto,
desde el punto de vista del usuario. La Descripcin del Sistema es el medio de comunicacin que
recoge la visin general, cualitativa y cuantitativa de las caractersticas del sistema; compartido
por la parte cliente y desarrolladora.
35

Propsito
de la descripcin del sistema
El desarrollo de la Descripcin del Sistema proporciona una actividad de anlisis y un documento

que tiene la funcin de enlace entre las necesidades del usuario, y las especificaciones tcnicas
del desarrollo.
La Descripcin del sistema proporciona:
La descripcin de las necesidades operacionales del usuario sin entrar en detalles

tcnicos.
La documentacin de las caractersticas del sistema y las necesidades operacionales del

usuario, de forma que puedan ser verificadas sin requerir conocimientos tcnicos.
El documento que recoge los deseos del usuario, sin requerir una cuantificacin medible.
Por ejemplo, el usuario puede indicar que desea que los tiempos de respuesta de las
consultas sean rpidos, y las razones de su deseo, sin necesidad de cuantificar esos
trminos. Ms adelante, el desarrollo y anlisis de los requisitos del sistema, el analista
concretar y cuantificar esos deseos.
El documento en el que, comprador y suministrador, reflejan las posibles estrategias de

solucin, y las restricciones que deben respetarse.
36

Propsito
del estndar IEEE 1362
Ofrece un formato y contenidos para la confeccin de las descripciones de sistema en los

desarrollos y modificaciones de sistemas intensivos de software.
El estndar no especifica tcnicas exactas, sino que proporciona las lneas generales que deben
respetarse. No es por tanto un modelo final, sino una gua de referencia sobre la que cada
organizacin debe desarrollar sus propias prcticas y procedimientos para preparar y actualizar
su documentacin con las descripciones de los sistemas.
Las partes esenciales de un ConOps son:
Punto 3: descripcin del sistema existente.
Punto 4: justificacin del desarrollo o de la modificacin,
Punto 5: Descripcin del sistema propuesto.
Los proyectos de tamao pequeo requieren descripciones de sistema menos formales, pero no
por su reducido tamao debe ignorarse.
Si el proyecto de software forma parte de un proyecto mayor, la descripcin del sistema de
software puede ser un documento separado, o ir incluido en la descripcin del sistema completo.
El estndar puede aplicarse a todos los tipos de sistemas de software: slo software, intensivos
de software o software/ hardware/personas. Aunque los conceptos del estndar tambin podran
aplicarse a sistemas de hardware, esta no es su finalidad.
El estndar identifica los elementos que al menos debe incluir una Descripcin del sistema. El
usuario puede incorporar otros elementos, agregando clusulas y sub-clusulas.
37

38

SISTEMA
EVOLUCIN
PREVISTA
39

Especificacin de requisitos del software (SRS)
Un documento SRS es la especificacin de las funciones que realiza un determinado producto de
software, programa o conjunto de programas en un determinado entorno.
El documento de especificacin de requisitos puede desarrollarlo personal representativo de la
parte suministradora, o de la parte cliente; si bien es aconsejable la intervencin de ambas partes.
Los aspectos bsicos que una descripcin de requisitos debe cubrir son:
Funcionalidad. Descripcin de lo que el software debe hacer.
Rendimiento. Indicacin de la velocidad, disponibilidad, tiempos de respuesta, tiempos de

recuperacin, tiempos de determinadas funciones.
Atributos. Consideraciones de portabilidad, correccin, mantenibilidad, seguridad, etc.
Interfaces externos. Cmo debe interactuar el software con las personas, el sistema de
hardware, o con otros sistemas (software y hardware).
Restricciones de diseo en la implementacin. Indicacin de las restricciones que

puedan afectar por la necesidad de sometimiento a estndares, lenguajes, polticas de
integridad de bases de datos, lmites de recursos disponibles para el desarrollo, sistema
operativo, etc.
Las especificaciones de requisitos de software deben evitar incluir requisitos de diseo o de

proyecto.
40

No deben incluir restricciones
de diseo gratuitas
Deben especificar el
QU, no el CMO
Una descripcin de requisitos del sistema limita las alternativas de diseo posibles, pero esto no
significa que deba decidir cul debe ser la solucin de diseo del sistema.
La especificacin de requisitos de software determina qu funcionalidades deben realizarse, qu
datos deben generarse en cada resultado, en qu lugar y quin los debe producir. La SRS debe
centrarse en los servicios que se realizarn, pero, en general, no debe especificar elementos de
diseo como los siguientes:
Divisin del software en mdulos.

Distribucin de funciones en los mdulos.
Descripcin del flujo de informacin entre los mdulos.
Eleccin de las estructuras de datos.
Deben centrarse nicamente en el punto de vista externo

del sistema, y no en el funcionamiento interno
41

Restricciones
de diseo necesarias
En algunos casos especiales, los requisitos pueden restringir el diseo de forma severa. Por
ejemplo, algunos requisitos de seguridad pueden implicar consideraciones de diseo como:
Mantener ciertas funciones en mdulos separados.

Permitir o limitar la comunicacin entre determinadas reas del programa.
Comprobar la integridad de los datos en variables crticas.
Algunos ejemplos de restricciones de diseo vlidas los constituyen los requisitos fsicos, los de
rendimiento y el cumplimiento de estndares en el desarrollo y procesos de garanta de calidad.
Exclusin de parmetros
y datos de planificacin del proyecto
La especificacin de requisitos de software se centra en el producto, no en el proceso de produccin

del producto.
Los requisitos de proyecto representan los trminos contractuales entre el cliente y el suministrador, y
no deben incluirse en la SRS. Normalmente incluyen informacin relativa a los procesos de adquisicin
o de suministro:
E3
Coste.
Agenda de entregas.
Procedimientos de seguimiento.
Mtodos de desarrollo del software.
Control de calidad.
Criterios de validacin y verificacin.
Procedimientos de aceptacin
42

Descripcin del sistema SRS: Diferencias
Pertenecen a procesos
primarios diferentes
DESCRIPCIN
DEL SISTEMA
SRS
5.1 Adquisicin
5.1 Adquisicin
5.2 Suministro
5.2 Suministro
5.4
Operacin
5.4
Operacin
5.3
Desarrollo
5.3
Desarrollo
5.5
Mantenimiento
5.5
Mantenimiento
Procesos primarios del ciclo de vida del software (ISO 12207)
43

Descripcin del sistema SRS: Diferencias
Pertenecen a entornos diferentes

ENTORNO DEL PROBLEMA
ENTORNO DE LA SOLUCIN
DESCRIPCIN DEL SISTEMA
SRS
E4
44

Conceptos clave
Independientemente de las tcnicas o procesos que se apliquen para realizar las diferentes tareas
relacionadas con el rea de requisitos, son cinco los objetivos que hay que cubrir:
ANALIZAR EL PROBLEMA
DEFINIR EL SISTEMA
DESARROLLAR LOS REQUISITOS DEL SOFTWARE
GESTIONAR LOS REQUISITOS
COMPRENDER LAS NECESIDADES DE LOS USUARIOS
Analizar el
problema
Comprender las
necesidades de
los usuarios
Definir el sistema
Desarrollar los
requisitos del
software
Gestionar los
requisitos
45

Conceptos clave
Analizar el problema
Consiste en comprender los problemas reales de los usuarios, y proponer soluciones que cubran
sus necesidades.
El objetivo del anlisis es conseguir la mayor comprensin posible antes de que empiece el
desarrollo.
El analista de requisitos es en realidad un solucionador de problemas.
Durante el anlisis debe comprender las necesidades de los usuarios, y proponer soluciones. En
esta tarea es necesario explorar y comprender el entorno del cliente.
Al realizar el anlisis hay que
Evitar la tendencia frecuente a los prejuicios creyendo que ya conocemos las necesidades del
cliente, y que su principal problema en realidad es que no entiende cul es su problema.
Tener en cuenta que siempre hay varias maneras de abordar un problema, y que en ocasiones,
cambiar la perspectiva del usuario puede generar la solucin ms eficiente y rentable, aunque no
siempre es posible.
Comenzar el anlisis sin ideas preconcebidas y teniendo presente el objetivo: conseguir la mayor
comprensin posible del problema.
El anlisis del problema comprende
1.2.3.4.-
Identificacin del problema.

Identificacin de las partes implicadas.
Delimitacin de la solucin.
Identificacin de las restricciones.
46

Conceptos clave
Comprender
las necesidades de los usuarios
La obtencin de los requisitos es sin duda la parte ms difcil del desarrollo de un sistema, y en la
actualidad es la principal causa de problemas.
En el apartado Obtencin de requisitos desarrolla de forma exclusiva este punto.
Definir el sistema
La descripcin del sistema marca el punto intermedio entre el anlisis del problema, y la
descripcin detallada de los requisitos del software. Es el documento que ofrece una visin general,
y ofrece la idea global del sistema en su conjunto. Marca una pausa antes de seguir avanzando
hacia los detalles, para evitar que los rboles nos impidan ver el bosque.
El resultado de esta fase es el documento de Definicin del sistema,
frecuentemente llamado tambin ConOps (Concept of Operations).
47

Conceptos clave
Definir el sistema
La descripcin del sistema el resultado del anlisis conceptual, y debe contener toda la informacin
necesaria para describir las necesidades de los usuarios, expectativas, entorno operativo, procesos
y caractersticas del sistema que se ha ideado para darles solucin.
Los elementos esenciales de la descripcin del sistema son:
Descripcin del sistema o de la situacin actual.

Descripcin de las necesidades que han motivado el desarrollo de un sistema nuevo, o de
la necesidad de modificar el actual.
Modos de operacin propuestos para el nuevo sistema.
Tipos de usuarios y caractersticas.
Funcionalidades propuestas.
Restricciones que debe respetar el sistema.
Por Definir el sistema no consideramos slo la redaccin del Con Ops por
el ingeniero de requisitos. Tambin comprende la verificacin y
validacin del documento.
Por verificacin se entiende la supervisin del documento para garantizar que
resulta formalmente correcto.
Validacin implica la conformidad de las partes afectadas por el sistema
(usuarios, clientes, etc.).
48

Conceptos clave
Desarrollar los requisitos
del software
Tras analizar los problemas y necesidades de los usuarios, conocer las limitaciones que tener en
cuenta, y haber sintetizado en la descripcin del sistema la visin global de la solucin que se
pretende construir, es el momento de profundizar en los detalles.
El nivel de precisin que se debe alcanzar en la descripcin de los requisitos del software (SRS),
depende de varios factores, incluyendo el contexto de la aplicacin, los conocimientos del equipo
de desarrollo, as como su experiencia en desarrollos similares.
Los requisitos del software tambin deben verificarse y validarse, para garantizar, por un lado, que
son formalmente correctos, y por otro que dan respuesta a las necesidades de todas las partes
implicadas.
49

Conceptos clave
Gestionar los requisitos

Una vez que se ha comprendido el problema del usuario, se ha definido y descrito el sistema que
se desea construir para solucionarlo, y detallado los requisitos del software, comienza la fase de
diseo y desarrollo.
Se puede considerar que la fase de requisitos ya ha terminado al generar los documentos de
descripcin del sistema y descripcin de requisitos del software. Pero lo cierto es que los ciclos de
desarrollo secuenciales, o de cascada pura son muy raros, y, aun el caso de que inicialmente se
haya planteado este ciclo, desde la gestin del proyecto se debe considerar la posibilidad de
incorporar modificaciones en los requisitos durante el periodo de desarrollo.
Cuanto ms complejo sea el sistema, y ms larga la agenda de desarrollo, habr mayor
probabilidad de modificaciones sobre los requisitos; y si no se gestionan convenientemente
deteriorarn, en mayor o menor medida, la planificacin y la calidad del proyecto.
Si bien es cierto que no es posible plantear escenarios de desarrollo ideales en los que, tras una
definicin inicial de los requisitos, stos se van a mantener inamovibles durante todo el desarrollo
del producto; tampoco es posible incorporar modificaciones sobre los requisitos que han servido de
base para la planificacin del proyecto, y el diseo de la solucin, sin que la incorporacin obligue a
medir las consecuencias que van a tener sobre el trabajo ya realizado, el pendiente de realizar, las
posibles reconsideraciones de diseo, y en consecuencia sobre los costes y agendas del proyecto.
Requisitos
Diseo
Codificacin
Integracin/
pruebas
La gestin de requisitos da continuidad a esta rea durante todo el proyecto

50

Conceptos clave

El hecho de tener que gestionar los requisitos durante todo el ciclo de vida del sistema no quiere
decir que cualquier momento del desarrollo sea un buen momento para seguir descubriendo cules
son las necesidades de los clientes. La incorporacin de nuevos requisitos, o la modificacin de los
iniciales resulta mucho ms costosa conforme van avanzando las fases del proyecto. Por esta
razn, los ciclos secuenciales o de cascada con escasas iteraciones de retroceso son los ms
eficientes en el consumo de recursos.
Las razones que normalmente no permiten llegar a un conocimiento detallado del problema en la
fase inicial de los requisitos suelen ser:
Sistemas complejos.
Sistemas para dar soporte a procesos de negocio poco maduros.
Desarrollos evolutivos impuestos por la necesidad de implantaciones parciales tempranas
para los usuarios.
Avance del desarrollo del proyecto
Coste de la introduccin de modificaciones de requisitos

51

Conceptos clave

Al analizar el problema del cliente, y desarrollar los documentos de requisitos no hay que
escamotear esfuerzos para profundizar en las funcionalidades del sistema, y caer en la tentacin
de dejar pendientes de concrecin, o insuficientemente analizadas partes del problema para ms
adelante.
La gestin de los requisitos implica que cada modificacin de requisitos:
Debe provenir de una fuente autorizada.
Debe incorporarse formalmente a la documentacin de requisitos
Debe alcanzar el consenso de las partes implicadas.

Obliga a un anlisis del impacto.
Implica una revisin de la planificacin del proyecto.
Debe informarse al cliente de los efectos sobre la planificacin y recursos necesarios, para
obtener su aprobacin.
E5
52

Obtencin de los requisitos
Sndromes
en la obtencin de los requisitos
Cuatro son los principales desafos para el analista de requisitos:
S pero no exactamente as.

Vaya!, pues esto no debera ser as.
Ya est todo?
Usuarios contra desarrolladores
53

Vaya!, pues esto no debera
ser as.
Este es un problema inherente al desarrollo de software.

Los usuarios no ven el sistema hasta que lo empiezan a usar, y es normal
que sea entonces cuando descubran que algunas partes no se adecuan
exactamente a sus expectativas.
El software no es fsico ni tangible. Al cliente de una vivienda se le puede
mostrar una maqueta o un plano. Un proyecto de mobiliario se puede
dibujar, pero nuestro producto no es fsico, es difcil de representar, de
conceptualizar de forma concreta y objetiva.
Si el analista de requisitos no comprende bien lo que el cliente necesita,
ste se dar cuenta de la disparidad de criterios cuando ya sea tarde,
cuando el sistema est en sus manos; de forma que habremos producido
algo que no cumple sus expectativas.
Por esta razn, inherente a la intangibilidad del software, la obtencin de
requisitos es la fase ms importante de un desarrollo.
El ingeniero de requisitos debe tener en cuenta que este sndrome es un riesgo consustancial con su trabajo, y que su
misin es anticipase para que al final del desarrollo produzca el menor efecto posible.
Los medios para reducir su efecto son:
Evitar quedarse con las primeras descripciones genricas.

No dar nada por supuesto.
Evitar las ambigedades.
Conocer el entorno y las necesidades del cliente.
Dedicar esfuerzo y tiempo para la obtencin de requisitos, adecuado al tamao y complejidad del sistema.
54


Este sndrome es similar al anterior, porque tiene el mismo resultado:
el descubrimiento tardo por parte del cliente de que determinadas
partes del sistema no solucionan adecuadamente su problema, pero a
diferencia del anterior, su origen no est en omisiones o
ambigedades en el proceso de obtencin, sino en la inmadurez de los
procesos a los que el nuevo sistema debe dar soporte, o en el
desconocimiento o actitud por parte de los interlocutores del cliente.
Aunque tenga el mismo efecto que el sndrome anterior, identificar
que tienen causas diferentes interesa en la medida en que requieren
soluciones, o formas de trabajo distintas.
El ingeniero de requisitos debe identificar mayores probabilidades de
riesgo si en el contexto adquieren relevancia las siguientes
situaciones:
El sistema no sustituye o modifica a otro
existente, sino que se desarrolla para dar soporte a procesos de negocio

novedosos para la organizacin que lo solicita.
Los interlocutores nombrados por el cliente no son conocedores expertos de los procesos cubiertos por el sistema.
Faltan representantes de partes implicadas por procesos importantes del nuevo sistema.
Escasa implicacin del cliente, que por falta de recursos, tiempo o incluso por pereza intelectual no se sienta con el
ingeniero de requisitos a desmenuzar las particularidades de sus procesos, dando por vlidos los requisitos finalmente
obtenidos, sin prcticamente mirarlos.
55


Estas situaciones aumentan las probabilidades de terminar un sistema
perfectamente validable sobre una descripcin de requisitos correcta y
completa, sin ambigedades, pero en el que al final el cliente
descubrir que en, menor o mayor medida, no le soluciona el
problema como hubiera sido deseable.
Por supuesto en esta situacin, como desarrolladores podremos
argumentar que tenemos la razn de nuestra parte, puesto que
habremos construido lo que el cliente nos pidi, y el problema estriba
en que l no saba bien lo que quera, o se ha dado cuenta de lo que
en realidad necesita, cuando ha empezado a trabajar con el nuevo
sistema que hemos desarrollado.
De cualquier forma no es una situacin ni cmoda ni deseable.
Nuestro cliente como experto en su negocio tiene su ego,
y difcilmente reconocer que no saba o no quiso explicarnos lo que debamos construir. Si afortunadamente
disponemos de un documento de requisitos formalmente correcto, validado con su firma, tendremos un salvoconducto
para hacer efectiva nuestra factura, o defendernos de acciones legales, pero en ningn caso habremos cubierto nuestro
objetivo: desarrollar soluciones para los clientes, y habremos creado un sistema que no sirve y un cliente cabreado y
descontento.
Este sndrome tambin es inherente al desarrollo de sistemas de software, y con l resulta fcil deducir las funciones y
competencias que debe cubrir el ingeniero de requisitos, as como de ser persona con ojo clnico y registro amplio de
recursos.
Si se enfrenta a procesos poco maduros deber involucrarse en mayor medida en el entorno organizacional del cliente y
aportar en su trabajo parte ms propia de consultora que de analista de requisitos.
56


Deber tambin aportar asesora profesional al cliente informndole
del riesgo alto que encierra el proyecto de producir versiones que se
demostrarn inadecuadas para la realidad de sus procesos, y de la
conveniencia de profundizar el mximo posible en el conocimiento de
los procesos antes de elaborar los requisitos, as como de emplear
tcnicas de prototipado en la obtencin de requisitos, y ciclos de
desarrollo en cascada. Resultan ms aconsejables desarrollos
incrementales o evolutivos, con ciclos en espiral y seguimiento por
parte del cliente.
Si el analista se encuentra con problemas de comunicacin o de
actitud por parte del cliente deber conducir la situacin y adaptar su
registro de actuacin de forma que sin perder la asertividad, logre
establecer una implicacin adecuada del cliente y un flujo de
comunicacin productivo.
57

Ya est todo?
Cundo se puede dar por terminado un trabajo?
Cuando ya no queda ms por hacer.
Cmo sabe el ingeniero de requisitos que ha descubierto
todos los requisitos necesarios?.
Esta incertidumbre es tambin inherente al trabajo del
ingeniero de requisitos, porque nunca tendr la certeza de
haber descubierto todas las necesidades y restricciones, y
sobre todo porque siempre puede dar por descontado que
algo se queda sin descubrir.
La nica forma de afrontar esta circunstancia es dedicar tiempo suficiente a la obtencin y anlisis,
e identificar a todos los participantes o partes implicadas en el proyecto.
Aunque nunca podr afirmar haber localizado todos los requisitos, el objetivo en este caso es
alcanzar el convencimiento de haber descubierto lo suficiente, y que las posibles omisiones
pertenecern a cuestiones menores, que pueden surgir durante la gestin de los requisitos, o a lo
largo del mantenimiento del futuro sistema.
58


No es posible saber qu necesita el cliente, si no disponemos de
comunicacin fluida con los interlocutores de su organizacin; y por
desgracia es demasiado frecuente que los desarrolladores y los
usuarios, se relacionen sobre la base de la desconfianza mutua, y
empleen idiomas distintos.
Tanto la actitud de los desarrolladores como la de los usuarios no
suele ser favorable para trabajar unos con otros. Los primeros
prefieren concentrar su trabajo en el entorno tcnico, y olvidarse de
hablar con los clientes.
Los usuarios, por su parte, esperan su nuevo programa, con la misma
actitud que podran esperar un coche tras haberlo encargado en el
concesionario.
Los analistas y los usuarios pertenecen a dos comunidades que
desconfan mutuamente.
Los usuarios ven a los desarrolladores como personas incapaces de conseguir sistemas que funcionen correctamente
sin la necesidad de estar constantemente parchendolos.
Los desarrolladores se ven solos y desamparados como nicos responsables de todo cuando ocurra o tenga relacin con
el sistema.
Por supuesto, nosotros no esperamos que los usuarios cambien, pero tenemos que conocer estos problemas, y el
ingeniero de requisitos debe estar preparado para encontrarse con estas dificultades y minimizar sus consecuencias.
Se supone que durante la obtencin de los requisitos, tanto los usuarios como los desarrolladores comparten el mismo
objetivo: definir cmo ha de ser el nuevo sistema, pero lo cierto es que cada uno tiene objetivos diferentes.
Por nuestra parte estamos interesados en desarrollar una buena descripcin de requisitos, completa y correcta.
Queremos especificar un sistema tcnicamente viable, que integre la funcionalidad necesaria de forma eficiente sobre
un diseo limpio y robusto.
59


Por su parte los usuarios (cuando se implican) centran su inters en
definir el sistema con que esperan trabajar, sin querer saber nada de
agendas, viabilidad, prioridades, etc.
Para abordar con las mayores garantas de xito este problema, por
nuestra parte:
Debemos sumergirnos en la organizacin del cliente; estudiar, analizar
y comprender los procesos y problemas a los que tiene que dar
cobertura el nuevo sistema.
En las comunicaciones de requisitos, as como en la descripcin del
sistema, tenemos que emplear un lenguaje natural, sin tecnicismos; y
adoptar la terminologa habitual del entorno del cliente.
Mantener un enfoque y unidad de criterio comn por todas las
personas de nuestra organizacin, de cara al cliente.
Por parte del cliente:
Debe facilitar interlocutores conocedores de los procesos y problemas que debemos conocer, con tiempo y motivacin
suficiente para trabajar con nosotros.
Los interlocutores deben ser concretos y especficos en sus descripciones, revisar y validar los documentos de requisitos
generados.
60

Problemas
frecuentes en la obtencin de requisitos
Los problemas ms frecuentes pertenecen a 3 categoras:
Delimitacin confusa del mbito del sistema.

Comprensin
Inestabilidad
Problema: delimitacin confusa del mbito del sistema

Antes de entrar en la obtencin de requisitos con detalle es necesario conocer cules son los
objetivos y los lmites del sistema.
Si no controlamos los lmites y objetivos esperados del sistema, el sistema nos
controlar a nosotros
Los contextos que es necesario conocer para centrar apropiadamente el sistema en su entorno
son:
Organizacin
Entorno
Proyecto
61

Problema: delimitacin confusa del mbito del sistema
Para evitarlo deben analizarse y conocerse los tres mbitos sealados
ORGANIZACIN
Para llevar a cabo la obtencin de requisitos es preciso conocer y comprender la organizacin
en la que trabajar el sistema, y los objetivos que se pretenden conseguir.
ENTORNO
Los factores del entorno del sistema influyen de forma determinante en el proceso de
obtencin de requisitos. Los ms importantes son:
Restricciones: de hardware, sobre el software o sobre los procesos de desarrollo.
Madurez de los procesos del entorno de operacin.
Grado de certidumbre de los interfaces con otros sistemas.
PROYECTO
El contexto en el que se desarrolla el proyecto tambin afecta a los procesos de obtencin de
requisitos, que deber adecuar los mtodos y tcnicas de obtencin a las caractersticas del
proyecto:
Caractersticas especficas de cada grupo de agentes implicados en el proyecto
(usuarios, cliente, desarrolladores, normativas, etc.)
Restricciones impuestas por las partes implicadas en la obtencin de los requisitos
(agenda, coste, parmetros de calidad deseados, etc.)
62

Problema: comprensin
El 56% de los errores deslizados en los sistemas desarrollados se deben a deficiencias en la
comunicacin usuario analista durante la obtencin de los requisitos, y este tipo de errores son
los ms caros de corregir porque llegan a consumir hasta el 82% del tiempo de desarrollo[1].
Los problemas de comprensin producen requisitos incompletos, con ambigedades,
inconsistentes; y en definitiva incorrectos, porque no definen las necesidades reales de los
usuarios.
Estos problemas se pueden agrupar en tres categoras:
Dar por supuesto lo desconocido.

Lenguaje.
Informacin desestructurada.
Problema: inestabilidad
Los requisitos son inestables y cambian durante el desarrollo y tras la entrada en servicio del
sistema.
La solucin para evitar problemas radica en el proceso de gestin de requisitos.
[1] Goodrich, Victoria, and Olfman, Lorne. An experimental Evaluacion of Task annd Methodology Variables for Requirements
Definition Phase Success. In Bruce D. Shriver (editor), Proceedings of the twenty-third Annnual Hawaii International Conference on
System Sciences, p. 201-209. IEEE Computer Society, January 1990
63

Tcnicas de obtencin de requisitos

ENTREVISTAS
Reuniones JAD, cuestionarios

reuniones de grupo
entrevista, lluvia de ideas
ESCENARIOS
Casos de uso, tarjetas CRC

diagramas de flujo, escenarios
PROTOTIPOS
Prototipos rpidos
prototipos evolutivos
TCNICAS
OBSERVACIN
Introspeccin
anlisis de protocolo
documentacin, otros sistemas
E6
64

Clasificacin de los requisitos
REQUISITO
FUNCIONALES
RESTRICCIN
REQUISITO
TIPOS DE REQUISITOS
NO FUNCIONALES
RESTRICCIN
REQUISITO
DE INTERFAZ
RESTRICCIN
Requisitos funcionales
Definen el comportamiento del sistema.
Describen las tareas que el sistema debe realizar.
Al definir un requisito funcional es importante mantener el equilibrio entre la excesiva generalidad,
insuficiencia de detalle o ambigedad, y el exceso de detalle con precisiones o descripciones
innecesarias o redundantes.
65

Requisitos no funcionales
Definen aspectos, que sin ser funcionalidades, (tareas que el sistema debe realizar) resultan
deseables desde el punto de vista del usuario. Generalmente comprenden atributos de calidad:
Tiempos de respuesta.
Caractersticas de usabilidad.
Facilidad de mantenimiento.
etc.
Requisitos de interfaz
Definen las interacciones del sistema con su entorno:
Usuarios
Otros sistemas
66

Restricciones
Los requisitos, en su definicin purista definen el QU, y no el CMO; pero en el conjunto de
necesidades que debe cubrir un sistema, no slo hay que tener en cuenta QU cosas hay que
hacer, sino tambin en ocasiones CMO deben hacerse.
La clasificacin entre requisitos puros (QU) y restricciones (CMO) la debe considerar el analista
para que el equipo de trabajo sepa hasta qu punto determinados aspectos limitan sus opciones de
trabajo, y poder mantener as la trazabilidad con su origen (necesidad apuntada por el usuario,
normativa legal, limitacin tcnica, etc.)
Con carcter general las restricciones imponen limitaciones:
En la libertad de los analistas al realizar el diseo del sistema.

En los procesos o formas de trabajar que se emplearn en el desarrollo del sistema.
El analista del sistema elige entre todas las opciones tecnolgicamente posibles aquellas que segn
su criterio profesional y las circunstancias del sistema, aportan mejor solucin para la
implementacin de los requisitos funcionales y no funcionales.
La indicacin por parte del cliente de instrucciones como:
Debe emplearse base de datos Oracle.
Los procesos de desarrollo deben ser conformes a Mtrica 3.
El sistema final debe ejecutarse sobre la plataforma libre Linux.
Debe desarrollarse empleando Java.
El interfaz de comunicacin con un programa externo de contabilidad debe hacerse de la siguiente
forma...
67

Problemas
de clasificacin y nivel de rigor necesario
Para nosotros la base terica de clasificacin es un marco de referencia con la definicin de los
criterios de clasificacin.
En la relacin de requisitos de un sistema, no resulta interesante entrar en anlisis puristas para
determinar si cada requisito lo es de interfaz, funcional, etc.
La diferencia entre:
El sistema comprueba la autentificacin y autorizacin del usuario y le da acceso a una
pantalla con el men general o en caso de error le redirige a la pantalla de usuario y
contrasea otra vez
Y:
RS. 3 El sistema slo permite el acceso al men principal a usuarios autorizados.
RT.3.1 El sistema identifica al usuario solicitando a travs de la pantalla de operacin
su nombre y contrasea de acceso.
En el segundo caso, el equipo de trabajo sabe que debe descartar opciones de identificacin a
travs de tarjetas, o dispositivos biomtricos, o cualquier otra opcin posible.
Se trata por tanto de conocer y comprender el concepto de restriccin, para aplicarlas
slo cuando son necesarias, dejando as el mayor margen posible de libertad para el
diseo de la solucin de software.
68

Calidad de la documentacin
Caractersticas
de las buenas descripciones de requisitos

Especificacin
Requisitos
Posibles
Completa
Necesarios
Correcta
Priorizados
Consistente
Concretos
Modificable
Verificables
Trazable
69

Propiedades de los buenos requisitos
Posibles
Cada requisito debe poder implementarse dentro de las capacidades y limitaciones conocidas
del sistema y su entorno. El director tcnico deber comprobar la viabilidad de los requisitos
antes de comprobar el documento.
Necesarios
Un requisito es necesario si es algo:
que el cliente realmente necesita

requerido para la conformidad con un requisito
requerido para la conformidad con un interfaz,
Alto
externo o estndar.
Para evitar requisitos innecesarios,

el cliente debe valorar cada
funcionalidad y como afectar
al sistema si esta o no.
Coste
Valor
Alto
70

Requisitos priorizados
Los requisitos de una SRS deben incluir una indicacin de la importancia del requisito en el
conjunto del sistema.
Normalmente todos los requisitos de un producto de software no son igual de importantes.
Algunos resultan esenciales, y otros son deseables.
Cada requisito debe identificar estas diferencias de forma clara, de esta forma ayuda a:
Los clientes tengan una consideracin ms adecuada de cada requisito, y a menudo

clarifica asunciones que pudieran estar ocultas.
Que los desarrolladores tomen decisiones de diseo correctas y dediquen niveles de

esfuerzo apropiado a las diferentes partes del producto.
Que el gestor del proyecto pueda establecer prioridades de ejecucin, y disponga de

informacin adicional en caso de problemas de agenda.
71

Concretos
Punto ptimo: Mayor grado de comprensin con la

menor ambigedad
Comprensin
Un requisito es concreto si tiene una nica interpretacin. Como mnimo esto requiere que cada
caracterstica del producto final se describa empleando un trmino nico. En los casos en los
que el trmino puede tener diferentes significados segn el contexto, ste debe incluirse en el
glosario de la SRS con el significado con el que se emplea.
Punto
ptimo
Ambigedad
Modos eficaces de evitar la ambigedad:
Inspecciones formales de los documentos de requisitos.

Escritura de casos de prueba
Elaboracin de casos de uso.
Elaboracin de diagramas.
72

Verificable
Un requisito es verificable si, y slo si a travs de un proceso concreto y finito es posible
comprobar si el software lo cumple. En general los requisitos ambiguos no son verificables.
Los requisitos no verificables incluyen sentencias como que trabaje eficientemente,interfaz de
usuario amigable, debe responder rpidamente. Estos requisitos no son verificables porque no
es posible definir los trminos eficiente, amigable, rpido. La sentencia el programa no
debe entrar nunca en un bucle infinito tampoco es verificable porque un nivel de pruebas
absoluto es tericamente imposible.
Un ejemplo de requisito verificable es:
El tiempo de respuesta para la compra de un billete sencillo no debe superar los 2 segundos el
90% de las veces, y una transaccin de compra de un billete sencillo nunca debe tardar ms de
5 segundos.
Esta sentencia es verificable porque emplea trminos concretos y magnitudes medibles y
comprobables.
Si no es posible establecer un mtodo para comprobar si el software cumple con un
determinado requisito, el requisito debe eliminarse o revisarse
73

Propiedades de la documentacin
Completa
Una SRS es completa si, y slo si incluye los elementos siguientes:
Todos los requisitos significativos, relativos a funcionalidad, rendimientos, restricciones

de diseo, atributos e interfaces externos.
Definicin de las respuestas del software a todas las posibles entradas de datos en toda
clase de situaciones. Es importante especificar las respuesta tanto para datos de
entrada vlidos, como invlidos.
Referencias a todas las imgenes, tablas y diagramas y definicin de todos los trminos
propios y unidades de medida no normalizadas.
No puede considerarse completa una SRS si en la descripcin de algunos requisitos se incluye la

frase A determinar o la expresin inglesa TBD (to be determined).
Si excepcionalmente se indica que un requisito se concretar ms adelante es necesario indicar
tambin:
Descripcin de las causas por las que no se ha concretado el requisito.
Descripcin de qu debe realizarse para poder eliminar el TBD, quin es la persona
responsable de llevarlo a cabo, y cundo debe eliminarse
74

Completos
Conocemos
No Conocemos
Entrevistas y revisiones
Entendemos
Este bloque pertenece a

los requisitos que
conocemos y sabemos
que son aplicables al
problema

los requisitos que
conocemos pero no
conocemos, es decir que
sabemos que existen pero
no hemos realizado su
anlisis.
Prototipado
Prototipado y
casos de uso
No Entendemos

los requisitos que
sabemos que son
aplicables al problema
pero que no entendemos

los requisitos que no
conocemos y tampoco
sabemos que no
conocemos
75

Correcta
Una especificacin de requisitos de software es correcta si, y solo si todos y cada uno de los
requisitos indicados son los que debe cubrir el software del sistema.
No hay ninguna herramienta que pueda garantizar la correccin. Una SRS debe compararse con
las especificaciones de rango superior del proyecto (Descripcin del sistema, documentacin
referenciada, etc.) para comprobar que cumple sus indicciones.
Tambin es recomendable que la parte cliente determine si la especificacin de requisitos de
software refleja sus necesidades actuales
Necesidades
del Usuario
A
B
B
Revisin y aprobacin
Requisitos
Correctos
C
Requisitos
Especificados
76

Consistente
El atributo de consistencia se refiere a consistencia interna no a conformidad o congruencia con
documentos superiores (ej. descripcin del sistema). La ausencia de esta congruencia supondra
un problema de correccin y no de consistencia.
Una documentacin es internamente consistente si, y solo si, no se establecen conflictos entre
requisitos individuales o grupos de requisitos. Los tres tipos de conflictos posibles son:
Conflictos
Objetos
Lgicos
C=A+B
C=A*B
Trminos
RF 10 Informe A
cierre de caja
RF 50 Informe A
cierre diario de operaciones
77

Modificable
Un documento de requisitos es modificable si, y slo si su estilo y estructura permiten que
puedan llevarse a cabo modificaciones en los requisitos manteniendo la estructura y el estilo, de
forma fcil, completa y consistente. La modificabilidad generalmente requiere en la
documentacin:
Que tenga una organizacin coherente y fcil, con una tabla de contenidos y un ndice..
Que no sea redundante. (p. ej. que el mismo requisito no aparezca en dos lugares del
documento)
Exprese cada requisito por separado, mejor que mezclados con otros requisitos.
La redundancia, por s misma no es un error, pero puede acarrearlos. En ocasiones la
redundancia puede hacer un SRS ms legible, pero puede generar errores al actualizar el
documento, y generar inconsistencias si slo se actualiza una de las apariciones, olvidando la
otra.
78

Trazable
Un SRS es trazable si establece de forma clara el origen de cada requisito, y facilita su
referencia en las futuras etapas del desarrollo, o en las actualizaciones de la documentacin. Se
recomiendan los dos tipos siguientes de trazabilidad:
Trazabilidad remota (hacia fases previas del desarrollo). Para ello se debe referenciar la fuente
del requisito.
Trazabilidad futura (hacia fases posteriores del desarrollo). Para ello cada requisito debe tener
un nombre o referencia nica.
La trazabilidad remota es importante cuando el producto de software entra en la fase de
operacin y mantenimiento. Al modificar el diseo y el cdigo es esencial poder determinar
todos los requisitos que quedan afectados por una modificacin
79

Conclusiones
OBJETIVO
Desarrollar software
Desarrollar una
solucin
Tomar requisitos
del usuario
Comprender el entorno
y necesidades del usuario
Realizar procesos
normalizados para el
desarrollo de requisitos
Descripcin de requisitos
correcta
80

Conclusiones
MEDIOS
Aplicar tcnicas
y procesos
FIN
Conseguir
el objetivo
81
Preguntas
Qu hemos aprendido?
Reflexionemos

IR02 Ingeniería de Requerimientos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

IR02 Ingeniería de Requerimientos

Enviado por

Direitos autorais:

Formatos disponíveis

Ingeniera de requerimientos

Ingeniera de Sistemas e Informtica

Propsito y contenido de la sesin

Introduccin Ingeniera del Software

Factores que imprimen aceleracin al ritmo de crecimiento del hardware:

Comunicaciones entre sistemas

Introduccin Ingeniera del Software

El proyecto se aborta o el sistema no se llega a utilizar

Introduccin Ingeniera del Software

En 1962 se public el primer algoritmo para bsquedas binarias.

El primero sobre anlisis de requisitos apareci en 1979

Introduccin Ingeniera del Software

(1) La aplicacin de mtodos sistemticos, disciplinados y cuantificables para el

Introduccin Ingeniera del Software

Identificacin de los factores clave que determinan la calidad del software.

El resultado ha sido la necesidad de profesionalizar el desarrollo, mantenimiento y

Introduccin Ingeniera del Software

Instituto de Ingeniera del software. (SEI http://www.sei.cmu.edu/).

Introduccin Ingeniera del Software

IEEE Computer Society

830 Prcticas recomendadas para las especificaciones de software.

Introduccin Ingeniera del Software

Definirse a s misma: Cules son las reas de conocimiento que la comprenden?

Definir los procesos que intervienen en el desarrollo, mantenimiento y operacin

Definir estndares menores para dibujar criterios unificadores en requisitos,

Introduccin Ingeniera del Software

Introduccin Ingeniera del Software

Requisitos del software

Requisitos del software

Para que un esfuerzo de desarrollo de software tenga xito, es esencial comprender

La parte ms difcil en la construccin de sistemas software es decidir

Requisitos del software

Qu porcentaje de proyectos concluyen con xito?

Los criterios para determinar el xito de un proyecto son:

Sin desviaciones en las fechas previstas.

Requisitos del software

Porqu fracasan los proyectos?

Requisitos incompletos: 13%

Expectativas no realistas: 10%

Requisitos del software

Fase en la que se soluciona el fallo

Requisitos del software

Sus defectos repercuten en todas las fases

Requisitos del software

Los defectos comunes en los requisitos y sus consecuencias.

Omisin de las necesidades

Requisitos del software

Los defectos comunes en los requisitos y sus consecuencias.

Requisitos del software

Los defectos comunes en los requisitos y sus consecuencias.

Requisitos del software

Los defectos comunes en los requisitos y sus consecuencias.

Requisitos del software

Los defectos comunes en los requisitos y sus consecuencias.

Requisitos del software

Los defectos comunes en los requisitos y sus consecuencias.

Requisitos del software

de los buenos requisitos.

Concrecin de los atributos de calidad (ergonoma, mantenibilidad, etc.)

Eficiencia en el consumo de recursos: reduccin de la re-codificacin, reduccin de omisiones y

Requisitos del software

Requisitos del software

La ingeniera del software y la ingeniera de requisitos son ingenieras muy recientes.

Requisitos del software