Está en la página 1de 31

Requisitos del software

Ingeniera de software-FISI
Marco Coral

Requisitos del software


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

Requisitos del software


Obtencin de los requisitos

Vaya!, pues esto no debera ser as.


Este es un problema inherente al desarrollo de software.
Los usuarios no ver 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.
3

Requisitos del software


Obtencin de los requisitos

S pero no exactamente as.


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.

Requisitos del software


Obtencin de los requisitos

S pero no exactamente as.


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.

Requisitos del software


Obtencin de los requisitos

S pero no exactamente as.


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.

Requisitos del software


Obtencin de los requisitos

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.

Requisitos del software


Obtencin de los requisitos

Usuarios contra desarrolladores


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.
8

Requisitos del software


Obtencin de los requisitos

Usuarios contra desarrolladores


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.

Requisitos del software


Obtencin de los requisitos

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
10

Requisitos del software


Obtencin de los requisitos
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.)

11

Requisitos del software


Obtencin de los requisitos
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

12

Requisitos del software


Obtencin de los requisitos

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

13

Requisitos del software


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.

14

Requisitos del software


Clasificacin de los requisitos

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

15

Requisitos del software


Clasificacin de los requisitos

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...
16

Requisitos del software


Clasificacin de los requisitos

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.
17

Requisitos del software


Calidad de la documentacin

Caractersticas de las buenas descripciones

de requisitos

Especificacin

Requisitos
Posibles

Completa

Necesarios

Correcta

Priorizados

Consistente

Concretos

Modificable

Verificables

Trazable

18

Requisitos del software


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

Alto
Valor
19

Requisitos del software


Propiedades de los buenos requisitos
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.

20

Requisitos del software


Propiedades de los buenos requisitos
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.
21

Requisitos del software


Propiedades de los buenos requisitos
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

22

Requisitos del software


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

23

Requisitos del software


Propiedades de la documentacin
Completos
Conocemos

No Conocemos
Entrevistas y revisiones

Entendemos

Este bloque pertenece a


los requisitos que
conocemos y sabemos
que son aplicables al
problema

Este bloque pertenece a


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

Este bloque pertenece a


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

Este bloque pertenece a


los requisitos que no
conocemos y tampoco
sabemos que no
conocemos

24

Requisitos del software


Propiedades de la documentacin
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
25

Requisitos del software


Propiedades de la documentacin
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

26

Requisitos del software


Propiedades de la documentacin
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.

27

Requisitos del software


Propiedades de la documentacin
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

28

Requisitos del software


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

29

Requisitos del software


Conclusiones

MEDIOS

Aplicar tcnicas
y procesos

FIN

Conseguir
el objetivo

30

Estndares en la etapa de requerimientos

La etapa de requerimientos esta conformada por:


Obtencin de Requerimientos
Anlisis de Requerimientos
Especificacin de Requerimientos y
Validacin de Requerimientos

Dentro de cada una de estas etapas el SWEBOK sugiere la utilizacin de los siguientes
estndares
Anlisis de Requerimientos
IEEE Std 1320.1 para modelado funcional, IEEE Std 1320.2 para modelado de informacin, IEEE
Std 1471-2000 para arquitectura.

Especificacin de Requerimientos
IEEE 1362 para la definicin del sistema, IEEE 830 para especificacin de requerimientos de
software, IEEE 1233 para requerimientos de sistemas.
Validacin de Requerimientos
IEEE 1028 para revisin de requerimientos

31