Procesos, modelado y formas de elicitación de requisitos[editar]

Siendo que la captura, elicitación y especificación de requisitos, es una parte crucial en el

proceso de desarrollo de software, ya que de esta etapa depende el logro de los objetivos
finales previstos, se han ideado modelos y diversas metodologías de trabajo para estos fines.
También existen herramientas software que apoyan las tareas relativas realizadas por el
ingeniero en requisitos.
El estándar IEEE 830-1998 brinda una normalización de las «Prácticas recomendadas para la
especificación de requisitos software».23
A medida que se obtienen los requisitos, normalmente se los va analizando, el resultado de
este análisis, con o sin el cliente, se plasma en un documento, conocido como ERS
o Especificación de requisitos software, cuya estructura puede venir definida por varios
estándares, tales como CMMI.
Un primer paso para realizar el relevamiento de información es el conocimiento y definición
acertada lo que se conoce como «Universo de Discurso» del problema, que se define y
entiende por:
Universo de Discurso (UdeD): es el contexto general en el cual el software deberá ser
desarrollado y deberá operar. El UdeD incluye todas las fuentes de información y todas las
personas relacionadas con el software. Esas personas son conocidas también
como actores de ese universo. El UdeD es la realidad circunstanciada por el conjunto de
objetivos definidos por quienes demandaron el software.
A partir de la extracción y análisis de información en su ámbito se obtienen todas las
especificaciones necesarias y tipos de requisitos para el futuro producto software.
El objetivo de la ingeniería de requisitos (IR) es sistematizar el proceso de definición de
requisitos permitiendo elicitar, modelar y analizar el problema, generando un compromiso
entre los ingenieros de requisitos y los clientes/usuarios, ya que ambos participan en la
generación y definición de los requisitos del sistema. La IR aporta un conjunto de métodos,
técnicas y herramientas que asisten a los ingenieros de requisitos (analistas) para obtener
requisitos lo más seguros, veraces, completos y oportunos posibles, permitiendo básicamente:

 Comprender el problema
 Facilitar la obtención de las necesidades del cliente/usuario
 Validar con el cliente/usuario
 Garantizar las especificaciones de requisitos
Si bien existen diversas formas, modelos y metodologías para elicitar, definir y documentar
requisitos, no se puede decir que alguna de ellas sea mejor o peor que la otra, suelen tener
muchísimo en común, y todas cumplen el mismo objetivo. Sin embargo, lo que si se puede
decir sin dudas es que es indispensable utilizar alguna de ellas para documentar las
especificaciones del futuro producto software. Así por ejemplo, hay un grupo de investigación
argentino que desde hace varios años ha propuesto y estudia el uso del LEL (Léxico
Extendido del Lenguaje) y Escenarios como metodología, aquí 24 se presenta una de las tantas
referencias y bibliografía sobre ello. Otra forma, más ortodoxa, de capturar y documentar
requisitos se puede obtener en detalle, por ejemplo, en el trabajo de la Universidad de Sevilla
sobre «Metodología para el Análisis de Requisitos de Sistemas Software». 25
En la Figura 7 se muestra un esquema, más o menos riguroso, aunque no detallado, de los
pasos y tareas a seguir para realizar la captura, análisis y especificación de
requisitos software. También allí se observa qué artefacto o documento se obtiene en cada
etapa del proceso. En el diagrama no se explicita metodología o modelo a utilizar,
sencillamente se pautan las tareas que deben cumplirse, de alguna manera.
Figura 7: Diagrama de tareas para captura y análisis de requisitos.

Una posible lista, general y ordenada, de tareas recomendadas para obtener la definición de
lo que se debe realizar, los productos a obtener y las técnicas a emplear durante la actividad
de elicitación de requisitos, en fase de Especificación de requisitos software es:

1. Obtener información sobre el dominio del problema y el sistema actual (UdeD).

2. Preparar y realizar las reuniones para elicitación/negociación.
3. Identificar/revisar los objetivos del usuario.
4. Identificar/revisar los objetivos del sistema.
5. Identificar/revisar los requisitos de información.
6. Identificar/revisar los requisitos funcionales.
7. Identificar/revisar los requisitos no funcionales.
8. Priorizar objetivos y requisitos.
Algunos principios básicos a tener en cuenta:

 Presentar y entender cabalmente el dominio de la información del problema.

 Definir correctamente las funciones que debe realizar el software.
 Representar el comportamiento del software a consecuencias de acontecimientos
externos, particulares, incluso inesperados.
 Reconocer requisitos incompletos, ambiguos o contradictorios.
 Dividir claramente los modelos que representan la información, las funciones y
comportamiento y características no funcionales.
Clasificación e identificación de requisitos[editar]
Se pueden identificar dos formas de requisitos:

 Requisitos de usuario: Los requisitos de usuario son frases en lenguaje natural junto a
diagramas con los servicios que el sistema debe proporcionar, así como las restricciones
bajo las que debe operar.
 Requisitos de sistema: Los requisitos de sistema determinan los servicios del sistema y
pero con las restricciones en detalle. Sirven como contrato.
Es decir, ambos son lo mismo, pero con distinto nivel de detalle.
Ejemplo de requisito de usuario: El sistema debe hacer préstamos. Ejemplo de requisito de
sistema: Función préstamo: entrada código socio, código ejemplar; salida: fecha devolución;
etc.
Se clasifican en tres los tipos de requisitos de sistema:

 Requisitos funcionales
Los requisitos funcionales describen:

 Los servicios que proporciona el sistema (funciones).

 La respuesta del sistema ante determinadas entradas.
 El comportamiento del sistema en situaciones particulares.

 Requisitos no funcionales
Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el
sistema (ej. cotas de tiempo, proceso de desarrollo, rendimiento, etc.)
Ejemplo 1. La biblioteca Central debe ser capaz de atender simultáneamente a todas
las bibliotecas de la Universidad
Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2 s
A su vez, hay tres tipos de requisitos no funcionales:

 Requisitos del producto. Especifican el comportamiento del producto (Ej.

prestaciones, memoria, tasa de fallos, etc.)
 Requisitos organizativos. Se derivan de las políticas y procedimientos de las
organizaciones de los clientes y desarrolladores (Ej. estándares de proceso,
lenguajes de programación, etc.)
 Requisitos externos. Se derivan de factores externos al sistema y al proceso de
desarrollo (Ej. requisitos legislativos, éticos, etc.)

 Requisitos del dominio.

Los requisitos del dominio se derivan del dominio de la aplicación y reflejan
características de dicho dominio.
Pueden ser funcionales o no funcionales.
Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos
mediante el Lenguaje de Intercomunicación de Bibliotecas de España (LIBE). Ej. El
sistema de biblioteca no podrá acceder a bibliotecas con material censurado.
Diseño del sistema[editar]
En ingeniería de software, el diseño es una fase de ciclo de vida del software. Se basa
en la especificación de requisitos producido por el análisis de los requisitos (fase de
análisis), el diseño define cómo estos requisitos se cumplirán, la estructura que debe
darse al sistema de software para que se haga realidad.
El diseño sigue siendo una fase separada de la programación o codificación, esta
última corresponde a la traducción en un determinado lenguaje de programación de
las premisas adoptadas en el diseño.
Las distinciones entre las actividades mencionadas hasta ahora no siempre son claras
cómo se quisiera en las teorías clásicas de ingeniería de software. El diseño, en
particular, puede describir el funcionamiento interno de un sistema en diferentes
niveles de detalle, cada una de ellos se coloca en una posición intermedia entre el
análisis y codificación.
Normalmente se entiende por "diseño de la arquitectura" al diseño de "muy alto nivel",
que solo define la estructura del sistema en términos de la módulos de software de
que se compone y las relaciones macroscópicas entre ellos. A este nivel de diseño
pertenecen fórmulas como cliente-servidor o “tres niveles”, o, más generalmente, las
decisiones sobre el uso de la arquitectura de hardware especial que se utilice, el
sistema operativo, DBMS, Protocolos de red, etc.
Un nivel intermedio de detalle puede definir la descomposición del sistema en
módulos, pero esta vez con una referencia más o menos explícita al modo de
descomposición que ofrece el particular lenguaje de programación con el que el
desarrollo se va a implementar, por ejemplo, en un diseño realizado con la tecnología
de objetos, el proyecto podría describir al sistema en términos de clases y sus
interrelaciones.
El diseño detallado, por último, es una descripción del sistema muy cercana a la
codificación (por ejemplo, describir no solo las clases en abstracto, sino también sus
atributos y los métodos con sus tipos).
Debido a la naturaleza "intangible" del software, y dependiendo de las herramientas
que se utilizan en el proceso, la frontera entre el diseño y la codificación también
puede ser virtualmente imposible de identificar. Por ejemplo, algunas herramientas
CASE son capaces de generar código a partir de diagramas UML, los que describen
gráficamente la estructura de un sistema software.
Codificación del software[editar]
Durante esta etapa se realizan las tareas que comúnmente se conocen
como programación; que consiste, esencialmente, en llevar a código fuente, en el
lenguaje de programación elegido, todo lo diseñado en la fase anterior. Esta tarea la
realiza el programador, siguiendo por completo los lineamientos impuestos en el
diseño y en consideración siempre a los requisitos funcionales y no funcionales (ERS)
especificados en la primera etapa.
Es común pensar que la etapa de programación o codificación (algunos la llaman
implementación) es la que insume la mayor parte del trabajo de desarrollo
del software; sin embargo, esto puede ser relativo (y generalmente aplicable a
sistemas de pequeño porte) ya que las etapas previas son cruciales, críticas y pueden
llevar bastante más tiempo. Se suele hacer estimaciones de un 30 % del tiempo total
insumido en la programación, pero esta cifra no es consistente ya que depende en
gran medida de las características del sistema, su criticidad y el lenguaje de
programación elegido.14 En tanto menor es el nivel del lenguaje mayor será el tiempo
de programación requerido, así por ejemplo se tardaría más tiempo en codificar
un algoritmo en lenguaje ensamblador que el mismo programado en lenguaje C.
Mientras se programa la aplicación, sistema, o software en general, se realizan
también tareas de depuración, esto es la labor de ir liberando al código de los errores
factibles de ser hallados en esta fase (de semántica, sintáctica y lógica). Hay una
suerte de solapamiento con la fase siguiente, ya que para depurar la lógica es
necesario realizar pruebas unitarias, normalmente con datos de prueba; claro es que
no todos los errores serán encontrados solo en la etapa de programación, habrá otros
que se encontrarán durante las etapas subsiguientes. La aparición de algún error
funcional (mala respuesta a los requisitos) eventualmente puede llevar a retornar a la
fase de diseño antes de continuar la codificación.
Durante la fase de programación, el código puede adoptar varios estados,
dependiendo de la forma de trabajo y del lenguaje elegido, a saber:

 Código fuente: es el escrito directamente por los programadores en editores de

texto, lo cual genera el programa. Contiene el conjunto de instrucciones
codificadas en algún lenguaje de alto nivel. Puede estar distribuido en paquetes,
procedimientos, bibliotecas fuente, etc.

 Código objeto: es el código binario o intermedio resultante de procesar con

un compilador el código fuente. Consiste en una traducción completa y de una
sola vez de este último. El código objeto no es inteligible por el ser humano
(normalmente es formato binario) pero tampoco es directamente ejecutable por la
computadora. Se trata de una representación intermedia entre el código fuente y
el código ejecutable, a los fines de un enlace final con las rutinas de biblioteca y
entre procedimientos o bien para su uso con un pequeño intérprete intermedio [a
modo de distintos ejemplos véase EUPHORIA, (intérprete
intermedio), FORTRAN (compilador puro) MSIL (Microsoft Intermediate
Language) (intérprete) y BASIC (intérprete puro, intérprete intermedio, compilador
intermedio o compilador puro, depende de la versión utilizada)].
o El código objeto no existe si el programador trabaja con un lenguaje a modo
de intérprete puro, en este caso el mismo intérprete se encarga de traducir y
ejecutar línea por línea el código fuente (de acuerdo al flujo del programa), en
tiempo de ejecución. En este caso tampoco existe el o los archivos
de código ejecutable. Una desventaja de esta modalidad es que la ejecución
del programa o sistema es un poco más lenta que si se hiciera con un
intérprete intermedio, y bastante más lenta que si existe el o los archivos de
código ejecutable. Es decir no favorece el rendimiento en velocidad de
ejecución. Pero una gran ventaja de la modalidad intérprete puro, es que él
está forma de trabajo facilita enormemente la tarea de depuración del código
fuente (frente a la alternativa de hacerlo con un compilador puro).
Frecuentemente se suele usar una forma mixta de trabajo (si el lenguaje de
programación elegido lo permite), es decir inicialmente trabajar a modo de
intérprete puro, y una vez depurado el código fuente (liberado de errores) se
utiliza un compilador del mismo lenguaje para obtener el código ejecutable
completo, con lo cual se agiliza la depuración y la velocidad de ejecución se
optimiza.

 Código ejecutable: Es el código binario resultado de enlazar uno o más

fragmentos de código objeto con las rutinas y bibliotecas necesarias. Constituye
uno o más archivos binarios con un formato tal que el sistema operativo es capaz
de cargarlo en la memoria RAM (eventualmente también parte en una memoria
virtual), y proceder a su ejecución directa. Por lo anterior se dice que el código
ejecutable es directamente «inteligible por la computadora». El código ejecutable,
también conocido como código máquina, no existe si se programa con modalidad
de «intérprete puro».