La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

JUAN GUILLERMO CARVAJAL PATIÑO TATIANA FRANCO VILLAMIZAR

Presentaciones similares


Presentación del tema: "JUAN GUILLERMO CARVAJAL PATIÑO TATIANA FRANCO VILLAMIZAR"— Transcripción de la presentación:

1 IEEE-STD-830-1998: PRÁCTICA RECOMENDADA PARA LAS ESPECIFICACIONES DE REQUISITOS DEL SOFTWARE
JUAN GUILLERMO CARVAJAL PATIÑO TATIANA FRANCO VILLAMIZAR DIANA CAROLINA MARTINEZ ZAMBRANO

2 CONTENIDO INTRODUCCIÓN DEFINICIONES PRELIMINARES
CONSIDERACIONES PARA PRODUCIR UN BUEN SRS PARTES DE UN SRS ANEXOS

3 INTRODUCCIÓN QUÉ ES SRS? QUÉ VENTAJAS TIENE?

4 DEFINICIONES PRELIMINARES
CONTRATO CLIENTE PROVEEDOR USUARIO

5 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
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 la integridad del banco de datos, los límites de los recursos, operando en que ambiente (s), etc.?

6 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
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.

7 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
CARACTERÍSTICAS DEL SRS Comprobable Correcto Consistente Delinear que tiene importancia y/o estabilidad Completo Inequívoco Modificable Identificable SRS

8 CARACTERÍSTICAS DEL SRS-CORRECTO
Cada requisito declarado se encuentra en el software El SRS refleja las necesidades actuales

9 CARACTERÍSTICAS DEL SRS-INEQUÍVOCO
TRAMPAS DEL IDIOMA NATURAL Revisión por una parte independiente IDIOMA DE ESPECIFICACIÓN DE REQUISITOS Detección de errores léxicos, sintácticos y semánticos Descripción acertada de sistemas y especificaciones Largo tiempo de aprendizaje y complejos para algunos usuarios REPRESENTACIÓN HECHA CON HERRAMIENTAS Objeto: Organización de requisitos referente a objetos en el mundo real, atributos y servicios que realizados Proceso: Organización a partir las funciones que se comunican vía el flujo de datos Conductual: Descripción de la conducta del sistema externo

10 CARACTERÍSTICAS DEL SRS-COMPLETO
REQUISITOS RESPUESTAS REFERENCIAS Y DEFINICIONES TBD (To Be Determined) CAUSAS SOLUCIONES

11 CARACTERÍSTICAS DEL SRS-CONSISTENTE
Choque características de los objetos del mundo real Informe de Rendimiento – Tabular / Textual Requisito – Luces Verdes / Rojas Conflictos lógicos o temporales Requisito – Programa Suma /Multiplica Requisito – A sigue B / A y B simultáneos Los requisitos describen el mismo objeto del mundo real Requisito – Entrada del usuario Sugerencia/ Señal

12 CARACTERÍSTICAS DEL SRS -IMPORTANCIA Y ESTABILIDAD
CLASES DE REQUISITOS ESENCIAL Implica que el software no será aceptable a menos que estos requisitos se proporciones de una manera convenida CONDICIONAL Implica que estos son requisitos que reforzarian el producto del software, pero no lo haria inaceptable si ellos estan ausentes OPTATIVO Implica una clase de funciones que pueden o no pueden valer la pena. Esto le da la oportunidad de proponer algo que excede el SRS al proveedor

13 CARACTERÍSTICAS DEL SRS - COMPROBABLE
PROCESO RENTABLE REQUISITOS SRS

14 CARACTERÍSTICAS DEL SRS - MODIFICABLE

15 CARACTERÍSTICAS DEL SRS - IDENTIFICABLE
DIRIGIDO HACIA ATRÁS DELANTERO

16 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
PREPARACIÓN CONJUNTA DEL SRS

17 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
EVOLUCIÓN DEL SRS Evolución de SRS Deben especificarse los requisitos completamente Un proceso de cambio formal debe comenzarse para identificar el control

18 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
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.

19 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
GENERACIÓN DEL DISEÑO DEL SRS Un diseño describe un subcomponente particular de un sistema y/o sus interfaces con otros subcomponentes.

20 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
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.

21 CONSIDERACIONES PARA PRODUCIR UN BUEN SRS
REQUISITOS DEL PROYECTO GENERADOS EN EL SRS El costo Los tiempos de entrega Información de los procedimientos Métodos de desarrollo del software Convicción de calidad Aprobación y criterio de la comprobación Procedimientos de aceptación

22 PARTES DE UN 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

23 DEFINICIONES, SIGLAS Y ABREVIACIONES
INTRODUCCIÓN PRÓPOSITO Público ALCANCE Definir que hace y que no debe hacer el software. Describir beneficios, objetivos y metas. DEFINICIONES, SIGLAS Y ABREVIACIONES Definir términos, siglas y abreviaciones para interpretar el SRS.

24 INTRODUCCIÓN APRECIACIÓN GLOBAL REFERENCIAS
Documentos referenciados en el SRS. Especificar fuentes. APRECIACIÓN GLOBAL Describir el resto del contenido del SRS. Explicar como esta organizado el SRS.

25 PARTES DE UN SRS 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

26 DESCRIPCIÓN GLOBAL PERSPECTIVA DEL PRODUCTO INTERFACES DEL SISTEMA
Identificar la funcionalidad del software INTERFACES DEL USUARIO Especificar las características lógicas de cada interfaz entre el producto del software y sus usuarios. Todos los aspectos para perfeccionar la interfaz con la persona que debe usar el sistema. INTERFACES DE HARDWARE Especificar las características lógicas de cada interfaz entre el producto del software y los componentes del hardware del sistema. INTERFACES DE SOFTWARE Especificar el uso de otros productos del software requeridos e interfaces con otros sistemas de la aplicación.

27 DESCRIPCIÓN GLOBAL PERSPECTIVA DEL PRODUCTO
INTERFACES DE COMUNICACIONES Especificar las interfaces a las comunicaciones. RESTRICCIONES DE MEMORIA Especificar cualquier característica aplicable y límites en la memoria primaria y la memoria secundaria. FUNCIONAMIENTOS Funcionamientos normales y especiales requeridos por el usuario REQUISITOS DE ADAPTACIÓN DEL SITIO Definir los requisitos para cualquier dato o secuencia de inicialización. Especificar el sitio o los rasgos que se deben modificar para adaptar el software a una instalación particular.

28 DESCRIPCIÓN GLOBAL Funciones del producto Se organizan de modo que la lista de funciones sea entendible para el cliente o cualquiera que lea el documento por primera vez. Pueden usarse los métodos Textuales o gráficos para mostrar las funciones diferentes y sus relaciones. Características del usuario Descripción de las características generales de los usuarios intencionales del producto que incluye nivel educativo, experiencia, y la especialización técnica

29 DESCRIPCIÓN GLOBAL Las políticas reguladoras
Restricciones Las políticas reguladoras Las limitaciones del Hardware Las Interfaces a otras aplicaciones El funcionamiento Paralelo Las funciones de la Auditoría Las funciones de Control Los requisitos de lenguaje Los protocolos Señalados (por ejemplo, XON-XOFF, ACK-NACK) Los requisitos de Fiabilidad Credibilidad de la aplicación La Seguridad y consideraciones de seguridad

30 Atención y dependencias
DESCRIPCIÓN GLOBAL Atención y dependencias Estos factores no son las restricciones del diseño en el software, más bien, son cualquier cambio a ellos; eso puede afectar los requisitos en el SRS

31 PARTES DE UN SRS 3. Los requisitos específicos Apéndices Índice

32 REQUISITOS ESPECÍFICOS
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.

33 REQUISITOS ESPECÍFICOS
INTERFACES EXTERNAS Descripción detallada de todas las entradas y salidas del sistema del software. FUNCIONES Los requisitos funcionales deben definir las acciones fundamentales que deben tener lugar en el software, aceptando y procesando las entradas, procesando y generando las salidas

34 LOS REQUISITOS ESPECÍFICOS-FUNCIONES
Verificar la validez sobre entradas Secuencia de operaciones Respuestas a situaciones anormales 3.Manejo de Errores y Comunicación 2. Facilidades de Comunicación 1. Overflow Efecto de Parámetros Relación de salidas a laentradass 2. Formulas y su conversión 1.Secuencia entrada/salidas

35 LOS REQUISITOS ESPECÍFICOS-REQUISITOS DEL DESARROLLO
Requerimientos estáticos * Cantidad y tipo de información a ser tratada. * Número de usuarios (simultáneos) a ser apoyados * Número de terminales a ser apoyadas Requerimientos dinámicos * Cantidad de datos a ser procesados en cierto periodo de tiempo * Número de transacciones o tareas.

36 LOS REQUISITOS ESPECÍFICOS-REQUISITOS DEL BANCO DE DATOS LÓGICO
Tipos de Información Usada por varias funciones Frecuencia de Uso Accediendo las capacidades Entidades de los datos y sus relaciones Restricciones de integridad Requerimientos en la retención de datos.

37 LOS REQUISITOS ESPECÍFICOS-RESTRICCIONES DEL DISEÑO
Aceptación de las normas El formato de reporte Los nombres de los datos Los procedimientos de contabilidad Los lineamientos de la Auditoría

38 LOS REQUISITOS ESPECÍFICOS-ATRIBUTOS DEL SOFTWARE DEL SISTEMA
Fiabilidad Disponibilidad Seguridad Mantenimiento Portabilidad

39 LOS REQUISITOS ESPECÍFICOS-ORGANIZAR LOS REQUISITOS ESPECÍFICOS
Modo del sistema Clases de usuario Objetos Característica Estímulo Respuesta Jerarquía Funcional

40 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.

41 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.

42 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.

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

44 LOS REQUISITOS ESPECÍFICOS- INFORMACIÓN DE APOYO
Tablas de contenido e índices Apéndices

45 ANEXOS FORMATO


Descargar ppt "JUAN GUILLERMO CARVAJAL PATIÑO TATIANA FRANCO VILLAMIZAR"

Presentaciones similares


Anuncios Google