Determinación de Requerimientos

Para la determinación de requerimientos se hace un proceso conocido como Ingeniería de Requerimientos. Se le conoce como Ingeniería de Requerimientos (IR) al proceso de descubrir, analizar, documentar y verificar los requerimientos y restricciones de un cliente para el desarrollo de un software.

Un requerimiento es una descripción de lo que el sistema debe hacer y las restricciones para su operación, los requerimientos pueden ser obtenidos de forma verbal, escrita, o a través de especificaciones precisas como plantillas, formatos, contratos, etc. En el entorno de la IR los requerimientos se clasifican en requerimientos funcionales y no funcionales.

 Tipos de Requerimientos

Requerimientos Funcionales

Un requerimiento funcional define una función del sistema de software o sus componentes. Una función es descrita como un conjunto de entradas, comportamientos y salidas. Los requisitos funcionales pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir. Los requerimientos de comportamiento para cada requerimiento funcional se muestran en los casos de uso. Son complementados por los requisitos no funcionales, que se enfocan en cambio en el diseño o la implementación.

Como se define en la ingeniería de requisitos, los requisitos funcionales establecen los comportamientos del sistema.

Típicamente, un analista de requisitos genera requisitos funcionales después de realizar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el desarrollo de software es un proceso iterativo y algunos requisitos son previos al diseño de los casos de uso. Ambos elementos (casos de uso y requisitos) se complementan en un proceso bidireccional.

Un requisito funcional típico contiene un nombre y un número de serie único y un resumen. Esta información se utiliza para ayudar al lector a entender por qué el requisito es necesario, y para seguir al mismo durante el desarrollo del producto.

El núcleo del requisito es la descripción del comportamiento requerido, que debe ser clara y concisa. Este comportamiento puede provenir de reglas organizacionales o del negocio, o ser descubiertas por interacción con usuarios, inversores y otros expertos en la organización.

Requerimientos no Funcionales

Un requisito no funcional o atributo de calidad es un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requisitos funcionales. Por tanto, se refieren a todos los requisitos que no describen información a guardar, ni funciones a realizar.

Algunas métricas para especificar requerimientos no funcionales son:

PROPIEDAD	MEDIDA
Rapidez	Número de transacciones por segundo Tiempo de respuesta usuario Tiempo de actualización del sistema
Tamaño	Mbytes
Facilidad de uso	Tiempo de capacitación Número de cuadros de ayuda
Fiabilidad	Disponibilidad Probabilidad de indisponibilidad de tiempo promedio de falla
Robustez	Tiempo de reinicio después de falla Porcentaje de eventos que causan falla
Portabilidad	Porcentaje de enunciados dependientes de objetivo Número de sistemas objetivo.

En la práctica se puede realizar una lista de requerimientos, posteriormente identificar los funcionales y no funcionales.

La Especificación de Requerimientos

La especificación de requerimientos es el proceso de escribir en un documento las características o restricciones del sistema. Generalmente los requerimientos del usuario se realizan en lenguaje natural, tablas y formatos sencillos, así como diagramas intuitivos. Entre las notaciones más usadas se tienen:

Notación	Descripción
Lenguaje natural	Se escriben en enunciados, cada enunciado deberá ser un requerimiento
Lenguaje natural estructurado	Se escriben en lenguaje natural empleando una plantilla previamente elaborada.
Anotaciones graficas	Se emplea UML específicamente casos de uso y diagrama de secuencias.

Técnicas utilizadas para conocer requerimientos

Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.

Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él.

Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales.

Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema. Este tipo de preguntas son siempre apropiadas, además que ayudan a entender la perspectiva del afectado y no están influenciadas por el conocimiento de la solución.

Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas.

Del Usuario 

·        ¿Quién es el cliente?  

·        ¿Quién es el usuario?  

·        ¿Son sus necesidades diferentes?  

·        ¿Cuáles son sus habilidades, capacidades, ambiente?

·        Del Proceso 

·        ¿Cuál es la razón por la que se quiere resolver este problema?  

·        ¿Cuál es el valor de una solución exitosa?  

·        ¿Cómo usted resuelve el problema actualmente?  

·        ¿Qué retrasos ocurren o pueden ocurrir?

Del Producto

·        ¿Qué problemas podría causar este producto en el negocio?  

·        ¿En qué ambiente se usará el producto?  

·        ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento?  

·        ¿Qué obstáculos afectan la eficiencia del sistema?

El éxito de esta técnica combinada, depende de la habilidad del entrevistador y de su preparación para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cómo tratar con problemas potenciales. Asimismo, necesitan considerar no sólo la información que adquieren a través del cuestionario y la entrevista, sino también, su significancia. 

Ejemplo.

Se desea tener un sistema para facilitar las actividades en la evaluación de clases muestras de profesores para una determinada escuela.

Desarrollo

Requerimientos no funcionales

a)     Se debe de contar con un equipo exclusivo para almacenar la aplicación y base de datos.

b)     Proveer un servicio de red para la conectividad con la aplicación.

c)      Se debe tener disponibilidad las 24 horas del día los 365 días del año.

d)     El sistema deberá ser escalable.

e)     El sistema deberá permitir la concurrencia.

f)       Mantenibilidad

g)     Interfaz

Requerimientos funcionales

• La aplicación debe ser creada en una arquitectura cliente-servidor de dos o tres capas.
• El uso de colores para la interfaz de usuario debe ser verde, blanco, rojo, azul claro y gris.
• Manejar privilegios para los diferentes tipos de usuarios, en este caso, administrador, coordinador, docente y aspirante.
• El sistema debe ser capaz de autenticar a los usuarios del sistema independientemente de su rol.
• En el caso del administrador debe tener todos los privilegios sobre el acceso y consulta a la base de datos, específicamente debe ser capaz de cambiar los privilegios sobre el coordinador, docente y aspirante.
• El coordinador debe tener el privilegio de capturar diferentes tipos de exámenes y conocer los resultados de las evaluaciones aplicadas a aspirantes.
• El docente debe evaluar la clase muestra del aspirante.
• El aspirante debe poder presentar sus exámenes.
• El sistema debe ser capaz de realizar reportes sobre los aspirantes con mejores resultados en las diferentes evaluaciones presentadas.
• El sistema de ser capaz de generar reportes sobre los perfiles almacenados en la base de datos.

Aplicación de un cuestionario a un Administrador

• ¿Cuál es su nombre completo?
• ¿Cuál es su rol en esta organización?
• Como evaluador ¿qué pruebas aplica a los aspirantes?
• Describa en pasos el procedimiento para evaluar y seleccionar aspirantes a docentes
• ¿Quién elabora los exámenes?
• ¿Qué colores se usarían para la interfaz del sistema?
• ¿Qué información le interesa consultar frecuentemente?
• ¿Le interesa que la conectividad del sistema sea a través de una red?

 Aplicación de una Entrevista a un Coordinador de Licenciatura

• ¿Cuánto tiempo le lleva analizar las evaluaciones aplicadas a los aspirantes?
• ¿Qué cantidad de palería emplea para los expedientes de aspirantes?
• ¿Cuántas personas están involucradas en el proceso de evaluación y selección de aspirantes?
• ¿Qué aspectos son los más importantes para determinar una contratación?
• ¿Cómo clasifica los expedientes de los aspirantes?
• ¿Qué hace con los expedientes almacenados durante mucho tiempo?
• ¿Está interesado en automatizar el proceso de evaluación y selección de aspirantes? ¿porque?
• ¿Existe algo importante que desee agregar?

 Lluvia de ideas sobre requerimientos

No funcionales

• Mobiliario
• Características para el equipo de cómputo de memoria RAM de 4gb y disco duro de 1 tb
• Cámara web
• Conexión a internet
• Licencias
• Portabilidad
• Mantenimiento del sistema
• Escalabilidad

Funcionales

• Que este programada con HTML y PHP
• Que genere reportes de las evaluaciones
• Que muestre el resultado final de las evaluaciones
• Contar con una base de datos
• Que muestre los criterios a evaluar en el examen
• Que cuente con un cronometro de tiempo
• Que cuente con sesiones
• Que permita agregar preguntas en diferentes modalidades

Una opción para poder identificar los requerimientos funcionales de los no funcionales es separarlos en una tabla como se muestra a continuación en la Tabla 1.

Tabla 1. Identificación de requerimientos funcionales y no funcionales

Requerimiento	¿Se requiere?	¿Por qué?
Mobiliario	No	Porque el sistema puede operar sobre cualquier mobiliario
Características para el equipo de cómputo de memoria RAM de 4gb y disco duro de 1 tb	No	Se requiere de un servidor con mayor capacidad debido a que en un futuro alojara más sistemas de información.
Cámara web	Si	Para obtener una fotografía actualizada de los aspirantes
Conexión a internet	No	Porque el sistema será interno y puede funcionar a través de una intranet
Licencias	No	Porque se puede usar software libre
Portabilidad	Si	Para acceder al servidor desde cualquier plataforma
Mantenimiento del sistema	Si	Porque siempre surgen mejoras en el sistema
Escalabilidad	Si	Si porque se pueden agregar nuevos módulos conforme pase el tiempo.
Que este programada con HTML y PHP	Si	Porque se usará la arquitectura cliente servidor.
Que genere reportes de las evaluaciones	Si	Para conocer detalladamente las respuestas de las evaluaciones.
Que muestre el resultado final de las evaluaciones	Si	Para tomar decisiones sobre la contratación
Contar con una base de datos	Si	Para almacenar todos los registros sobre currículos y evaluaciones.
Que muestre los criterios a evaluar en el examen	Si	Para que las evaluaciones sean claras para los aspirantes.
Que cuente con un cronometro de tiempo para cada evaluación y así delimitar el tiempo para contestar.	No	Porque para las pruebas de psicológicas no se requiere de tiempo. Podría llevarse un registro del tiempo que tardo en contestar cada examen y generar una estadística.
Que cuente con sesiones	Si	Para poder manejar los privilegios para cada rol.
Banco de preguntas	Si	Para generar aleatoriamente preguntas y que no sea siempre el mismo examen.

 Referencias

[1] “Advancing Software Engineering Project Technical Report RPT – 071”, University of California at Irvine Departament of Information and Computer Sicence, Jun 1987.

[2] Boehm, “Software Engineering”, IEEE Transactions on Computers Dic. 1976.

[3] Brainstorm, Alex Osborne, 1941

[4] Federick P. Brook, “Essence and Accident in Software Engineering”. USA IEEE Computer, 1987.

[5] Ian Sommerville. “Software Engineering”, Addison-Wesley, 1992.

[6] IEEE “Task Force on Requirements Engineering”.

[7] Eric j Barudre, “Ingenieria de Software, Una perspective Orientada a Objetos”,  University Alfaomega, Boston.

[8] IT – Starts: “Developers Guide”, National Computing Center, Manchester EE. UU. 1989.

[9] Ivar Jacobson, James Rumbaugh y Grady Booch, “El Lenguaje Unificado de Modelado”, Addison Wesley, Madrid 1999.

[10]  Jacobson, I. et. al. 1992. “Object-Oriented Software Engineering; A Use Case Driven Aproach”, ACM Press. Adison-Wesley Publishing. Co. U.S.A. 

[11] Kotonya, G. and Sommerville, I., “Requirements Engineering, Processes and Techniques”, USA 1998.

[12] Kotonya, G. and Sommerville, I., Viewpoints for requirements definition, Software Engineering Journal, November 1992.

[13] Macaulay Linda A., “Requirements Engineering”, Verlag Berlin Heidelberg, New York 1996. [14] McMenamin, S.M, J.F. Palmer (1984), “Essential Systems Analysis”, New York: Yourdon Press.

[15] Meilir Page-Jones, “Fundamentals of Object-Oriented Design in UML”, Addison Wesley Reading, Massachusetts, 2000

[16] Ortas, A. “Aproximación a la Ingeniería de Requerimientos”, Uruguay, Universidad ORT Uruguay, 2001.

[17] Pressman Roger S., “Software Engineering: A Practitioner's Approach”, 5th edition, McGraw-Hill 2001.

[18] Raghavan S., G. Zelesnik y G. Ford., “Notes on Requirements Elicitation”, Educational Materials CMU/SEI-94-EM-10, Software Egineering Institute, Carnegie Mellon University, 1994.  [19] Senn, James A. “Análisis y Diseño de Sistemas de Información”. Segunda Edición. McGraw Hill. 1992.

[20] Barbara Romero “Técnicas de apoyo a la toma de decisiones en la Administración Pública” Instituto Nacional de Administración Pública, Madrid, 1984.

[21] “Unified Modeling Language Specification”, v1.3. Object Management Group (OMG), 1999.

[22] Rainer Burkhardt, “UML: Unified Modeling Language”, Addison-Wesley, 1997.

[23]http://www-306.ibm.com/software/rational/oifferings/reqanalysis.html [24]http://brainstorming.co.uk/tutorials/brainstormingprinciples.html  [25]http://www.brainstorming.co.uk/tutorials/preparingforbrainstorming.html