Especificación de los requisitos según la norma IEEE 830

Instituto Tecnológico de Oaxaca Alumna: CITLALI BELEN JIMÉNEZ JERONIMO Docente: DÍAZ SARMIENTO BIBIANA Carrera: ING. EN SISTEMAS COMPUTACIONALES

24/02/2024

ESPECIFICACIÓN DE REQUISITOS SEGUN EL ESTÁNDAR IEEE 830

índice

Conclusión

Introducción

Referencias

Estámdar IEEE 830

Definiciones

Consideraciones para producir un buen SRS

Partes de un SRS

introducción

En el área de desarrollo de software el estándar IEEE 830 que describen cuales son las especificaciones de requisitos de un software las cuales cumplen con un papel muy importante en el proceso de crear sistemas informáticos efectivos y funcionales, ya que este es un medio por el cual se plasman las necesidades del cliente y el desarrollador, donde se establecerán las funcionalidades que debe tener el software, como debe comportarse y cuales son los criterios de calidad que debe de cumplir.por lo tanto en la siguiente presentación describiremos lo que necesitamos para crear un buen SRS y que partes lo comforman.

Estándar IEEE 830

Según IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga estrictamente la organización y el formato dados en el estándar 830, sí deberá incluir, de una forma o de otra, toda la información presentada en dicho estándar

DEFINICIONES

Contrato

Proveedor

Usuario

Cliente

Un documento es legalmente obligatorio y en el estarán de acuerdo las partes del cliente y proveedor. Esto incluye los requisitos técnicos y requerimientos de la organización, costo y tiempo para un producto.

La persona (s) que pagan por el producto y normalmente (pero no necesariamente) definen los requisitos. En la práctica el cliente y el proveedor pueden ser miembros de la misma organización.

La persona (s) que operan o actúan recíprocamente directamente con el producto. El usuario (s) y el cliente (s) no es (son) a menudo las mismas persona(s).

La persona (s1) que producen un producto para un cliente.

01

Consideraciones para producir un buen SRS

Naturaleza del Srs

El SRS puede escribirse por uno o más representantes del proveedor, uno o más representantes del cliente, o por ambos. Los problemas básicos que se presentan al escribir un SRS van dirigidos a lo siguiente:

Las interfaces Externas

La Funcionalidad

La Actuación

¿Qué se supone va hacer el software ?

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

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

Restricciones del diseño que se impone en una aplicación

Los Atributos

¿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.?

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

Ambiente

El software puede contener toda la funcionalidad del proyecto esencialmente o puede ser parte de un sistema más grande. En el último caso habrá un SRS que declarará las interfaces entre el sistema y su software modular, y pondrá que función externa y requisitos de funcionalidad tiene con el software modular. El SRS debe tener el cuidado para no ir más allá de los límites de ese papel. Esto significa que:

Un requisito del software puede existir debido a la naturaleza de la tarea a ser resuelta o debido a una característica especial del proyecto.

Debe definir todos los requisitos del software correctamente.

Éstos deben describirse en la fase del diseño del proyecto.

No debe describir cualquier plan o detalles de aplicación

Éstos se especifican propiamente en otros documentos.

No debe imponer las restricciones adicionales en el software.

CARACTERÍSTICAS

Clasificado

Corrección

Verificable

Sin ambiguedad

Modificable

Completa

Consistente

Trazable

preparación de los joins

Clientes normalmente no entienden bien el diseño del software y proceso de desarrollo bastante bien como para escribir un SRS utilizable.

El proceso de desarrollo de software debe empezar con el proveedor y con el acuerdo del cliente en lo que el software completado debe hacer. Este acuerdo, en la forma de un SRS, debe prepararse juntamente.

Los Proveedores normalmente no entienden bien el problema de los clientes y campo de acción bastante bien como para que especifique los requisitos para un sistema satisfactorio..

evolución de srs

Deben especificarse los requisitos completamente como se es conocido en el momento, aun cuando las revisiones evolutivas pueden preverse como inevitable. El hecho que ellos están incompletos debe ser anotado.

El SRS puede necesitar evolucionar así como el desarrollo de las actualizaciones del producto de software. Puede ser imposible de especificar un poco a detalle en el momento que el proyecto se inicia Los cambios adicionales pueden suceder según como las deficiencias se vayan descubriendo, las limitaciones e inexactitudes en el SRS.

Un proceso de cambio formal debe comenzarse para identificarse, el control, dejar huella e informe de lo que proyectaron los cambios.

Prototipos

Los prototipos frecuentemente se usan durante una fase de los requisitos de un proyecto. Un prototipo debe usarse como una manera de sacar los requisitos del software, otros requisitos pueden ser inferidos ejecutando los experimentos con el prototipo.

El prototipo proporciona la regeneración rápida

Se acorta el tiempo de desarrollo.

Ayuda a ver el alcance en el SRS.

El cliente puede ver el prototipo y reaccionar a él que leer el SRS y reaccionar a él.

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

El prototipo despliega aspectos de anticiparse a la conducta de los sistemas.

requisitos del proyecto generados en el srs

generando l diseño en el srs

Los requisitos del proyecto representan una comprensión entre el cliente y el proveedor sobre materias contractuales que pertenecen a la producción de software y así no deben ser incluidos en el SRS. Éstos normalmente incluyen los puntos como:

• El Costo
• Los tiempos de la entrega
• Informando los procedimientos
• Los métodos de desarrollo de Software
• La convicción de Calidad
• La Aprobación y criterio de la comprobación
• Los procedimientos de aceptación

Un requisito especifica una función externa visible o atributo de un sistema. Un diseño describe un subcomponente particular de un sistema y/o sus interfaces con otros subcomponentes. El diseñador del SRS debe distinguir claramente entre identificar las restricciones del diseño requeridos y proyectar un plan específico.

02

partes de un srs

Introducción

Próposito

Introducción

Ámbito del sistema

• Se le da un nombre al sistema
• Explica lo que hará y no hará el sistema.
• Se describirán los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema.

• Se referenciarán todos aquellos documentos de nivel superior

En esta sección se proporcionará una introducción a todo el documento de (ERS). Consta de varias subsecciones: propósito, ambito del sistema, definiciones, referencias y visión general del documento.

En esta subsección se definirá el propósito del documento ERS y se especificará a quién va dirigido el documento.

Visión General del Documento

Referencias

Definiciones, Acrónimos y Abreviaturas

Esta subsección describe brevemente los contenidos y la organización del resto de la ERS

En esta subsección se mostrará una lista completa de todos los documentos referenciados en la ERS.

En esta subsección se definirán todos los términos, acrónimos y abreviaturas utilizadas en la ERS

Descripción General

En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permitirá definir con detalle los requisitos específicos , haciendo que sean más fáciles de entender

Prespectiva del Producto

Funciones del Producto

Se debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalemente independiente de otros productos, también debe especificarse aqué. Si la ERS define un producto que es parte de un sistema mayor, esta subsección relacionará los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identificarán las interfaces entre el producto mayor y el producto aquí descrito.

En esta subsección de la ERS se mostrará un resumen, a grandes rasgos, de las funciones del futuro sistema. Las funciones deberán mostrarse de forma organizada, y pueden utilizarse gráficos, siempre y cuando dichos gráficos reflejen las relaciones entren funciones y no el diseño del sistema.

características de los usuarios

Suposiciones y Dependencias

Esta subsección describirá las características generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia técnica.

la ERS describirá aquellos factores que, si cambian, pueden afectar a los requisitos.

restricciones

REquisitos futuros

• Políticas de la empresa
• Limitaciones del hardware
• Interfaces con otras aplicaciones
• Operaciones paralelas
• Funciones de auditoría
• Funciones de control
• Lenguaje(s) de programacion
• Protocolos de comunicación
• Requisitos de habilidad
• Criticalidad de la aplicación
• Consideraciones acerca de la seguridad

Esta subsección esbozará futuras mejoras al sistema, que podrán analizarse e implementarse en un futuro.

Requerimientos especificos

principios

El documento debería ser perfectamente legible por personas de muy distintas formaciones e intereses.

Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos.

Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos.

Todo requisito deberá ser unívocamente identificable mediante algún código o sistema de numeración adecuado.

Características de la diapositiva 11

Interfaces internas

funciones

Se describirán los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e interfaces de comunicaciones.

Esta subsección deberá especificar todas aquellas acciones (funciones) que deberá llevar a cabo el software.

formas de organizar

Por tipos de usuario

Por estímulos

Por objetos

Por jerarquía funcional

Por objetivos

Todo aquello que restrinja las decisiones relativas al diseño de la aplicación: Restricciones de otros estándares, limitaciones del hardware, etc

Restricciones de Diseño

Requisitos de Rendimiento

Se detallar´an los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultaneamente conectados,etc. También, si es necesario, se especificarán lo requisitos de datos, es decir, aquellos requisitos que afecten a la información que se guardará en la base de datos.

Se detallarán los atributos de calidad del sistema: Deberá especificarse qué tipos de usuario están autorizados, o no, a realizar ciertas tareas, y cómo se implementarán los mecanismos de seguridad

Atributos del Sistema

Cualquier otro requisito que no encaje en otra sección.

Otros Requisitos

Apendice

Pueden contener todo tipo de información relevante para la ERS pero que, propiamente, no forme parte de la ERS. Por ejemplo:

• Formatos de entrada/salida de datos, por pantalla o en listados.
• Resultados de análisis de costes.
• Restricciones acerca del lenguaje de programación

Conclusión

Como conclusión puedo decir que los requsitos de software son una herramienta que nos ayuda a desarrollar un sistema eficiente y sobre todo exitoso, ya que sin unas especificaciones de requisitos adecuadas y bien definidas, un proyecto de software corre riesgo de sufrir problemas que afectaran el resultado esperado. Por lo tanto es importante dedicar tiempo y esfuerzo en la elaboración de estas especificaciones para obtener un éxito a largo plazo de cualquier proyecto de desarrollo de software.

Referencias

1. Luis, B. G. J. (2015). Desarrollo de aplicaciones web en el entorno servidor. Ediciones Paraninfo, S.A.
2. https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
3. https://www.ctr.unican.es/asignaturas/is1/ieee830_esp.pdf