Requerimientos

Seminario
de práctica

1
Concepto de
Requerimientos
En este módulo revisaremos los principales conceptos
respecto al término “Requerimiento”, sus
características, tipos, y metodologías para capturar
las Necesidades de Información de una empresa y
convertirlas en Requerimientos de Software.
Las necesidades de información del cliente o usuario
que se busca identificar son aquellas que contribuyen
a resolver cuestiones operativas, y/ sirvan de soporte
a la toma de decisiones.
Entender e Interpretar “qué necesita el cliente” o
“qué información desea que le provea el sistema” es
el reto que enfrenta la Ingeniería de Requerimientos.

La parte más difícil de construir un sistema de

software es decidir precisamente qué construir.
Ninguna otra parte del trabajo conceptual es tan
difícil como establecer los requerimientos técnicos
detallados... Ninguna otra parte del trabajo afecta
tanto el sistema resultante si se hace
incorrectamente. Ninguna otra parte es tan difícil de
rectificar más adelante (Fred Brooks - “No Silver
Bullet - Essence and Accidents of Software
Engineering”. IEEE Computer, artículo de Computer
Magazine, abril de 1987. Recuperado de:
http://goo.gl/zGTSs3).

1
 La Ingeniería de Requerimientos se define como el
proceso mediante el cual se capturan las necesidades
del cliente y se desarrolla un modelo de la solución a
esas necesidades.

Un requerimiento representa básicamente algo que se necesita que el

sistema a desarrollar haga, es decir, aquella funcionalidad o característica
que deberá poseer el sistema para cubrir las necesidades planteadas por
los usuarios.

“Las descripciones de los servicios y las restricciones para el sistema son los
requerimientos para el sistema y el proceso de descubrir, analizar,
documentar y verificar estos servicios y restricciones se llama Ingeniería de
Requerimientos” (Somerville, 2005, pág. 98).

Tipos de Requerimientos
Si bien existen diversas clasificaciones y/o tipificaciones de
Requerimientos, siguiendo diferentes criterios, específicamente para
software trabajaremos sobre los 3 siguientes tipos:

 Requerimientos funcionales, son las declaraciones de los servicios

que debe proporcionar el sistema, la forma en que éste debe
reaccionar a la entrada particular de datos, los procesos que debe
hacer con sus controles y de cómo debe comportarse en situaciones
particulares.

 Requerimientos no funcionales, son consideraciones sobre los

servicios del sistema o sus funcionalidades que limitan la forma en
que será implementado el mismo. Por lo general están relacionadas
con tiempo de respuesta, performance, criterios de las interfaces
de usuario, sobre el proceso de desarrollo y sus estándares.
Además, se aplican al sistema en general, rara vez pueden estar
asociados a una funcionalidad en particular.

 Requerimientos del dominio, provienen del dominio de la

aplicación, reflejan las características y restricciones de su dominio.
Estos requerimientos pueden ser funcionales y no funcionales.

2
A esta clasificación de los requerimientos, sumaremos un tipo más a tener
en cuenta: los Requerimientos candidatos, entendiendo por éstos los
requerimientos funcionales que no se tienen en cuenta en primera
instancia, pero que son de negocio y con el tiempo pueden convertirse en
requerimientos del dominio.

Requerimientos Funcionales

Un requerimiento funcional describe la funcionalidad que se espera que el

sistema provea. Es una descripción de cómo debe comportarse el sistema
ante determinado estímulo y cómo interacciona ante el ambiente. Un
requerimiento funcional describe lo que el sistema hará sin definición de
aspectos referidos a cómo será implementado. Se describe el qué hará y no
el cómo se hará.

Cuando se describen como requerimientos del usuario, se hace en lenguaje

coloquial, de negocio y de forma abstracta. Sin embargo, se describe en
detalle las funcionalidades, entradas, salidas, excepciones y restricciones.
Para documentar requerimientos funcionales se recomienda usar casos de
uso.

Requerimientos No Funcionales

Un requerimiento no funcional es el que impone restricciones al sistema

limitando la forma en que será implementado. Dan marco al “cómo se
hará”. Estas restricciones tienen que ver por ejemplo con la selección del
lenguaje de programación, la plataforma o técnicas y herramientas de
implementación a utilizar.

Su alcance se define a través de conceptos tales como:

 Performance

 Precisión

 Confiabilidad

 Seguridad

 Portabilidad

 Restricciones de la tecnología a utilizar, entre otros…

Tanto Requerimientos funcionales, como Requerimientos No Funcionales

son tomados del cliente en forma detallada y formalizados a través del
documento de Especificación de Requerimientos de Software (ERS).

3
Características de los Requerimientos
Para asegurar que los clientes y los desarrolladores comprendan y utilicen
correctamente los requerimientos es importante que éstos sean de alta
calidad, o sea estén bien formulados y maduros. Con este objetivo debe
comprobarse que los requerimientos posean las siguientes características:

 Necesario: cuando su omisión genera una deficiencia en el sistema

que se construirá, y además su capacidad, características físicas o
factor de calidad no pueden ser reemplazados por otras
capacidades del producto o del proceso.

 Conciso: cuando es fácil de leer y entender para todos los

involucrados en el sistema, tanto usuarios y clientes como el equipo
técnico. Su redacción debe ser simple y clara para aquellos
involucrados que vayan a consultarlos.

 No ambiguo: Su descripción debe ser clara, precisa y tener una sola

interpretación posible.

 Completo: cuando no necesita ampliar detalles en su redacción

para su comprensión, es decir, si se proporciona la información
suficiente para su comprensión.

 Consistente: si no es contradictorio o plantea conflictos con otro

requerimiento diferentes.

 Verificables: cuando puede ser comprobado de manera cierta que

el requerimiento fue satisfecho por el sistema que lo implementó.
Esta verificación puede realizarse mediante la inspección, análisis,
demostración o pruebas.

4
 Ingeniería de
requerimientos
La Ingeniería de Requerimientos trata los principios, métodos, técnicas y
herramientas que permiten descubrir, documentar, verificar y mantener
los requerimientos de forma sistemática y repetible.

Es importante tener presente la descripción que Sommerville realiza:

El proceso general corresponde a cuatro subproceso de alto

nivel de la Ingeniería de Requerimientos. Éstos tratan de la
evaluación de si el sistema es útil para el negocio (estudio de
viabilidad); el descubrimiento de requerimientos (obtención
y análisis); la transformación de estos requerimientos en
formularios estándar (especificación), y la verificación de
que estos requerimientos realmente definen el sistema que
quiere el cliente (validación) (Sommerville, 2005, pág. 130).

Fuente: Libro “Ingeniería del Software” – Ian Sommerville, pág. 130.

A lo largo del tiempo se han vertido diferentes opiniones respecto a las

actividades a desarrollar durante la ingeniería de requerimientos. Para

5
obtener mayor descripción del tema referirse a la materia Ingeniería de
Software, Lectura 7 Módulo 3.

A continuación vamos a repasar los subprocesos más importantes.

Relevamiento de Requerimientos
El proceso de “Elicitación” es el proceso de adquirir todo el conocimiento
relevante necesario para producir el modelo de los requerimientos del
dominio del problema. Se busca entender el dominio del problema a
solucionar.

Sin un conocimiento del problema no se puede entender la terminología, ni

testear la consistencia, ni la completitud de una especificación.

El analista de requerimientos debe conocer la naturaleza del problema,

entender del tema para poder interactuar con el cliente y relacionar las
especificaciones de requerimientos con las necesidades del cliente y la
veracidad del problema.

La obtención y análisis de requerimientos pueden afectar a varias personas

dentro de la organización y varios fuera de ella.

El término stakeholder (involucrado) se utiliza para referirse a cualquier

persona o jurídica que pueda tener influencia directa o indirecta sobre el
sistema. Es importante para el éxito del proyecto determinar la lista de
stakeholders, dado que participarán tanto de la obtención de los
requerimientos como de su validación. Es muy difícil determinar a priori
una lista completa, pero a medida que el proyecto avanza es necesaria
completarla.

Entre los stakeholders se encuentran los usuarios finales que interactúan

con el sistema y todos aquellos en la organización que se pueden ver
afectados por su instalación. Otros stakeholders del sistema pueden ser los
ingenieros que desarrollan o dan mantenimiento a otros sistemas
relacionados, los gerentes del negocio, los expertos en el dominio del
sistema y los representantes de los trabajadores.

Obtener y comprender los requerimientos de los stakeholders es complejo

por varias razones:

1. Los stakeholders a menudo no conocen lo que desean obtener del

sistema informático excepto en términos muy generales; puede resultarles
difícil expresar lo que quieren que haga el sistema o pueden hacer
demandas irreales debido a que no conocen el coste de sus peticiones.

6
2. Los stakeholders expresan los requerimientos con sus propios términos
de forma natural y con un conocimiento implícito de su propio trabajo. Los
analistas de requerimientos, sin experiencia en el dominio del cliente,
deben comprender estos requerimientos.

3. Diferentes stakeholders tienen requerimientos distintos, que pueden

expresar de varias formas. Los analistas de requerimientos tienen que
considerar todas las fuentes potenciales de requerimientos y descubrir las
concordancias y los conflictos.

4. El entorno económico y de negocios en el que se lleva a cabo el análisis

es dinámico. Inevitablemente, cambia durante el proceso de análisis. Por lo
tanto, la importancia de ciertos requerimientos puede cambiar. Pueden
emerger nuevos requerimientos de nuevos stakeholders que no habían
sido consultados previamente.

Uno de los principales desafíos de los analistas de requerimientos es

resolver los conflictos que se presentan entre las necesidades y deseos de
los stakeholders, y la principal herramienta que tiene para esto es la
comunicación.

Técnicas de Recolección de la información

Las diferentes técnicas, ventajas y desventajas se estudian en profundidad

en la materia Sistemas de Información (Módulo 2).

En este caso revisaremos la más relevante para aplicar para desarrollo de

Software, la entrevista. Se recomienda revisar la documentación contenida
en la Materia referida para complementar el conocimiento de las demás
herramientas: Cuestionario, Muestreo, Brainstorming, Observación, etc.…

Entrevista: es una conversación dirigida con un propósito específico y que

se basa en el uso de un formato preestablecido de preguntas y respuestas.

El analista, al utilizar esta técnica de recolección de información no sólo

busca información sino que también busca lograr una empatía con el
entrevistado que redunde en el éxito futuro de la aplicación de software a
desarrollar.

Los pasos a seguir para la concreción de una entrevista son:

 Lectura de material, tanto del entrevistado, como del problema y la

organización.

 Establecimiento de los objetivos de la entrevista. Use la información

de fondo que recopiló, así como su propia experiencia, para
establecer los objetivos de la entrevista.

7
  Decidir a quién entrevistar.

 Contactar la entrevista: organizar en base a los tiempos disponibles

por el entrevistado el momento adecuado de aplicar el
instrumento. Se establece la fecha, hora, lugar y duración de la
entrevista.

 Redactar las preguntas a realizar (Kendall, 2005, pág. 90).

Las preguntas a realizar pueden ser abiertas o cerradas. Recordamos el

concepto:

 Preguntas Abiertas: Aquellas que buscan una respuesta en donde el

entrevistado debe elaborar una descripción amplia del tema.
Implican respuestas extensas.

 Preguntas cerradas: Son las que tienen como respuesta un

conjunto acotado de alternativas. Deben poder establecerse dichas
alternativas con anterioridad.

Es fundamental para que la entrevista sea exitosa tener claro el objetivo

buscado, elaborar el plan previamente y disponer del conjunto de
preguntas redactadas.

Especificación de Requerimientos
La tarea fundamental que se define para el proceso de Especificación de
Requerimientos es la de realizar una análisis de los requerimientos
detectados y la creación de los modelos necesarios que representen la
solución del software, que tiene en cuenta esos requerimientos.

Para la creación del documento de ERS (Especificación de Requerimientos

de Software), un analista cuenta con una serie de herramientas que le
permiten describir la funcionalidad que tendrá el sistema, que será
utilizado no sólo para que el cliente pueda entender los procesos que
realizará el sistema sino también para comunicar a los diseñadores del
sistema cuáles son los procesos que éste debe hacer, para que los mismos
traduzcan esa solución hacia una definición comprensible por los
desarrolladores del sistema.

El documento de ERS cumplirá la función de un contrato entre el equipo de

desarrollo y el cliente, donde se detallará con claridad qué hace y qué no

8
hace el sistema, e incluirá tanto los requerimientos funcionales como no
funcionales definidos para el sistema.

El documento de ERS tiene varios destinatarios; desde los administradores

principales de la organización, quienes pagan por el sistema, hasta los
ingenieros responsables del software.

 Clientes del Sistema: Especifican los requerimientos y los leen para

verificar que cumplen sus necesidades. Especifican los cambios.

 Administradores: Utilizan el documento ERS para estimar el costo

del sistema y tiempos. Planificar el proceso de desarrollo del
sistema

 Ingenieros de sistemas: Utilizan los requerimientos para

comprender qué sistema debe desarrollarse

 Ingenieros encargados de las pruebas del sistema: Utilizan los

requerimientos para desarrollar las pruebas de verificación para el
sistema.

 Ingenieros encargados del mantenimiento del sistema: Utilizan los

requerimientos para comprender el sistema y las relaciones entre
sus partes.

La diversidad de posibles usuarios significa que el

documento de requerimientos (ERS) tiene que presentar un
equilibrio entre la comunicación de los requerimientos a los
clientes, la definición de los requerimientos en el detalle
exacto para los desarrolladores y analistas de pruebas, y la
inclusión de información sobre la posible evolución del
Sistema (Sommerville, 2005, 124).

Es por ello que existen seis requisitos que un documento de ERS debe
satisfacer:

 Especificará únicamente el comportamiento externo del sistema.

 Especificará las restricciones de la implementación.

 Será fácil de cambiar.

 Servirá como herramienta de referencia para los mantenedores del

sistema.

 Registrará las previsiones del ciclo de vida del sistema.

9
  Caracterizará las respuestas aceptables para los eventos no
deseados.

Existe gran cantidad de estándares definiendo el contenido del documento

de ERS, pero el estándar más ampliamente conocido es el IEEE/ANSI 830-
1998. Se recomienda tenerlo en cuenta como un marco general que se
puede adaptar para definir un estándar ajustado a las necesidades de una
organización.

Uso de Use Case en la captura de Requerimientos

La técnica de casos de uso se basa en escenarios para la obtención de

requerimientos que se introdujeron por primera vez en el método Objeto
(Jacobson, Objectory method, 1992).

UML lo plantea como guía para el proceso de desarrollo del software,

describiendo cada requerimiento funcional del sistema.

Un caso de uso está asociado a un actor y determina los casos de uso que
incluye y que extiende. Además de su gráfica de modelado, que se utiliza
para representar los requerimientos en forma de negocio, cuenta con una
ficha técnica que detalla los pasos a seguir por un comportamiento normal
y las alternativas de cada paso.

Los escenarios y los casos de uso son técnicas eficaces para obtener
requerimientos desde los puntos de vista de los usuarios y el equipo de
desarrollo, donde cada tipo de interacción se puede representar como un
caso de uso. No obstante, como se centran en las interacciones, no son tan
eficaces para detallar las restricciones y reglas de negocio, tampoco
identifican requerimientos no funcionales de alto nivel o para descubrir
requerimientos de dominio.

Se sugiere ampliar el tema consultando la materia Análisis y Diseño de

Software, Lectura 2 Módulo 2.

Validación de Requerimientos
La validación de los requerimientos es el proceso por el cual se determina
si la especificación es consistente con la definición de los requerimientos
iniciales, es decir, la validación asegura que los requerimientos satisfarán
las necesidades del cliente.

Validar los requerimientos a tiempo es importante debido a que los errores

en el documento de ERS pueden conducir a errores más importantes y

10
costosos del producto, el cual habrá que modificar para arreglarlos, siendo
mucho más costoso reparar errores después de estar codificado que en el
diseño.

Durante el proceso de validación de los requerimientos, se deben llevar a

cabo verificaciones de éstos en el documento de ERS. Estas verificaciones
pueden ser de validez, de consistencia, de completitud, de realismo, de
verificabilidad.

Esta revisión de los requerimientos debe involucrar a personas tanto del

equipo de desarrollo como del cliente, y pueden ser informales o formales.
Antes de realizar una revisión formal con el cliente, muchos problemas se
pueden detectar simplemente hablando del sistema de manera informal
con tantos stakeholders del sistema como sea posible. En la revisión
formal, el equipo de desarrollo debe “conducir” al cliente a través de los
requerimientos del sistema, explicándole las implicaciones de cada
requerimiento. Los conflictos, contradicciones, errores y omisiones, deben
ser resueltos antes de iniciar el diseño y la construcción del sistema.

Para complementar esta información te sugerimos revisar a la materia

Ingeniería de Software, Lectura 7 Módulo 3 pág. 25-26.

11
Referencias Bibliográficas

IEEE 830-1998. (1998). IEEE Recommended Practice for Software Requirements

Specifications.

Kendall, K. (2005). Análisis y Diseño de Sistemas. Sexta Edición. España: Pearson.

Sommerville, I. (2005). Ingeniería del Software. Séptima Edición. España: Pearson-

Addison Wesley.

12