SRS
El SRS es una especificación para un producto de software en particular, ya sea un sólo programaa, o un conjunto de programas, que realicen ciertas funciones en un ambiente específico
NATURALEZA DEL SRS
Frecuentemente, el usuario sólo conoce las necesidades pero no el tipo de solución más conveniente. El SRS puede escribirse por uno o más representantes del proveedor, uno o más del cliente, o por ambos Lo más recomendable es que haya representantes de ambas partes
El usuario/cliente puede redactar un borrador inicial y después revisarlo con el proveedor
-Funcionalidades deseadas
-Interfaces externas
-Desempeño
Atributos (seguridad, portabilidad, mantenibilidad, etc.)
Restricciones de diseño impuestas a la implementación (estándares técnicos propios o internacionales, lenguaje de progr., sistema operativo, límites de recursos, políticas internas).
AMBIENTE DEL SRS
El SRS es la fuente principal para hacer el plan detallado de un proyecto de software
Un SRS puede referirse a los requerimientos deseados de todos los componentes de un sistema grande, o a componentes (módulos) individuales del mismo. Si se hacen SRS por separado para varios módulos, tiene que mantenerse la consistencia en los documentos. Si un software necesita interactuar con otro, tienen que especificarse los requerimientos de esa interacción (interfaces), definiendo sus funcionalidades y el nivel de desempeño deseado.
lunes, 25 de agosto de 2008
domingo, 24 de agosto de 2008
Antes de empesasr
Para definir los requerimientos de un software, podemos apoyarnos en una norma que nos guía
para hacer las preguntas pertinentes: IEEE 830
Esta norma le sirve tanto al usuario/cliente como al desarrollador
Un cliente describa claramente lo que quiere
Un proveedor entienda claramente lo que el cliente quiere
Se establezcan bases para un contrato de desarrollo (o de compra-venta)
Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos)
Se tenga una base o referencia para validar o probar el software solicitado
Se facilite el traspaso del software a otros clientes/usuarios
Se le puedan hacer mejoras (o innovaciones) a ese software
Para definir los requerimientos de un software, podemos apoyarnos en una norma que nos guía
para hacer las preguntas pertinentes: IEEE 830
Esta norma le sirve tanto al usuario/cliente como al desarrollador
Un cliente describa claramente lo que quiere
Un proveedor entienda claramente lo que el cliente quiere
Se establezcan bases para un contrato de desarrollo (o de compra-venta)
Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos)
Se tenga una base o referencia para validar o probar el software solicitado
Se facilite el traspaso del software a otros clientes/usuarios
Se le puedan hacer mejoras (o innovaciones) a ese software
Suscribirse a:
Comentarios (Atom)