Requerimientos

de Software

Ingeniería de
Software

1
Conceptos y tipos de
requerimientos
Comenzaremos la lectura con la definición de requerimiento y los conceptos
de requerimientos de usuarios y del sistema y marcaremos cuáles son las
diferencias que existen entre requerimientos de software funcionales y los
no funcionales.

Requerimiento según la IEEE (Standard Glossary for Software

Engineering Terminology):
1-Una condición o capacidad requerida por un usuario
para resolver un problema o alcanzar un objetivo.
2-Una condición o capacidad que debe cumplir o poseer
un sistema o componente de sistema para satisfacer un
contrato, estándar, especificación, o cualquier otro
documento impuesto formalmente.
3- Una representación documentada de una condición o
capacidad de lo explicado en los puntos 1 o 2. (IEEE Computer
Society Press, 1990, goo.gl/ZaFI9o).

Conceptos y tipos de requerimientos de software

Comenzaremos definiendo los requerimientos del usuario. Estos son
escritos en un lenguaje natural junto con los diagramas, describen qué
servicios son lo que esperan los usuarios del sistema y cuáles son las
restricciones con las que este va operar.
Un ejemplo de requerimiento de usuario: “El MHC-PMS elaborará
mensualmente informes administrativos que revelen el costo de los
medicamentos prescritos por cada clínica durante ese mes” (Sommerville,
2011, p. 84).
En cambio, los requerimientos del sistema son descripciones detalladas de
todas las funciones, servicios y restricciones operacionales que debe tener
el software.
Un ejemplo de requerimiento del sistema: “En el último día laboral de cada
mes se redactará un resumen de los medicamentos prescritos, su costo y las
clínicas que los prescriben” (Sommerville, 2011, p. 84).
El documento de requerimientos del sistema debe definir con exactitud qué
se implementará. Puede ser parte del contrato entre el cliente del sistema y
los desarrolladores del software.

2
Hay que dejar en claro que los requerimientos del sistema no solo están para
describir los servicios o las características que deben proveer como sistema,
también deben especificar la funcionalidad que asegure que los servicios y
características puedan ser entregados de manera correcta.
El hecho de hacer una mala especificación de requerimientos causa muchos
problemas posteriores en la ingeniería de software.
Es bastante difícil el hecho de tener que separar en el documento de
especificación de requerimientos, los que son del tipo funcionales de los no
funcionales, ya que si se expresan por separado, las relaciones que existen
entre estos van a ser muy difíciles de entender. De todas maneras, se deben
destacar de manera explícita los requerimientos que están relacionados con
las propiedades no funcionales, como es el caso del rendimiento o la
fiabilidad, y establecer una sección específica en el documento de
requerimientos.

Clasificación de requerimientos

Existen tres categorías de requerimientos de software los funcionales y los

no funcionales y los de dominio.

Requerimientos funcionales: Son enunciados acerca de

servicios que el sistema debe proveer, de cómo debería
reaccionar el sistema a entradas particulares y de cómo
debería comportarse el sistema en situaciones específicas. En
algunos casos, los requerimientos funcionales también
explican lo que no debe hacer el sistema.
Requerimientos no funcionales: Son limitaciones sobre
servicios o funciones que ofrece el sistema. Incluyen
restricciones tanto de temporización y del proceso de
desarrollo, como impuestas por los estándares.
(Sommerville, 2011, pág. 85)

.
Los requerimientos no funcionales determinan cuáles son las limitaciones
de los servicios o funciones del sistema, como son la confiabilidad,
disponibilidad, eficiencia o performance, portabilidad, robustez, facilidad de
uso y de mantenimiento.
Por ejemplo, si un cajero automático no cubre sus requerimientos de
fiabilidad, no será certificado para su operación como dispositivo seguro.
Los requerimientos de dominio se derivan del dominio de aplicación del
sistema. Pueden ser requerimientos funcionales nuevos por derecho propio,
restricciones funcionales de los existentes o formas en que deben realizarse
distintos cálculos particulares.

3
¿El usuario siempre sabe realmente lo que necesita?

En ocasiones, el usuario no sabe bien lo que quiere y es nuestra tarea como

profesionales saber relevar sus necesidades y ayudarlo a poder definir los
requerimientos, aprovechando todo el conocimiento de las tecnologías en
las que se pueden implantar las soluciones. Hay que poder darle visibilidad
a sus requerimientos utilizando técnicas de análisis y modelado. El usuario
conoce el negocio, pero nosotros tenemos conocimiento acerca de cómo
modelarlo, por eso, cuando el usuario realmente no sabe lo que quiere,
debemos ayudarlo.

El documento de requerimientos

Este posee un conjunto variado de usuarios que van desde el administrador

ejecutivo de la organización, que es quien paga por el sistema, hasta todo el
equipo de ingenieros responsables del desarrollo del software.

Figura 1: Posibles usuarios del documento y cómo ellos lo utilizan

Fuente: (Sommerville, 2011, pág. 92)

4
La diversidad de usuarios en este documento de requerimientos significa
que este debe brindar una definición de los requerimientos con una
descripción precisa, para ser utilizado por los desarrolladores y
examinadores, incluyendo también información de posible evolución del
sistema. El detalle del documento de requerimiento va estar estrechamente
ligado al tipo de sistema a diseñar y el proceso de desarrollo utilizado.

5
Referencias
IEEE Computer Society Press. (1990). IEEE Standard Glosary of Software
Engineering Terminology. New York, Estados Unidos: The Insitute of Electrical and
Electronics Engineers.

Sommerville, I. (2011). Ingeniería del Software (9 na ed.). Madrid: Pearson

Educacion S.A.