Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Identificar los actores externos al sistema que interactan con la aplicacin de forma
relevante.
Refinar los protocolos de interaccin que usan los actores para llevar a cabo las
diferentes transacciones que se pueden realizar con el sistema.
DISCUSIN
La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una
evaluacin de los mismos antes de definir si son adecuados para el cliente.
En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como
referencia los niveles de abstraccin y descomposicin de cada problema presentado.
Los principales pasos de esta actividad son:
Descubrir problemas potenciales: En este paso se asegura que todas las caractersticas de los
requerimientos estn presentes en cada uno de los ellos, es decir, se identifican aquellos
requerimientos ambiguos, incompletos, inconsistentes, etc.
Clasificar los requerimientos: En este paso se busca identificar la importancia que tiene un
requerimiento en trminos de implementacin. A esta caracterstica se le conoce como
prioridad y debe ser usada para establecer la secuencia en que ocurrirn las actividades de
diseo y prueba de cada requisito. La prioridad de cada requerimiento depender de las
necesidades que tenga el negocio.
En base a la prioridad, cada requerimiento puede ser clasificado como mandatorio, deseables o
innecesarios. Un requerimiento es mandatorio si afecta una operacin crtica del negocio. Si
existe algn proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un
requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para
fases posteriores, el requerimiento es catalogado como innecesario.
Una vez hecha esta categorizacin de los requerimientos, puedo tomar como estrategia general
el incluir los mandatorios, discutir los deseables y descartar los innecesarios.
Antes de decidir la inclusin de un requerimiento, tambin debe analizarse su costo,
complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de
implementar, puede ser una buena idea incluirlo por ms que ste sea slo deseable.
Evaluar factibilidades y riesgos: Involucra la evaluacin de factibilidades tcnicas (Pueden
implementarse los requerimientos con la tecnologa actual?); factibilidades operacionales
(puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades econmicas
(ha sido aprobado por los clientes el presupuesto?).
En la actividad de negociacin, se incrementa la comunicacin entre el equipo de desarrollo y
los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay
una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:
Estas tareas se desarrollan en forma interactiva a partir de un abordaje progresivo del problema.
Se espera que una especificacin de requerimientos que fue aprobada por clientes y/o usuarios
tenga al menos las siguientes caractersticas:
ALTERNATIVAS
An despus de los tpicos dados y de que se realice la discusin, puede ser posible que se
incurra en errores u omisiones con los requerimientos. Es por esto que lo siguiente es dar
alternativas sobre los mismos y evaluarlas segn corresponda.
Una correcta presentacin de alternativas ser el primer paso en una adecuada presentacin y
preparacin del proyecto o a una alternativa final para la solucin. Tambin, ser la base para el
documento de especificaciones tcnicas en el proceso.
Restricciones asociadas a cada alternativa
La idea es mencionar las restricciones de precio, mantencin, operacin y tecnologa que
presenta cada alternativa.
Producto o servicio esperado en cada alternativa
Debe establecerse si se espera el mismo servicio o producto por cada alternativa de solucin y
en qu consiste en trminos generales. Por ejemplo, se podra mencionar que el producto de la
alternativa seleccionada cumplir con un requerimiento especfico y que en cambio no
solucionar otro requerimiento menos importante.
ESPECIFICACIN DE REQUERIMIENTOS
Consiste en el desarrollo de un documento que de manera clara y precisa contenga y especifique
cada uno de los requerimientos del sistema. Aqu se deben especificar los requerimientos
funcionales y no funcionales en forma clara y detallada.
ISO/IEC 26514:2008
IEEE 830
ISO/IEC 26514:2008
Esta ISO est enfocada en la documentacin por parte del desarrollador del sistema y cubre la
documentacin como producto, su estructura, contenido y formato.
Dentro de esta ISO podemos encontrar 2 partes fundamentales
La primera: ayuda a establecer la informacin que los usuarios necesitan y a cmo determinar
la mejor forma en que se le debe dar la informacin al usuario
La segunda: cubre lo que es el manual del usuario cmo debe ser impreso, tutoriales y
documentacin de referencia para el usuario
IEEE 830 RSR (especificacin de requerimientos del software)
Este estndar se utiliza como un acuerdo entre el cliente y el grupo de trabajo (desarrolladores)
Estos documentos tienen por finalidad reunir los requisitos completos del cliente para poder
desarrollar un producto de acuerdo a lo que el cliente quiere y necesita.
Sus funciones principales son:
Determinar con precisin las funciones y las restricciones del software o producto
Es la base para desarrollar cualquier tipo de planificacin, diseo, codificacin, pruebas
del software y documentacin.
Administradores de proyecto
Documentadores
Diseadores de bases de datos
VALIDACIN DE REQUERIMIENTOS
Proceso por el cual se determina si la especificacin es consistente con las necesidades del
cliente.
Incluye verificar trazabilidad entre la especificacin y el documento de requerimientos.
Se trabaja con un bosquejo completo del documento a diferencia de la verificacin del Anlisis.
Se realizan las siguientes verificaciones en el documento de requerimientos:
Validez: compromiso con el usuario, que valide que es lo que quiere.
Consistencia: que no haya contradicciones.
Realismo: que se puedan implementar (incluye: tecnologa, presupuesto y
calendario).
Verificabilidad: Disear conjunto de pruebas para demostrar que el sistema
cumple esos requerimientos.
La validacin de requerimientos sirve para demostrar que stos realmente definen el sistema
que el cliente desea. Asegura que los requerimientos estn completos, son exactos y
consistentes. Debe garantizar que lo descrito es lo que el cliente pretende ver en el producto
final. Esta validacin es importante porque la deteccin de errores durante el proceso de anlisis
de requerimientos reduce mucho los costos. Si se detecta un cambio en los requerimientos una
vez que el sistema est hecho, los costos son muy altos, ya que significa volver a cambiar el
diseo, modificar la implementacin del sistema y probarlo nuevamente.
Inspecciones de Software
Analizan y comprueban las representaciones del sistema (los diagramas de diseo, el cdigo
fuente del programa). Se aplica a todas las etapas del proceso de desarrollo y se complementan
con algn tipo de anlisis automtico del texto fuente y documentos asociados. Son tcnicas de
verificacin y validacin estticas, no requieren que el sistema se ejecute. (Ceniceros, 2012)
Pruebas de Software:
Consisten en comparar datos tericos con los resultados del software utilizando series de datos
de prueba, se examinan los resultados del software y su comportamiento operacional para
comprobar que se desempee conforme a lo requerido. Es una tcnica dinmica de la
verificacin y validacin ya que requiere disponer de un prototipo ejecutable del sistema.
(Ceniceros, 2012)
10
Proceso de Depuracin:
Localizar los fallos es un proceso complejo porque los fallos no necesariamente se localizan cerca
del punto en que se detectan. Para localizar un fallo de un programa el programador responsable
de la depuracin tiene que disear programas de prueba adicionales que repitan el fallo original
y que ayudan a descubrir el origen del fallo.
Despus de que se descubre el origen del fallo en el programa, este debe corregirse y entonces
reevaluar el sistema. Esto implica repetir de nuevo las pruebas anteriores (pruebas de
regresin). Estas pruebas se hacen para comprobar que los cambios introducidos resuelven
definitivamente el fallo y no introducen nuevos fallos. La estadstica muestra que la reparacin
de un fallo frecuentemente es incompleta y adems introduce nuevos fallos. (Drak & Lopez,
2014)
11