Professional Documents
Culture Documents
Propuesta de Proyecto
y Especificacin de
Requisitos de Software
Proyecto: [Insertar Nombre de Proyecto]
Revisin: [01]
[Seleccionar fecha]
Contenido
FICHA DEL DOCUMENTO .............................................................................................................................. 3
1. INTRODUCCIN ....................................................................................................................................... 4
2
Especificacin de Requisitos, estndar de IEEE 830
Integrantes:
Nombre Integrante del Equipo Rol Definido
3
Especificacin de Requisitos, estndar de IEEE 830
1. Introduccin
En esta seccin se proporcionar una introduccin a todo el documento de Especificacin de
Requisitos Software (ERS). Consta de varias subsecciones: propsito, mbito del sistema,
definiciones, referencias y visin general del documento.
1.1. Propsito
En esta subseccin se definir el propsito del documento ERS y se especificar a quin va dirigido
el documento
Se describirn los beneficios, objetivos y metas que se espera alcanzar con el futuro
sistema.
1.4. Referencias
En esta subseccin se mostrar una lista completa de todos los documentos referenciados en la
ERS.
4
Especificacin de Requisitos, estndar de IEEE 830
2. Descripcin General
En esta seccin se describen todos aquellos factores que afectan al producto y a sus requisitos. No
se describen los requisitos, sino su contexto. Esto permitir definir con detalle los requisitos en la
seccin 3, haciendo que sean ms fciles de entender.
Normalmente, esta seccin consta de las siguientes subsecciones: Perspectiva del producto,
funciones del producto, caractersticas de los usuarios, restricciones, factores que se asumen y
futuros requisitos.
2.4. Restricciones
Esta subseccin describir aquellas limitaciones que se imponen sobre los desarrolladores del
producto:
Polticas de la empresa.
Operaciones paralelas.
5
Especificacin de Requisitos, estndar de IEEE 830
Funciones de auditora.
Funciones de control.
Lenguaje(s) de programacin.
Protocolos de comunicacin.
Requisitos de habilidad.
Criticidad de la aplicacin.
6
Especificacin de Requisitos, estndar de IEEE 830
3. Requisitos Especficos
Esta seccin contiene los requisitos a un nivel de detalle suficiente como para permitir a los
diseadores disear un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas
planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo
requisito aqu especificado describir comportamientos externos del sistema, perceptibles por
parte de los usuarios, operadores y otros sistemas. Esta es la seccin ms larga e importante de la
ERS. Debern aplicarse los siguientes principios:
Todo requisito deber ser unvocamente identificable mediante algn cdigo o sistema de
numeracin adecuado.
Lo ideal, aunque en la prctica no siempre realizable, es que los requisitos posean las
siguientes caractersticas:
Correccin: La ERS es correcta si y slo si todo requisito que figura aqu (y que ser
implementado en el sistema) refleja alguna necesidad real. La correccin de la ERS implica
que el sistema implementado ser el sistema deseado.
No ambiguos: Cada requisito tiene una sola interpretacin. Para eliminar la ambigedad
inherente a los requisitos expresados en lenguaje natural, se debern utilizar grficos o
notaciones formales. En el caso de utilizar trminos que, habitualmente, poseen ms de
una interpretacin, se definirn con precisin en el glosario.
Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir
todas las posibles respuestas del sistema a los datos de entrada, tanto vlidos como no
vlidos.
Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos
contradictorio no es implementable.
Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los
requisitos pueden clasificarse por importancia (esenciales, condicionales u opcionales) o
por estabilidad (cambios que se espera que afecten al requisito). Esto sirve, ante todo,
para no emplear excesivos recursos en implementar requisitos no esenciales.
Verificables: La ERS es verificable si y slo si todos sus requisitos son verificables. Un
requisito es verificable (testeable) si existe un proceso finito y no costoso para demostrar
que el sistema cumple con el requisito. Un requisito ambiguo no es, en general,
verificable. Expresiones como a veces, bien, adecuado, etc. Introducen ambigedad en los
requisitos. Requisitos como en caso de accidente la nube txica no se extender ms all
de 25Km" no es verificable por el alto costo que conlleva.
7
Especificacin de Requisitos, estndar de IEEE 830
En ellas se incluye:
8
Especificacin de Requisitos, estndar de IEEE 830
3.3.2 Seguridad
Garantizar la confiabilidad, la seguridad y el desempeo del sistema informtico a los diferentes
usuarios. En este sentido la informacin almacenada o registros realizados podrn ser consultados
y actualizados permanente y simultneamente, sin que se afecte el tiempo de respuesta.
Garantizar la seguridad del sistema con respecto a la informacin y datos que se manejan tales sean
documentos, archivos y contraseas.
3.3.3 Fiabilidad
El sistema debe tener una interfaz de uso intuitiva y sencilla.
9
Especificacin de Requisitos, estndar de IEEE 830
3.3.4 Disponibilidad
La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios de 7 das
por 24 horas, garantizando un esquema adecuado que permita la posible falla en cualquiera de sus
componentes, contar con una contingencia, generacin de alarmas.
3.3.5 Mantenibilidad
El sistema debe disponer de una documentacin fcilmente actualizable que permita realizar
operaciones de mantenimiento con el menor esfuerzo posible
La interfaz debe estar complementada con un buen sistema de ayuda (la administracin puede
recaer en personal con poca experiencia en el uso de aplicaciones informticas).
Se debe realizar las tareas de mantenimiento a cargo de un tcnico analista, el cual debe generar
estadsticas de accesos semanales y mensuales.
3.3.6 Portabilidad
El sistema ser implantado bajo la plataforma de Windows.
Propiedad Intelectual: El costo de licencia de producto ser valorado por el nmero de usuarios
que se conecten.
4. Propuesta de Planificacin
[Insertar una descripcin de cmo se abordar el trabajo en cuanto a los das totales estimados y
las personas involucradas en su ejecucin, las buenas prcticas y condiciones necesarias a
considerar para implementar para su buen trmino]
10
Especificacin de Requisitos, estndar de IEEE 830
PROYECTO
DOCUMENTO DE ESPECIFICACIONES
SISTEMA PROBADO
REQUISITOS DE DISEO
INTEGRAL
FUNCIONALES GRFICO
DOCUMENTO DE ESPECIFICACIONES
SISTEMA
REQUISITOS DE DISEO
CERTIFICADO
TCNICOS FUNCIONAL
01-jun
02-jun
03-jun
04-jun
05-jun
06-jun
07-jun
08-jun
09-jun
10-jun
11-jun
12-jun
Id Nombre de Tarea
1 Definicin De Caso
2 Entrevista
3 Situacin Actual
4 Entrega Documento Factibilidad
5 Modelo de Negocio
6 Modelo de Requisitos
7 Entrega Documento
8 Entrevista 2
9 Modelo de Anlisis
10 Modelo De Diseo
11 Entrega Documento
12 Entrevista 3
13 Prototipo Inicial
14 Validacin Prototipo
15 Implementacin
16 Prueba por Secciones
17 Validacin
18 Prueba Final
19 Entrega Software
11
Especificacin de Requisitos, estndar de IEEE 830
[OBS.
Crear una tabla resumen extrada del EDT de clculo de esfuerzo que desglose los principales
costos asociados al proyecto: en base a la Hora hombre y roles profesionales definidos
12
Especificacin de Requisitos, estndar de IEEE 830
[ Obs.
Insertar Descripcin de los aspectos del desarrollo en los que se permitir aplicar cambios como
parte del Desarrollo del Software definiendo sus alcances y limitaciones asociadas.
El control de cambios es una actividad paralela al desarrollo del proyecto que responde a eventos
que surgen del mismo, sea por requerimientos propios del usuario o por mejoras o correcciones
detectadas por el mismo equipo del proyecto.
Se describe de manera independiente de las dems fases de la metodologa pues puede ser
aplicada indistintamente a proyectos en marcha o proyectos ya implementados, y porque es
necesario resaltar su importancia y no relegarla como una actividad posterior al desarrollo, sino
reconocerla como una actividad que debe estar definida, presente y es crtica desde el inicio del
proyecto. Deber describir que tipo aspectos Funcionalidades y no funcionales se podrn modificar
con cambio, en que instancia de proyecto se podrn aplicar y que motivos los validaran para ser
aplicables y en qu caso no ser posible aplicar cambios.
Luego esto se debe complementar con la observacin de que en el anexo encontrarn la Planilla
de Control de Cambio con los Tipos de Cambio que podrn aplicarse en la cual posteriormente se
debe completar la planilla al ejecutarse la instancia. ]
5. Anexos
13
Especificacin de Requisitos, estndar de IEEE 830
14