CATALOGO DE REQUERIMIENTOS

REQUISITOS DETECTADOS PARA EL SISTEMA

Se han detectado 2 requisitos principales los cuales pueden ser divididos en subrequisitos.

*El sistema debe de capturar la información del medio ambiente

*El sistema debe de transformar la información adquirida del medio ambiente en instrucciones que el cliente pueda entender.

Si nos damos cuenta el primer requisito se puede dividir en más requisitos ya que la captura de información del medio ambiente se puede hacer de distintas formas y con distinto hardware.

El segundo requisito ya es algo más entendible para nosotros los ingenieros en sistemas, ya que nos podemos dar una mejor idea de cómo procesar la información adquirida del medio ambiente y hacerla entendible al usuario.

Nota. Se pondrán más requisitos conforme se vayan haciendo más específicas las áreas de investigación del proyecto y se eviten grandes ramificaciones.

INGENIERIA DE REQUERIMIENTOS PARTE 3

Para la parte de validación de requerimientos se tienen las siguientes técnicas:

Reviews o Walk-throughs. Esta técnica nos puede ser de gran ayuda al momento de estar realizando el proyecto, ya que consiste en la revisión de la documentación de la definición de requisitos y así validar que los requisitos son válidos.

Auditorías.  Esta técnica nos será de gran ayuda ya que solo revisa una muestra de los resultados obtenidos comparándolos con todos los documentos obtenidos de instituciones.

Matrices de trazabilidad. Esta técnica consiste en marcar los objetivos del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo qué objetivos cubre cada requisito, de esta forma se podrán detectar inconsistencias u objetivos no cubiertos.

Prototipos. Algunas propuestas se basan en obtener de la definición de requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema, permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con el usuario (Olsina, 1999).

Esto es fundamental en el proyecto, ya que se tiene planeado ir paso  por paso y esta técnica nos ayuda a hacer eso.

INGENIERIA DE REQUERIMIENTOS PARTE 2

Para la etapa de definición de requerimientos se tienen las siguientes técnicas:

Lenguaje natural: Resulta una técnica muy ambigua para la definición de los requisitos. Consiste en definir los requisitos en lenguaje natural sin usar reglas para ello. A pesar de que son muchos los trabajos que critican su uso, es cierto que a nivel práctico se sigue utilizando.

Esta técnica en lo particular pareciera ser lo que la gente común pudiera usar pero, para un proyecto de nivel licenciatura no es lo más deseable ya que no está bien fundamentado su uso.

Glosario y ontologías: La diversidad de personas que forman parte de un proyecto software hace que sea necesario establecer un marco de terminología común. Esta herramienta es muy útil, en especial si se maneja un número grande de nuevos términos técnicos.

Plantillas o patrones. Esta técnica, recomendada por varios autores, tiene por objetivo el describir los requisitos mediante el lenguaje natural pero de una forma estructurada. Una plantilla es una tabla con una serie de campos y una estructura predefinida que el equipo de desarrollo va cumplimentando usando para ello el lenguaje del usuario.

Esta técnica es apropiada para el proyecto en el sentido que es más entendible poner los requisitos en lenguaje natural y partir de ahí hacia requisitos más técnicos.

Escenarios. La técnica de los escenarios consiste en describir las características del sistema a desarrollar mediante una secuencia de pasos (Liu & Yu, 2001). La representación del escenario puede variar dependiendo del autor. Esta representación puede ser casi textual o ir encaminada hacia una representación gráfica en forma de diagramas de flujo (Weidenhaupt, Pohl, Jarke & Haumer, 1999). El análisis de los escenarios, hechos de una forma u otra, pueden ofrecer información importante sobre las necesidades funcionales de sistema (Lowe & Hall, 1999).

Esta técnica puede ser una forma de hallar errores, de prevenirlos y darle más y mejor funcionalidad al sistema final. Ya que se entiende que un escenario puede derivarse la la pregunta: ¿Qué pasa si…?

Lenguajes Formales: Otro grupo de técnicas que merece la pena resaltar como extremo opuesto al lenguaje natural, es la utilización de lenguajes formales para describir los requisitos de un sistema.

INGENIERIA DE REQUERIMIENTOS PARTE 1

Al querer desarrollar cualquier sistema se necesita tener en cuenta los requerimientos que el sistema necesite y las técnicas que se necesitarán para poder obtener los requisitos,  los requerimientos deben de pasar por un procedimiento de aprobación y dicho proceso consta de 3 partes:

1.       Captura

2.       Definición

3.       Validación

Para la parte de la captura de requerimientos se tienen las siguientes técnicas:

Entrevistas. Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada.

Básicamente, la estructura de la entrevista abarca cuatro pasos: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados (protocolo de la entrevista).

La entrevista es la metodología principal a usar para la captura de requerimientos de mi proyecto, ya que obtendría información de primera mano y de la gente a la que está enfocada el proyecto.

Brainstorming (Tormenta de ideas). Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas.

Como técnica de captura de requisitos es sencilla de usar y de aplicar, puesto que no requiere tanto trabajo en grupo como éste.

Además suele ofrecer una visión general de las necesidades del sistema, pero normalmente no sirve para obtener detalles concretos del mismo, por lo que suele aplicarse en los primeros encuentros.

Concept Mapping. Los concept maps (Pan, Zhu & Johnson, 2001) son grafos en los que los vértices representan conceptos y las aristas representan posibles relaciones entre dichos conceptos. Esta metodología parecía ser buena opción para el proyecto pero debido a que el proyecto puede tener ramificaciones muy amplias, entonces los concept maps se harían confusos y poco entendibles.

Sketches y Storyboards. La misma consiste en representar sobre papel en forma muy esquemática las diferentes interfaces al usuario (sketches). Estos sketches pueden ser agrupados y unidos por enlaces dando idea de la estructura de navegación (storyboard).

Esta metodología pareciera ser la ideal pero solo al principio del proyecto. Esto para irse dando una mejor idea de cómo se va a hacer cada parte de la interfaz con el usuario, luego seria innecesaria.

Casos de uso. Aunque inicialmente se desarrollaron como técnica para la definición de requisitos (Jacobson, 1995), algunos autores proponen casos de uso como técnica para la captura de requisitos (Pan, Zhu & Johnson, 2001 y Liu & Yu, 200). Los casos de uso permiten mostrar el contorno (actores) y el alcance (requisitos funcionales expresados como casos de uso) de un sistema.

Esta metodología seria apropiada para el proyecto, en especial en saber cómo sería la interacción del usuario con el sistema.

Cuestionarios y Checklists: Esta técnica requiere que el analista conozca el ámbito del problema en el que está trabajando. Consiste en redactar un documento con preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas por unas cuantas opciones en el propio cuestionario (Checklist).  Al parecer es muy similar a la entrevista, así que será innecesario ya que no se obtendría información nueva o relevante a la ya obtenida con la entrevista.

Comparación de terminología: Esta técnica es utilizada en forma complementaria a otras técnicas para obtener consenso respecto de la terminología a ser usada en el proyecto de desarrollo. Para ello es necesario identificar el uso de términos diferentes para los mismos conceptos (correspondencia), misma terminología para diferentes conceptos (conflictos) o cuando no hay concordancia exacta ni en el vocabulario ni en los conceptos (contraste) (Pan, Zhu & Johnson, 2001). Sin duda esta técnica es muy útil para evitar malentendidos, pero es muy probable que el usuario final no llegue a utilizar la terminología que yo necesitaré utilizar, así que bastaría con entender los tecnicismos manejados en el proyecto.