Documento de Especificacion de Requerimientos

INGENIERÍA DE REQUERIMIENTOS
El requerimiento de Software determinado en la etapa de análisis, contendrá las

diferentes actividades acordadas con el usuario y serán organizadas de tal manera que
puedan ser evaluadas y entendidas por los usuarios del sistema y por el equipo
responsable de desarrollar el modulo respectivo. Los requerimientos constituyen una
ayuda que permite visualizar la manera de cómo debe funcionar un determinado
proceso, así como sus restricciones.
El documento de requerimientos deberá estar dividido en los siguientes puntos:
1. Requerimientos No Funcionales.-
Se refieren a las cualidades, restricciones y características del software. A
diferencia de los funcionales, no determinan una funcionalidad del sistema a
desarrollar.
Los requerimientos NO funcionales se caracterizan por ser:
 Específicos
 Cuantificables
 Verificables
Aquí se podrá considerar temas relacionados con:
- Atributos de calidad: Características, que, al cumplirse, mejoran en gran
medida la calidad del software.
o Confiabilidad: Estos requerimientos plantean que las aplicaciones no
son perfectas, pero limitan las fallas de la aplicación a determinados
valores.
o Disponibilidad: Tiempo en que debe estar disponible la aplicación.
o Seguridad: Medidas de seguridad con relación a procedimientos que
impliquen el uso de información vulnerable como, por ejemplo, las
claves de acceso al software.
o Mantenibilidad: Facilidad de reparar un defecto en el software.
o Portabilidad: El software debe funcionar en determinadas
plataformas o bajo ciertas condiciones.
- Restricciones: Requerimientos que definen los límites y condicione de cómo
una aplicación será diseñada o implementada.
1
o Exactitud: Indica la exactitud con la que se deben prestar los

servicios.
o Restricciones de herramientas o lenguajes: Lenguajes y herramientas
que se deben usar para el desarrollo y puesta en producción de las
aplicaciones.
o Restricciones de diseño: Son restricciones en el diseño del SW como
la necesidad de seguir ciertos estándares.
- Interfaces externas
o El SW a veces debe interoperar con otras aplicaciones del cliente.
o Las interfaces pueden ser de hardware, software o de
comunicaciones.
- Interfaces de usuario
o El diseño de las interfaces de usuario a veces se considera como una
tarea en la fase de requerimientos.
o El diseño de interfaces en borrador (wireframes, mockups y
prototipos) sirven para que el cliente pueda expresar de una mejor
manera lo que quiere.
- Control de errores: Este tipo de requerimientos indica cómo la aplicación
debe responder a los diferentes errores que se puedan presentar.
-
- El rendimiento del módulo y/o sistema cualificado en tiempo y espacio
- Temas relacionados con los diferentes interfaces desarrolladas
- Fiabilidad del módulo y/o sistema. Aquí se deberán explicar temas
relacionados con la seguridad informática (confidencialidad de la
información, integridad y disponibilidad de los datos y recursos y
confiablidad en la calidad de la información).
- Portabilidad. Se definirán las características del producto y la capacidad que
este tiene para que pueda ser ejecutado en una o en varias plataformas.
- Mantenibilidad: El diseño de las interfaces deben garantizar que las
propiedades y parámetros enviados a los métodos deben ser estándares.
Cada requerimiento no funcional debe ser explicado en lenguaje natural, se
acoplará a todo el producto y se lo codificará de la siguiente manera:
- Uso de la sigla “RNF”: Requerimiento No Funcional
2
- Uso del símbolo “-”: underscore

- Numero secuencial de cinco dígitos “00000”: Numero del Requerimiento no
funcional definido en el Proceso
A continuación se darán algunos ejemplos de requerimientos no funcionales
Especificación de Requerimiento No Funcionales

Nombre del Módulo y/o Sistema:
Fecha1:
RNF-00001. El sistema se encuentra orientado hacia la Web y su acceso se lo
podrá realizar usando cualquier explorador
RNF-00002. Las interfaces desarrolladas tendrán las características de ser

responsivas, es decir se acoplaran a cualquier tamaño y resolución de pantalla.
RNF-00003. Se utilizaran componentes y colores que permitan presentar la

información de manera organizada y entendible, manteniendo siempre la estética
de la interfaz.
RNF-00004. Los mensajes de error o advertencia que se desplegaran deberán ser

intuitivos.
A continuación, se presentará algunos ejemplos de Requerimientos NO Funcionales
1. Atributos de calidad2
- Confiabilidad:
 El usuario no puede experimentar más de dos fallas por mes en la
aplicación.
- Disponibilidad:
 La aplicación web debe estar disponible 24/7.
 La aplicación debe soportar «cinco nueves» en disponibilidad: Esto significa
que la aplicación estará disponible un 99,999% del tiempo al año. Indica
que la aplicación no puede estar caída por más de 5,26 minutos al año.
1
Fecha en la que se escribe el Requerimiento No Funcional
2
Estos requerimientos son críticos para aplicaciones que funcionan en tiempo real. Por ejemplo, aplicaciones de control de trenes,
tráfico aéreo, etc.
3
- Desempeño:
 La aplicación de recuperar la información del usuario y mostrarla en menos
de 3 segundos.
 El computo de la presión en el fluido del freno del carro debe hacerse en
menos de 1 milisegundo.
 La aplicación debe procesar 100 consultas SQL por segundo.
2. Seguridad: La longitud de las claves de la aplicación debe ser de mínimo 8
caracteres y debe incluir símbolos, al menos una mayúscula y al menos un
número.
3. Mantenimiento: Se debe determinar un tiempo promedio para responder ante un
error. Ejemplo: El tiempo promedio para reparar un error debe no mayor a 8
horas.
4. Requerimientos de Portabilidad:
- La aplicación debe funcionar en Windows, Linux, IOS.
- La aplicación web debe funcionar en firefox, Chrome, IE, etc.
- La aplicación web debe funcionar en PC, tabletas y dispositivos móviles
(Android, IOS, Windows Phone).
5. Restricciones
- Exactitud: indica la exactitud con la que se deben prestar los servicios.
- Restricciones de herramientas y lenguajes: Lenguajes y herramientas que se
deben usar para el desarrollo de las aplicaciones.
- Restricciones de diseño: Son restricciones en el diseño del SW como la
necesidad de seguir ciertos estándares.
6. Interfaces externas
- La aplicación debe ser compatible con el servidor web Jboss.
- La aplicación debe invocar los servicios tipo REST de la empresa y procesar sus
resultados.
- El formato de intercambio de datos con la aplicación del cliente debe ser XML.
7. Interfaces de usuario
- El diseño de interfaces en borrador (wireframes, mockups y prototipos) sirven
para que el cliente pueda expresar de una mejor manera lo que quiere.
8. Control de errores
4
- ¿Cómo debe actuar la aplicación si recibe un mensaje de otra aplicación

indicando que el formato del mensaje enviado es inválido?
- ¿Cómo debe actuar la aplicación si encuentra un error grave?
2. Requerimientos de Interfaz. - Los requerimientos de interfaz permite describir

todos los elementos que provee el sistema para la interacción con el usuario (cajas
de texto, botones de búsqueda, títulos, objetos de selección, radiobuttons, checkbox,
ayudas en línea, etc.) y la funcionalidad de cada uno de estos. Estos requerimientos
tienen como finalidad clarificar el número de elementos a ser implementados y la
interrelación de cada uno de estos elementos.
3. Requerimientos Funcionales.- La descripción del requerimiento funcional

detallara el funcionamiento de un proceso, función, actividad o componente. Aquí
se especifica cuáles son las entradas, el comportamiento de los datos y las salidas.
Como un requerimiento funcional se puede calificar al:
- Registro de un dato, de un detalle técnico, selección de una fecha, etc.
- La realización de un calculo
- La manipulación de una determinada porción de información o de un dato
- Control a ser implementado sobre un campo o proceso
La estructura de un requerimiento funcional o requerimiento de comportamiento,
deberá ser la que se indica en la siguiente tabla:
<<Nombre del Sistema>>

Especificación del Diseño del Requerimiento de Software - SRS
Código: Fecha:
Nombre del Proceso:
Responsable del
Requerimiento:
Prioridad:
Fuente
Descripción:
Entradas:
Salidas:
- Código: El código del requerimiento funcional se lo conformara de la
siguiente manera:
o Uso de la sigla “RF”: Requerimiento Funcional
o Uso del símbolo “-”: underscore
5
o Numero secuencial de cinco dígitos “00000”: Numero del

Requerimiento funcional definido en el Proceso
- Fecha: Fecha en la que se escribe el Requerimiento Funcional.
- Nombre del Proceso: Nombre del proceso, función, actividad o
componente del cual se ha generado los requerimientos funcionales
- Responsable del Requerimiento: Nombre del Técnico responsable de
desarrollar el requerimiento.
- Prioridad: Prioridad del Requerimiento Funcional. Su finalidad es
maximizar la eficiencia en el desarrollo del módulo y/o sistema, a través de
la organización de los requerimientos. Los valores que puede tomar este
ítem son los siguientes: N: Normal3. M: Moderada4. U: Urgente5.
- Fuente: Se debe señalar la base legal, la normativa institucional o el
nombre de la persona o personas de donde se obtuvo la información.
- Descripción: Descripción detallada de cada una de las actividades a ser
consideradas como parte del Requerimiento Funcional.
- Entradas: Determinar el número y tipo de cada uno los valores que el
usuario deberá ingresar en la interfaz, así como los provenientes de otros
procesos, pudiendo ser estos; aquellos que se encuentren almacenados como
variables globales o como parte de la Base de Datos.
- Salidas: Constituye todo tipo de información resultante del registro, calculo
o manipulación de los datos. Como dato de salida, también se debe
considerar los mensajes de: Aviso, Confirmación, Advertencia o Error que
el modulo y/o sistema debe emitir.
Adicional a la descripción detallada del Requerimiento Funcional, se podrá presentar el

prototipo del módulo, el mismo que podrá ser desarrollado usando la herramienta
Balsamiq Mockups versión 3.1.6 o superior
3
Dos o más procesos contribuyen al cumplimiento del objetivo
4
Considerar levemente la priorización de la ejecución del requerimiento
5
Esta actividad se debe de desarrollar antes que cualquier otra

Documento de Especificacion de Requerimientos

Cargado por

Copyright:

Formatos disponibles

Documento de Especificacion de Requerimientos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Documento de Especificacion de Requerimientos

Cargado por

Copyright:

Formatos disponibles

INGENIERÍA DE REQUERIMIENTOS

El requerimiento de Software determinado en la etapa de análisis, contendrá las

El documento de requerimientos deberá estar dividido en los siguientes puntos:

o Exactitud: Indica la exactitud con la que se deben prestar los

- Uso del símbolo “-”: underscore

A continuación se darán algunos ejemplos de requerimientos no funcionales

Especificación de Requerimiento No Funcionales

RNF-00002. Las interfaces desarrolladas tendrán las características de ser

RNF-00003. Se utilizaran componentes y colores que permitan presentar la

RNF-00004. Los mensajes de error o advertencia que se desplegaran deberán ser

A continuación, se presentará algunos ejemplos de Requerimientos NO Funcionales

- ¿Cómo debe actuar la aplicación si recibe un mensaje de otra aplicación

2. Requerimientos de Interfaz. - Los requerimientos de interfaz permite describir

3. Requerimientos Funcionales.- La descripción del requerimiento funcional

<<Nombre del Sistema>>

o Numero secuencial de cinco dígitos “00000”: Numero del

Adicional a la descripción detallada del Requerimiento Funcional, se podrá presentar el

También podría gustarte