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