IEEE-STD-830-1998: PRÁCTICA RECOMENDADA PARA LAS

ESPECIFICACIONES DE REQUISITOS DEL SOFTWARE

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

CONTENIDO

QUÉ ES SRS? QUÉ VENTAJAS TIENE?

INTRODUCCIÓN

CONTRATO CLIENTE PROVEEDOR USUARIO

DEFINICIONES PRELIMINARES

NATURALEZA DEL SRS

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

CONSIDERACIONES PARA PRODUCIR UN BUEN SRS

CARACTERÍSTICAS DEL SRS

CONSIDERACIONES PARA PRODUCIR UN BUEN SRS

Comprobable

Correcto

Consistente

Delinear que tieneimportancia

y/o estabilidad

Completo

Inequívoco

Modificable

Identificable

SRS

CARACTERÍSTICAS DEL SRS-CORRECTO

SRS CORRECTO

• Cada requisito declarado se encuentra en el software

• El SRS refleja las necesidades actuales

CARACTERÍSTICAS DEL SRS-INEQUÍVOCO

• Revisión por una parte independiente

TRAMPAS DEL IDIOMA

NATURAL

• 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

IDIOMA DE ESPECIFICACIÓN DE REQUISITOS

• 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

REPRESENTACIÓN HECHA CON

HERRAMIENTAS

CARACTERÍSTICAS DEL SRS-COMPLETO

SRS COMPLETO

• REQUISITOS• RESPUESTAS• REFERENCIAS Y DEFINICIONES

TBD (To Be Determined)

• CAUSAS• SOLUCIONES

CARACTERÍSTICAS DEL SRS-CONSISTENTE

• Informe de Rendimiento – Tabular / Textual

• Requisito – Luces Verdes / Rojas

Choque características de los objetos del mundo real

• Requisito – Programa Suma /Multiplica• Requisito – A sigue B / A y B

simultáneos

Conflictos lógicos o

temporales

• Requisito – Entrada del usuario Sugerencia/ Señal

Los requisitos describen el

mismo objeto del mundo real

CARACTERÍSTICAS DEL SRS -IMPORTANCIA Y ESTABILIDAD

CLASES DE REQUISITOS

ESENCIALImplica que el software

no será aceptable a menos que

estos requisitos se proporciones

de una manera

convenida

CONDICIONALImplica que estos son requisitos

que reforzarian el producto

del software, pero no lo

haria inaceptable

si ellos estan ausentes

OPTATIVOImplica 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

CARACTERÍSTICAS DEL SRS - COMPROBABLE

PROCESO RENTABLE

REQUISITO

SSRS

CARACTERÍSTICAS DEL SRS - MODIFICABLE

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

CARACTERÍSTICAS DEL SRS - IDENTIFICABLE

IDENTIFICABLE

DIRIGIDO HACIA ATRÁS DELANTERO

PREPARACIÓN CONJUNTA DEL SRS

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

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

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.

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.

CONSIDERACIONES PARA PRODUCIR UN BUEN SRS

REQUISITOS DEL PROYECTO GENERADOS EN EL SRS

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

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

PARTES DE UN SRS

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.

INTRODUCCIÓN

REFERENCIAS

• Documentos referenciados en el SRS.• Especificar fuentes.

APRECIACIÓN GLOBAL

• Describir el resto del contenido del SRS.• Explicar como esta organizado el 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

PARTES DE UN SRS

DESCRIPCIÓN GLOBALPERSPECTIVA DEL PRODUCTO

INTERFACES DEL SISTEMA

Identificar la funcionalidad del software

INTERFACES DEL USUARIOEspecificar 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 HARDWAREEspecificar las características lógicas de cada interfaz entre el producto del software y los

componentes del hardware del sistema.

INTERFACES DE SOFTWAREEspecificar el uso de otros productos del software requeridos e interfaces con otros sistemas de la

aplicación.

DESCRIPCIÓN GLOBALPERSPECTIVA DEL PRODUCTO

INTERFACES DE COMUNICACIONES

Especificar las interfaces a las comunicaciones.

RESTRICCIONES DE MEMORIAEspecificar 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 SITIODefinir 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.

DESCRIPCIÓN GLOBAL

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

Funciones del

producto

• Descripción de las características generales de los usuarios intencionales del producto que incluye nivel educativo, experiencia, y la especialización técnica

Características del usuario

DESCRIPCIÓN GLOBAL

• 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

Restriccion

es

DESCRIPCIÓN GLOBAL

• 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

Atención y dependencias

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

PARTES DE UN SRS

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.

REQUISITOS ESPECÍFICOS

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

LOS REQUISITOS ESPECÍFICOS-FUNCIONES

Verificar la

validez

sobre entradas

Secuencia de

operacione

s

Respuestas a

situaciones anormales1. Overflow

2. Facilidades

de Comunicaci

ón3.Manejo de

Errores y Comunicaci

ón

Efecto de Pará

metros

Relación de salidas

a laentradas

s1.Secuenci

a entrada/sa

lidas2.

Formulas y su

conversión

LOS REQUISITOS ESPECÍFICOS-REQUISITOS DEL DESARROLLO

Requerimi

entos

estáti

cos

* Número de terminales a ser apoyadas* Número de usuarios (simultáneos) a ser apoyados* Cantidad y tipo de información a ser tratada.

Requerimi

entos

dinámico

s

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.

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

LOS REQUISITOS ESPECÍFICOS-RESTRICCIONES DEL DISEÑO

Fiabilidad Disponibilidad Seguridad Mantenimiento Portabilidad

LOS REQUISITOS ESPECÍFICOS-ATRIBUTOS DEL SOFTWARE DEL SISTEMA

LOS REQUISITOS ESPECÍFICOS-ORGANIZAR LOS REQUISITOS ESPECÍFICOS

• 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

LOS REQUISITOS ESPECÍFICOS- INFORMACIÓN DE APOYO

FORMATO

ANEXOS