Guía de uso del SRS01

Documento: Visión y Alcance
Proyecto:
Archivo:
420317046.doc
Versión:
Fecha:
Página:
1
//
1 de 7
Se deben ingresar arriba el nombre del proyecto, la versión (que comienza en 1 y es un
número consecutivo) y la fecha. Estos dos últimos campos coincidirán con el último
valor del historial de cambios que se encuentra debajo. Por otro lado el número de
versión también deberá coincidir con el que posee el nombre del archivo.
1. Introducción .................................................................................................................. 2
1.1 Propósito ................................................................................................................. 2
1.2 Alcance ................................................................................................................... 2
1.3 Definiciones, siglas y abreviaturas ......................................................................... 3
1.4 Referencias ............................................................................................................. 3
2. Descripción global ........................................................................................................ 3
2.1 Perspectiva del producto ......................................................................................... 3
2.2 Funciones y prestaciones funcionales del producto ............................................... 3
2.3 Características de los usuarios ................................................................................ 4
2.4 Restricciones........................................................................................................... 4
2.5 Asunciones y dependencias .................................................................................... 6
2.6 Requisitos a futuro .................................................................................................. 6
Historial de Cambios
Fecha
Versión
Cambio Realizado
//
1
Versión Inicial
Autor
La primer fila de este historial marca la construcción inicial del documento, luego se
deben enumerar cada una de las modificaciones que justificaron un cambio de versión,
indicando el autor y la fecha de finalización de la misma. Cuando las variaciones están
relacionadas con una reunión es recomendable incorporar en la columna de Autor la
lista de personas que intervinieron en la reunión, siempre poniendo en primer término el
autor definitivo del texto.
Documento: Visión y Alcance
Proyecto:
Archivo:
420317046.doc
Versión:
Fecha:
Página:
1
//
2 de 7
1. Introducción
1.1 Propósito
a) Propósito global del producto
En pocas líneas identificar el / los objetivos del producto y una descripción general del
mismo.
b) Público al que va dirigido.

Identificar los usuarios del producto a fin de dejar más en claro los párrafos escritos
anteriormente. Además de los usuarios directos del sistemas, es importante determinar
los actores intervinientes en el proceso en el que se insertará este producto.
1.2 Alcance
a) Funcionalidades globales que deben estar incluidas

Enumerar el conjunto de funcionalidades globales que debe tener el producto.
b) Funcionalidades globales que no necesitan estar incluidas

Enumerar todas aquellas funcionalidades que corresponden al contexto del problema
pero que no están incluidas entre los requerimientos del producto, es decir que el mismo
se puede considerar culminado satisfactoriamente sin que brinde estas funciones. Es
fundamental enumerar aquellas funcionalidades cuya decisión de que no estén incluidas
dependen de acuerdos con los solicitantes y que conceptualmente podrían incluirse. De
esta forma nos aseguramos de no ampliar el tamaño del producto sin necesidad.
c) Beneficios / Objetivos relevantes de tener el producto operativo.

Cuando el producto esté operando, qué beneficios brindará? Enumerar los objetivos con
mayor nivel de detalle.
d) Metas de cumplimiento.
Fecha
Detalle
En muchos casos, cuando surge una solicitud de desarrollo, la misma ya tiene definida
una o varias fechas en las que habrá que tener determinados resultados. Esta sección es
para definir las restricciones a los tiempos de desarrollo que plantea el solicitante a fin
de evaluar su factibilidad y asignar los recursos necesarios para cumplirlas o evaluar
otras alternativas.
Documento: Visión y Alcance
Proyecto:
Archivo:
420317046.doc
Versión:
Fecha:
Página:
1
//
3 de 7
1.3 Definiciones, siglas y abreviaturas
Termino: Definición.
...
Todo término utilizado en este documento que pertenezca al dominio de aplicación será
conveniente documentarlo y definirlo a fin de eliminar ambigüedades y malos
entendidos. Incluso en muchos casos en la definición de un término se utilizan términos
que también debe ser definidos. Es importante tener presente en todo momento, durante
el armado de este documento, que todo término perteneciente al dominio debe ser
incorporado aquí.
1.4 Referencias
Título y Código
Fecha y fuente de obtención
Ubicación
Todo documento que haya sido utilizado para estas etapas debe ser incorporado en la
tabla anterior y adjunto como información adicional a este documento.
2. Descripción global
Esta sección del SRS debe describir los factores generales que afectan al producto y sus
requisitos, es decir el contexto del negocio en el que el producto se va a desarrollar y
cómo va a intervenir en él. No declara los requisitos o funcionalidades específicas, en
cambio, posee descripciones generales que permitirán una mejor comprensión de las
mismas que estarán detalladas en la sección 2.2.
2.1 Perspectiva del producto
Esta subdivisión del SRS debe poner el producto en la perspectiva con otros productos
relacionados. Si el producto es independiente y totalmente autónomo, debe declararse
que así es. Si el SRS define un producto que es un componente de un sistema más
grande, como frecuentemente ocurre, entonces esta subdivisión debe relacionar los
requisitos de ese sistema más grande a la funcionalidad del software y debe identificar
las interfaces entre ese sistema y el software a desarrollar. Una alternativa es presentar
un diagrama del bloque que muestra los componentes mayores del sistema con las
interfaces entre sus módulos, incluyendo el que se está definiendo.
2.2 Funciones y prestaciones funcionales del producto
Documento: Visión y Alcance
Proyecto:
Archivo:
420317046.doc
Versión:
Fecha:
Página:
1
//
4 de 7
Esta subdivisión del SRS debe proporcionar un resumen de las funciones principales
que el software realizará.
A veces el resumen de las funciones de esta parte puede tomarse directamente de la
sección de la especificación en el nivel superior (si existe) eso asigna las funciones
particulares al producto del software. Si es la sección anterior no existe, es fuertemente
recomendable tener un punteo de las funciones principales.
Las funciones deben organizarse en cierto modo a fin de lograr que sea entendible por el
cliente o cualquiera leyendo el documento la primera vez.
Pueden usarse los métodos textuales o gráficos para mostrar las distintas funciones y sus
relaciones. No se espera que el diagrama muestre un diseño del producto, sino
simplemente la relación lógica entre las componentes.
2.3 Características de los usuarios
Hay x perfiles de usuarios:
Nombre: (Nombre del perfil)
Descripción:
...
El producto puede tener uno o más perfiles diferentes de usuarios, cada uno de ellos
debe estar indicado aquí con una descripción que lo caracteriza y permite determinar a
grandes rasgos las capacidades que tendrá dicho perfil en el sistema.
2.4 Restricciones
Los siguientes puntos están presentes para clasificar los diferentes tipos de restricciones
y/o características que puede poseer el producto que se está especificando. Es
importante para cada uno de ellos indicar la/s restricciones existentes o un texto
informando que no existen restricciones o características particulares para esta
categoría. También se pueden agregar aquí todas aquellas características no funcionales
que le correspondan a esta especificación aunque no estén enumeradas a continuación.
2.4.1 Restricciones del entorno
a) las limitaciones del Hardware (incluyendo memoria principal y secundaria)
Toda característica que deba ser conocida a los efectos de que el producto interactúe
adecuadamente con el hardware.
b) las limitaciones del Software de Base (incluyendo portabilidad)
Características que hay que tener en cuenta con respecto a la especificación que se está
desarrollando relacionada con respecto a la plataforma de producción para su correcto
funcionamiento.
Documento: Visión y Alcance
Proyecto:
Archivo:
420317046.doc
Versión:
Fecha:
Página:
1
//
5 de 7
c) los requisitos del lenguaje, base de datos y entorno de desarrollo
En algunos casos existen definiciones referidas al entorno de desarrollo y programación
a utilizar. Lo mismo ocurre con el motor de la base de datos y/o el sistema operativo.
Este punto es para identificar esas definiciones, si existen y de lo contrario indicar las
alternativas que se están evaluando.
d) las Interfaces con otras aplicaciones
Características que hay que tener en cuenta con respecto a la especificación que se está
desarrollando relacionada con otros sistemas externos, por ejemplo medios y formas de
comunicación.
e) los protocolos de comunicación (por ejemplo, HTML, XML, CVS)
Protocolos de comunicación intervinientes que no estén indicados y especificados en el
punto anterior.
f) las interfaces del Usuario
Características generales con respecto a la interfaz del usuario que se deberán tener en
cuenta en todo el producto. Tanto elementos puntuales de determinados requerimientos
como cuestiones generales.
g) las políticas reguladoras
Reglamentaciones que condicionen el desarrollo que se está definiendo a nivel
Nacional, del Ministerio, de la Secretaría o de alguna entidad con ingerencia en los
productos que se desarrollan. SIGEN, ONTI, etc.
h) los requisitos de adaptación del Site
Características que hay que tener en cuenta con respecto a la especificación del sitio en
el que se instalará el producto.
2.4.2 Atributos de Seguridad
Se deben especificar los factores que protegen el software del acceso accidental o
malévolo, uso, modificación, destrucción o descubrimiento.
a) los requisitos de Fiabilidad
b) Criticidad de la aplicación
Documento: Visión y Alcance
Proyecto:
Archivo:
420317046.doc
Versión:
Fecha:
Página:
1
//
6 de 7
c) la seguridad y consideraciones de seguridad
d) las funciones de Auditoria
2.4.3 Características del Capacidad y Rendimiento
a) Requisitos de tiempos de respuesta requeridos
Se deben definir aquí todas las características que se deban cumplir referentes a
velocidades de procesamiento y tiempos de respuesta del sistema frente al usuario.
b) Volúmenes de información y transacciones a administrar por el sistema
Si existe conocimiento sobre el volumen de información a administrar y/o la cantidad de
transacciones / operaciones a las que será sometido el sistema deben ser expresado en
este punto.
2.4.4 Otros requerimientos No Funcionales
a) modos y períodos de funcionamiento
Períodos de actividad del producto. Horarios en los que debe estar operativo. Forma y
necesidades de resguardo. Especificación de los distintos modos de operación, si los
hubiere.
b) el funcionamiento Paralelo
Modo de implantación del sistema. Política de migración, tanto de datos como de
procesos. Períodos de funcionamiento en paralelo si se lo considera necesario.
2.5 Asunciones y dependencias
Se deben informar aquí todas las suposiciones que se toman a fin de poder determinar
en el futuro las condiciones necesarias para el correcto funcionamiento del producto. De
esta forma, si la suposición no se cumple, se podrá determinar las consecuencias que
afectarán al mismo.
2.6 Requisitos a futuro
Documento: Visión y Alcance
Proyecto:
Archivo:
420317046.doc
Versión:
Fecha:
Página:
1
//
7 de 7
Características que pueden quedar delineadas para futuras versiones. Este punto no es
para determinar el orden cronológico de los requisitos planteados sino para enumerar
aquellos requisitos que aparecieron en esta etapa de definición, que se consideran muy
interesantes pero que ya se determinó que no deberán ser resueltos por el producto en
sus versiones a corto y mediano plazo. Pueden estar aquí definidos los puntos que se
enumeraron en el ítem 1.2.b como así otros adicionales que no son tan obvios dentro
del contexto del problema pero que a futuro pueden implicar un crecimiento interesante.