Documento

Solo disponible en BuenasTareas
  • Páginas : 25 (6160 palabras )
  • Descarga(s) : 0
  • Publicado : 28 de noviembre de 2010
Leer documento completo
Vista previa del texto
INGENIERIA DE SOFTWARE I

GUIA No 2

La Especificación de Requerimientos de Software
Alan Davis
Ver 1.0

ESP. SANTIAGO ZUÑIGA SHAIK

CORPORACIÓN UNIVERSITARIA DE CIENCIA Y DESARROLLO
CALI
2004

La Especificación de Requerimientos de Software.
Alan Davis.[1]

Durante el análisis delproblema, el problema es descompuesto repetidamente hasta que es finalmente entendido completamente. Sin embargo, la fase de requerimientos de software no esta completa hasta que la especificación de requerimientos de software (SRS) no sea escrito. Este capítulo introduce el concepto de SRS, describe su contenido apropiado, explora los atributos de un SRS bien escrito, y ofrece guías sobre comoorganizar un SRS.

1. Introducción
Antes que la etapa de requerimientos de software este completa, un SRS debe ser escrito. El SRS contiene una descripción completa del comportamiento externo del sistema de software. Es posible completar el análisis del problema antes de comenzar a escribir el SRS. Sin embargo, es más común que a medida que se logra el proceso de análisis y descomposición delproblema y partes del problema son entendidas, la sección correspondiente del SRS es escrito.

El SRS sirve a un número de propósitos dependiendo de quien es el que lo escribe. Primero, el SRS puede ser escrito por un usuario potencial (o cliente) del sistema. Segundo, el SRS puede ser escrito por un desarrollador del sistema. Los dos escenarios crean situaciones enteramente diferentes y establecepropósitos enteramente diferentes para el documento. En el primer caso, el propósito primario es establecer la necesidad. Este documento algunas veces sirve de base para un proceso de selección competitiva entre compañías que desean satisfacer esa necesidad (base para la licitación). Con el fin de enfrentar la competencia (el cual ayuda potencialmente al cliente a obtener el mejor producto al menorcosto), el SRS debe ser tan general como sea posible. Veamos por ejemplo que un dueño de un edificio desea adquirir un sistema de control para un elevador. El SRS debe ser lo suficientemente general para que varias compañías de elevadores (cada una con diferente algoritmo de despacho y caminos de viaje del elevador) puedan responder, pero debe ser lo suficientemente específico para eliminarclaramente de la competencia a una compañía que ofrece rampas conectando los pisos y paradas de elefantes caminando de un piso a otro transportando gente en sus espaldas. Idealmente el SRS debe dividir el universo de sistemas en dos conjuntos independientes: un conjunto de todos los sistemas que satisfacen las necesidades reales de los usuarios y uno conteniendo todos los que no.

Por otro lado, unSRS escrito por una organización de desarrollo como primer paso para el proceso de construcción de software debe ser mucho más específico. Este tipo de SRS es materia de nuestra discusión en este capítulo, y desarrolla un conjunto enteramente diferente de funciones del también llamado SRS descrito en el párrafo anterior. Su propósito en proveer un medio de:
• Comunicación entre clientes,usuarios, analistas y diseñadores.
• Soporte a las actividades de prueba del sistema.
• Control de la evolución del sistema.

Discutamos esos tres con más detalle.

El primer propósito del SRS es proveer un medio de comunicación entre todas las partes. Un SRS bien escrito reduce la probabilidad de que un cliente se vea desilusionado con el producto final. Asumiendo que el SRS no esambiguo, define el comportamiento externo del sistema a construir, y no pueden haber malinterpretaciones. Si existe un desacuerdo entre entre el cliente y los desarrolladores concernientes al comportamiento externo, debe detectarse durante la etapa de requerimientos y no durante el proceso de entrega del software, cuando es mucho más costoso de corregir. Desafortunadamente varios desarrolladores...
tracking img