JUAN GUILLERMO CARVAJAL PATIÑO - 257299TATIANA FRANCO VILLAMIZAR - 257311DIANA CAROLINA MARTINEZ ZAMBRANO - 257328

INTRODUCCIÓN DEFINICIONES PRELIMINARES CONSIDERACIONES PARA PRODUCIR UN

BUEN SRS PARTES DE UN SRS ANEXOS

QUÉ ES SRS? QUÉ VENTAJAS TIENE?

CONTRATO CLIENTE PROVEEDOR USUARIO

NATURALEZA DEL SRS

Funcionalidad ¿Qué se supone va hacer el software?

Las interfaces Externas.

¿Cómo el software actúa recíprocamente con las personas, el hardware de los sistemas, otro hardware, y otro software?

La Actuación.

¿Cuál es la velocidad, la disponibilidad, tiempo de la contestación, tiempo de la recuperación de varias funciones del software, etc.?

Los Atributos.

¿Qué portabilidad tiene, exactitud, el mantenimiento, la seguridad, las consideraciones, etc.?

Las restricciones del diseño que impusieron en una aplicación.

¿Hay algún requerimiento Standard, idioma de aplicación, las políticas para laintegridad del banco de datos, los límites de los recursos, operando en que ambiente (s), etc.?

AMBIENTE DEL SRS Debe definir todos los requisitos del

software correctamente. No debe describir cualquier plan o detalles

de aplicación. No debe imponer las restricciones

adicionales en el software.

CARACTERÍSTICAS DEL SRS

Comprobable

Correcto

Consistente

Delinear que tieneimportancia

y/o estabilidad

Completo

Inequívoco

Modificable

Identificable

SRS

MODIFICABLENo redundante (es decir, el

mismo requisito no debeaparecer en más de un

lugar en el SRS).

Cada requisito debeexpresarse separadamente ,en lugar de intercalarlas con

otros requisitos .

Coherente y fácil de usaren la organización de

volúmenes de información,un índice y las referencias

cruzadas explícitas

MODIFICABLENo redundante (es decir, el

mismo requisito no debeaparecer en más de un

lugar en el SRS).

Cada requisito debeexpresarse separadamente ,en lugar de intercalarlas con

otros requisitos .

Coherente y fácil de usaren la organización de

volúmenes de información,un índice y las referencias

cruzadas explícitas

IDENTIFICABLE

DIRIGIDO HACIA ATRÁS DELANTERO

PREPARACIÓN CONJUNTA DEL SRS

Clientes

J untos un buenescrito y

completamenteentendible SRS

No entienden bien el diseño delsoftware y proceso de

desarrollo bastante bien comopara escribir un SRS utilizable.

Proveedores

No entienden bien el problemade los clientes y campo

de acción para que especifiquelos requisitos para un sistema

satisfactorio.

Clientes

J untos un buenescrito y

completamenteentendible SRS

No entienden bien el diseño delsoftware y proceso de

desarrollo bastante bien comopara escribir un SRS utilizable.

Proveedores

No entienden bien el problemade los clientes y campo

de acción para que especifiquelos requisitos para un sistema

satisfactorio.

EVOLUCIÓN DEL SRS

Evolución de SRS

Deben especificarse los requisitos

completamente

Un proceso de cambio formal

debe comenzarse para identificar el

control

PROTOTIPOS El cliente puede ver el prototipo y

reaccionar a este.

El prototipo despliega aspectos que se anticipan a la conducta de los sistemas.

Un SRS basado en un prototipo tiende a sufrir menos cambios durante el desarrollo.

GENERACIÓN DEL DISEÑO DEL SRS Un diseño describe un subcomponente

particular de un sistema y/o sus interfaces con otros subcomponentes.

REQUISITOS DEL PLAN NECESARIOS En casos especiales, algunos requisitos

pueden restringir el plan severamente. Por ejemplo, seguridad o requisitos de seguridad pueden verse reflejados directamente en el plan.

REQUISITOS DEL PROYECTO GENERADOS EN EL SRS

Tabla de Contenido 1. Introducción 1.1 Propósito 1.2 Alcance 1.3 Definiciones, siglas, y abreviaciones 1.4 Referencias 1.5 Apreciación global

2. Descripción global 2.1 Perspectiva del producto 2.2 Funciones del producto 2.3 Características del usuario 2.4 Restricciones 2.5 Atención y dependencias 2.6. Repartir proporcionalmente los

requisitos

3. Los requisitos específicos Apéndices Índice

Deben declararse los requisitos específicos de conformidad con todas las características descritas en la sección de “características del usuario”.

Los requisitos específicos deben tener referencias cruzadas a documentos más actuales que los relacionen.

  Todos los requisitos deben ser singularmente

identificables.  Debe prestarse la atención necesaria para

organizar los requisitos, de manera que se aumente al máximo la legibilidad.

Aceptación de las normas El formato de reporte Los nombres de los datos Los procedimientos de contabilidad Los lineamientos de la Auditoría

Aceptación de las normas El formato de reporte Los nombres de los datos Los procedimientos de contabilidad Los lineamientos de la Auditoría

Fiabilidad Disponibilidad Seguridad Mantenimiento Portabilidad

Fiabilidad Disponibilidad Seguridad Mantenimiento Portabilidad

• Modo del sistema• Clases de usuario• Objetos• Característica• Estímulo• Respuesta• Jerarquía Funcional

Modo del sistema: Algunos sistemas se comportan de diferente manera dependiendo del modo de operación.

Clases de usuario: Algunos sistemas proporcionan diferentes conjuntos de funciones a las diferentes clases de usuario.

Objetos: Son entidades del mundo real que tienen una contraparte dentro del sistema.

Característica: Una característica es un servicio externo deseado por el sistema.

Estímulo: Algunos sistemas pueden organizarse mejor describiendo sus funciones en términos de estímulos.

Respuesta: Algunos sistemas pueden organizarse mejor describiendo todas las funciones en soporte a la generación de una respuesta.

Jerarquía funcional: La funcionalidad global puede organizarse en una jerarquía de funciones organizadas por cualquier entrada común, salida común o el acceso a datos internos comunes.

Comentarios adicionales: Hay muchas anotaciones, métodos y herramientas de apoyo disponibles para ayudar en la documentación de requisitos.

Tablas de contenido e índices

Apéndices

Tablas de contenido e índices

Apéndices

FORMATO