Marco terico

Se debe tener claro que se puede evitar errores durante el desarrollo del software, reduciendo
hasta en ms del 50% de errores que por cierto se dan debido a una pobre gestin y definicin
de requisitos.

Qu es un requisito?
Se encontraron y se exponen varias definiciones que se consideran apropiadas para definir este
concepto.
Un requisito es una condicin o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
Un requisito es una condicin o capacidad que debe estar presente en un sistema o
componente de sistemas para satisfacer un contrato, estndar, especificacin u otro documento
formal.
De acuerdo a las definiciones anteriores los requisitos se entienden como una especificacin de
lo que se denota o se establece como necesario e indispensable para determinar el
comportamiento eficiente de un software.

Caractersticas de los requisitos

Se debe recordar que el objetivo principal es que cada uno de los requisitos que se obtengan
sean los adecuados y necesarios para darle una visin clara de lo que es el producto final, pero
para que un requisito sea por si solo adecuado o tenga la mejor descripcin de lo que quiere el
cliente, debe satisfacer una serie de caractersticas las cuales se describen a continuacin:
a. Necesario. - Esta caracterstica quiere decir que represente en realidad lo que es necesario
para el producto, es decir que lo que se exprese en dicho requisito es necesario para el buen
desempeo y desarrollo del producto.
b. No ambiguo. -Es decir debe diferenciarse de los dems requisitos adems de tener claridad
en su interpretacin independiente del punto de vista que se visualice.
c. Conciso. -Donde bsicamente debe expresar lo que se desea de una manera breve y
comprensible, que permita facilitarles su entendimiento al equipo desarrollador y al cliente para
obtener un excelente producto.
d. Completo. -Como su mismo nombre lo dice debe contener la informacin requerida para un
buen entendimiento del mismo.
e. Alcanzable. -Debe ser algo muy puesto sobre la tierra, el cual tenga un objetivo alcanzable a
travs de diferentes recursos.
f. Verificable. -Que pueda brindarles a los usuarios la certeza de que fue cumplido el requisito a
travs de un componente del desarrollo software o de una funcionalidad.

Tipos de requisitos
La Ingeniera de Requisitos, como su mismo nombre lo indica tiene como elemento
fundamental el requisito que como est plasmado anteriormente es la expresin de una
necesidad que tiene el cliente, sin embargo este puede ser distribuido en diferentes tipos de
requisitos, unos ms utilizados que otros, pero dicha clasificacin se especifica a continuacin:
a. Requisitos Funcionales. Son los que de alguna manera u otra describen las funcionalidades o
el comportamiento que debe tener el sistema, estos requisitos vienen a ser complementados por
cada uno de los requisitos no funcionales, en conclusin estos son los que constituyen el
comportamiento del sistema y es por tal motivo que la definicin de cada uno de ellos debe
provenir de la interaccin con los clientes/usuarios, proveedores o personas involucradas en el
desarrollo del software y adems se deben tener en cuenta cada una de las reglas de negocio que
fueron establecidas en la organizacin, ya que estas brindan directrices con respecto a cmo est
establecido el negocio.
b. Requisitos No Funcionales. Son aquellos que determinan una necesidad en el sistema pero
que no hacen parte de una funcionalidad especfica que se tenga que construir en el sistema, es
por esto que hacen referencia contrariamente a elementos de informacin o de funciones que
deba cumplir el sistema. 2.2.3 Requisitos de Informacin. Son aquellos que a diferencia de los
anteriores va ms de la mano de lo que se denominan restricciones, son elementos de
informacin que le brindan al equipo de desarrollo unas restricciones a tener en cuenta a la hora
de trabajar en el producto, es decir elementos que directa o indirectamente afectan la labor de
desempeo.

Elicitacin de requisitos (ER)

Considerada la primera etapa en el proceso de comprender el problema que se quiere resolver
con el software. Se trata, esencialmente, de identificar las partes interesadas y se establecen las
relaciones entre el comprador, el cliente, los usuarios y el equipo de desarrollado.
La fase del anlisis de requisitos se es de suprema importancia porque es donde se debe obtener
una versin final de lo que espera el cliente para satisfacer su necesidad, donde se discrepen
elementos que no sean de mayor relevancia o que puedan complicar el buen desarrollo del
proyecto. Por todo lo anterior descrito la etapa de anlisis de requisitos tiene su objetivo
principal enmarcado por la deteccin de conflictos y defectos en cuanto a la comunicacin que
se da entre el usuario y el personal del equipo de desarrollo, de tal manera que estos permitan
ser transformados apropiadamente en elementos a tratar dentro del diseo.

Tcnicas de elicitacin de requisitos

Existen diversas tcnicas de elicitacin entre las ms comunes se encuentran:

Entrevistas: esta es tal vez la ms comn de todas y por lo general se entrevista solo en
pequeos grupos de trabajo, pueden ser estructuradas en las cuales se define una agenda de
preguntas abiertas para los participantes o abiertas las cuales no tienen una agenda comn. Las
ventajas de estas son que se puede obtener buena coleccin de informacin y descubrir deseos,
metas, opiniones entre otras, claves para los requisitos del Sistema. Las desventajas podran ser
la predisposicin de los entrevistados y el anlisis de datos cualitativos

Talleres: es comn que los requisitos tengan diferentes puntos de vista de acuerdo a las
necesidades de cada implicado o usuario lo cual hace conveniente la utilizacin de los talleres
para que de manera controlada se generen discusiones entre los implicados, que permitan
obtener detalles y por ende requisitos insospechados.

Lluvia de ideas (Brainstorming): esta tcnica de elicitacion de requisitos se realiza de manera

grupal y permite en un entorno relajado y natural para los implicados aportar sugerencias
creativas libremente, incentivando el surgimiento de nuevos requisitos aprovechando la
capacidad creativa de manera oportuna en un ambiente propicio. Sus etapas suelen ser la
preparacin, generacin, consolidacin y documentacin.
 Forma de contrato: consiste en llenar formularios o contratos indicando los requisitos. Puede
resultar extenso de acuerdo al tamao del Proyecto y por ende tendera a ser tediosa su
utilizacin dentro del desarrollo del software.

Objetivos medibles: es una tcnica que tiene como principal objetivo recopilar todos los
requisitos que se convierten en objetivos generales pero que posteriormente se analizaran
detalladamente con el fin de establecer objetivos concretos que estarn de la mano con lo que el
usuario expresaba que deseaba que el sistema realizara, adems se establecern mecanismos a
travs de los cuales se d a conocer el progreso de estos.

Prototipos: con esta tcnica lo que se pretende es darle al cliente una primera visin de lo que
ellos quieren que haga el sistema, los prototipos son un ejemplo que muestra a grandes rasgos
como se podra visualizar el producto desarrollado y de esta forma ver si se est enfocado en lo
que es o si se est desviado de la realidad.

El proceso de iniciar un nuevo sistema puede dividirse en las siguientes cuatro categoras,
dependiendo del grado de claridad que tengan las partes interesadas de las necesidades del
mismo:
1) tanto los desarrolladores como los clientes tienen claros los requisitos de proyecto
2) los desarrolladores no los tienen claros pero el cliente s
3) ni los desarrolladores ni el usuario los tienen claros
4) los desarrolladores los tienen claros, pero del lado del cliente no.

Dificultades en la elicitacin de requisitos

1. Problemas de alcance. Las fronteras del sistema estn mal definidas o los clientes/usuarios
definen detalles tcnicos innecesarios que pueden confundir, ms que aclarar, los objetivos
generales del sistema.
2. Problemas de comprensin. Los clientes/usuarios no estn completamente seguros de lo que
necesitan, tienen una comprensin deficiente de las capacidades y limitaciones de su entorno
informtico, no tienen una plena comprensin del dominio del problema, tienen dificultades
para comunicar sus necesidades al ingeniero de software, omiten informacin que consideran
evidente, definen requisitos que entran en conflicto con las necesidades de otros
clientes/usuarios, o definen requisitos que son ambiguos o incomprobables.
3. Problemas de volatilidad. Los requisitos cambian con el tiempo. La ER es el componente
bsico sobre el que se construye un proyecto software y tiene un impacto muy alto en el diseo
y las fases posteriores del ciclo de vida del producto. Si se realiza apropiadamente, puede
ayudar a reducir los cambios y las correcciones en los requisitos.