IEEE 830

EEE-STD-830-1998 : ESPECIFICACIONES DE LOS REQUISITOS DEL SOFTWARE

(Sánchez, 1998)

Definiciones

En general las definiciones de los términos usados en estas especificaciones están conforme a las definiciones proporcionadas en IEEE Std 610.12-1990.

Contrato

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. Un contrato también puede contener la información informal pero útil como los compromisos o expectativas de las partes involucradas.

Cliente

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.

Proveedor

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

Usuario

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 personas(s).

Las consideraciones para producir un buen SRS.

Estas cláusulas proporcionan información a fondo que deben ser consideradas al momento de producir un SRS. Esto incluye lo siguiente:

• La Naturaleza del SRS;
• El Ambiente del SRS;
• Las Características de un buen SRS ;
• La preparación de los Joins del SRS;
• La evolución de SRS;
• Prototipos;
• Generando el diseño en el SRS;
• Generando los requisitos del proyecto en el SRS.

(Sirse, 2012)

El estándar 830-1998 fue generado por un equipo de trabajo del IEEE, su finalidad es la integración de los requerimientos del sistema desde la perspectiva del usuario, cliente y desarrollador.

Esta ha sido nuestra propuesta durante la existencia como blog, la 830 se encarga de poner las pautas para identificar y esquemagtizar las requierimientos de software. como parte integral del disarrollo de software, sino tambien como base fundamental de este, todo esto con el fin de no caer en cambios, errores o situaciones que pongan en peligro la creacion de una solucion, producto o software; incurriendo en gastos o cambios producto de una mal analisis de requerimientos

Normas y estándares de sistemas de calidad en TI(García, 2010)

(LD, 2017)

Los principales objetivos que se identifican en la especificación de requisitos software son

•  1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software: El cliente debe participar activamente en la especificación de requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo

• 2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS permite al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena especificación de requisitos, los costes de desarrollo pueden incrementarse considerablemente, ya que se deben hacer cambios durante la creación de la aplicación. 

• 3. Servir de base para desarrollos de estándares de ERS particulares para cada organización: Cada entidad puede desarrollar sus propios estándares para definir sus necesidades. Una buena especificación de requisitos software ofrece una serie de ventajas entre las que destacan el contrato entre cliente y desarrolladores (como ya se ha indicado con anterioridad), la reducción del esfuerzo en el desarrollo, una buena base para la estimación de costes y planificación, un punto de referencia para procesos de verificación y validación, y una base para la identificación de posibles mejoras en los procesos analizados. 

(YeisonJ, 2012)

La ERS es una descripción que debe decir ciertas cosas y al mismo tiempo debe decirlas de una determinada manera. En este documento se presentará una de las formas que viene especificada por el estándar IEEE 830. Una ERS forma parte de la documentación asociada al software que se está desarrollando, por tanto debe definir correctamente todos los requerimientos, pero no más de los necesarios. Esta documentación no debería describir ningún detalle de diseño, modo de implementación o gestión del proyecto, ya que los requisitos se deben describir de forma que el usuario pueda entenderlos. Al mismo tiempo, se da una mayor flexibilidad a los desarrolladores para la implementación. Así pues, el grado y el lenguaje utilizado para la documentación de los requisitos estarán en función del nivel que el usuario tenga para entender dichas especificaciones. E78. Ingeniería del Software ERS según el estándar IEEE 830 3 3 Características de una buena ERS
Las características deseables para una buena especificación de requisitos software que se indican en el IEEE son las siguientes

• Correcta 
• No ambigua 
• Completa
• Verificable 
• Consistente 
• Clasificada 
• Modificable 
• Explorable 
• Utilizable durante las tareas de mantenimiento y uso

(YeisonJ, 2012)

Referencias

González, M. E. (16 de 07 de 2015). Academia. Obtenido de Academia: https://www.academia.edu/14127263/ISO_IEC_26514

Industrial, F. (12 de 09 de 2008). Foro Industrial. Obtenido de Foro Industrial: http://www.foro-industrial.com/2008/09/nueva-norma-isoiec-265142008-documentacion-software/

KAI WEBER, L. T. (2016). Technical-comunication. Obtenido de Technical-comunication: https://www.technical-communication.org/fileadmin/Bilder/tekom-danmark/event-downloads/2016-10-04_04_Kai_Weber_ISO26515_and_Agile_User_Documentation.pdf

Kosutic, D. (2008). Gestión de documentación ISO: una guía en un lenguaje sencillo. En D. Kosutic,Gestión de documentación ISO: una guía en un lenguaje sencillo.

LD, F. (2 de 03 de 2017). Prezi. Obtenido de Prezi: https://prezi.com/3cegqpfhoelm/isoiec-265142008/

Sirse. (06 de 05 de 2012). Obtenido de Sirse: https://www.google.com/search?biw=1366&bih=608&tbm=isch&sa=1&ei=Z02cXPigMc2osgX06Y7oDQ&q=ISO&oq=ISO&gs_l=img.3..35i39l2j0i67l2j0l6.286752.286914..287216...0.0..0.272.527.2-2......1....1..gws-wiz-img.5qGQhPPH9v4#imgrc=rOhJttDvz6v7GM:

Sites.google.com. (s.f.). Obtenido de Sites.google.com: https://sites.google.com/site/sistemascalidadti/iso-iec-26514-2008

SZ, A. (8 de 04 de 2013). Prezi. Obtenido de Prezi: https://prezi.com/u9zr2hcwxv8z/norma-isoiec265142008/

López, A. (19 de 05 de 2017). ctr-unican. Obtenido de ctr-unican: https://www.ctr.unican.es/asignaturas/is1/IEEE83

Bibliografía

García, A. (05 de 09 de 2010). ctr-unican. Obtenido de ctr-unican: https://www.ieec830.es/asignaturas/is1/IEEE830.html

Sánchez, J. (8 de Febrero de 1998). Documento de Requerimientos. Obtenido de Documento de Requerimientos: https://www.google.com/search?q=ieee+830&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjKzLv8nqThAhWEna0KHezGCjkQ_AUIDigB&biw=1366&bih=657#imgrc=6E9RCu2pJKpxRM:

chain, S. (17 de Noviembre de 2017). Business school. Obtenido de Business school: https://retos-operaciones-logistica.eae.es/que-es-la-guia-pmbok-y-como-influye-en-la-administracion-de-proyectos/

Institute, p. M. (2018). Guía de PMBOK. Newtown: GlobalStandard.

Consultoritil. (45 de 02 de 2015). Grupo Arion. Obtenido de Grupo Arión: http://www.consultoriaitil.com.mx/10.html

Morries, L. G. (2011). ITIL. Wiley Brand.