Estándares De Calidad En Ingenieria De Software Y Requerimientos 3u6w6f

Definición: Estándar de calidad Estándar de calidad es el que reúne los requisitos mínimos en busca de la excelencia dentro de una organización institucional. Autor: Pulido, Hernán Javier 2004. Estándar es aquello que sirve como tipo, modelo, norma, patrón o referencia. Autor: Real Academia Española Tipos de estándares

Estándar

Oficial

De facto

De jure

Estándar Oficial: Es una norma respaldada por un organismo oficial que define estándares Estándar de facto: Es un "estándar" (pero no oficial), pero que su penetración en el mercado es inmensa y aceptada. Estándar de jure (Oficial): Se establecen por convenio en contraposición a un establecimiento por hecho o costumbre. Son definidos por organizaciones oficiales Fuente: Evelio http://www.eveliux.com/mx/curso/estandares-y-organizaciones.html

¿Qué son y cuáles son los estándares de calidad en la ingeniería de requerimientos y en el desarrollo de software en general? En ingeniería de requisitos Existen numerosas metodologías, estándares y normas en el ámbito de la gestión de requisitos. Algunas de las normas más conocidas son: ISO 29148, ISO 15288, ISO 24766. 

ISO 29148 – Systems and software engineering – Life cycle processes – Requirements engineering: Contiene destrezas para los procesos y productos relacionados con la ingeniería de requisitos para los sistemas y productos de software y servicios a lo largo del ciclo de vida. Define la construcción de un buen requisito, proporciona atributos y características de los requisitos, y analiza la aplicación iterativa y recursiva de los procesos de requisitos

a lo largo del ciclo de vida. ISO 29148 proporciona una orientación adicional en la aplicación de los procesos de requisitos de ingeniería y gestión de las actividades de los requisitos relacionados en la norma ISO 15288. Además, define los elementos de información aplicables a la ingeniería de requisitos y su contenido. 

ISO 15288 - Systems and software engineering – System life cycle processes: Establece un marco común de procesos para describir el ciclo de vida de la Ingeniería de Sistemas. Define un conjunto de procesos y la terminología asociada desde un punto de vista de la ingeniería. Estos procesos se pueden aplicar en cualquier nivel de la estructura jerárquica de un sistema. Algunos conjuntos seleccionados de estos procesos se pueden aplicar en todo el ciclo de vida de la gestión y la realización de las etapas del ciclo de vida de un sistema. Esto se logra a través de la participación de todas las partes interesadas, con el objetivo de lograr la satisfacción del cliente.



ISO 24766 – Information technology – Systems and software engineering – Guide for requirements tool capabilities: La ingeniería de requisitos es un proceso esencial de los sistemas y los ciclos de vida del software de ingeniería. La ingeniería de requisitos se ha establecido como un proceso del ciclo de vida estándar ISO tanto en la norma ISO 15288, como en la norma ISO IEC 12207. Esta norma proporciona una orientación sobre las capacidades deseables que debería aportar una herramienta de Ingeniería de Requisitos. Normalmente la norma ISO 24766 es utilizada como complemento de la norma ISO 14102, “Information technology – Guideline for the evaluation and selection of CASE tools”

Otras normas y estándares sobre la gestión de requisitos son:  

IEEE Std 830 – IEEE Recommended Practice for Software Requirements Specifications IEEE Std 1233 – IEEE Guide for Developing System Requirements Specifications

Autor: Jose Sevilla, Consultor de ITSM & Gestión de Requisitos en OVERTI. http://www.overti.es/tecnologia/283-normas-y-estandares-para-gestion-de-requisitos

En ingeniería de Software en general ISO 12207 – Modelos de Ciclos de Vida del Software. Estándar para los procesos de ciclo de vida del software de la organización, Este estándar se concibió para aquellos interesados en adquisición de software, así como desarrolladores y proveedores. El estándar indica una serie de procesos desde la recopilación de requisitos hasta la culminación del software. El estándar comprende 17 procesos lo cuales son agrupados en tres categorías: ·

Principales

·

de apoyo

·

de organización

Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos organizativos

ISO 9000: Gestión y aseguramiento de calidad (conceptos y directrices generales). Recomendaciones externas para aseguramiento de la calidad (ISO 9001, ISO 9002, ISO 9003). ISO 9001: Sistema de calidad- Modelo de aseguramiento de la calidad en diseño/ desarrollo producción, instalación y servicio. Norma que se aplica a los sistemas de calidad (SGC), el cual se centra en todos los elementos de istración de calidad con los que una empresa debe contar, para tener un sistema efectivo que permita istrar y mejorar la calidad sus productos y servicios. La norma ISO 9001:2008 se basa en ocho principios de gestión de calidad: 1. 2. 3. 4. 5. 6.

Enfoque al cliente Liderazgo Participación del personal Enfoque basado en procesos Enfoque de sistema para la gestión Mejora continua

7. Enfoque basado en hechos para la toma de decisión 8. Relaciones mutuamente beneficiosas con el proveedor ISO 9002: Sistemas de calidad- Modelo de aseguramiento de la calidad en la producción e instalación. La norma ISO 9002 evalúa todos los recursos humanos y técnicos y los procedimientos istrativos, que garantizan la operación continua y efectiva del sistema de calidad en una empresa. es necesaria la supervisión constante y el cumplimiento de especificaciones, las que servirán para documentar los procedimientos y aseguramiento que satisfacen los requisitos específicos del cliente. En el año 2000, ISO 9002 se unió a la norma ISO 9001, ya que eran similares. La norma ISO 9001 de aseguramiento de calidad estándar cubre tanto la producción, fabricación y partes de servicio de 9002, además de cubrir procesos de creación del diseño. ISO 9003: Sistemas de calidad- Modelo aseguramiento de la calidad Se enfatiza en los requisitos del sistema de calidad especificados en la ISO-9001 y en la ISO-9002 Son complementarios, Estas normas establecen requisitos que determinan que elementos tienen que comprender los sistemas de calidad, el deño de estas normas permiten que están sean genéricas. La norma ISO-9003 se dedica a inspeccionar el producto final terminado, esta norma fue anulada por la publicación del 2000 de la norma ISo-9001. Artículo: Que es ISO-9001 http://www.normas9000.com/que-es-iso-9000.HTML Artículo: ISO-9000 http://orden20166grupo2.blogspot.com/2011/03/cumplimiento-de-normas-iso-90009001_14.html ISO 9126 – Calidad del producto. El estándar ISO 9126 ha sido desarrollado en un intento de identificar los atributos clave de calidad para el software evalúa los productos de software, esta norma nos indica las características de la calidad y los lineamientos para su uso. El estándar identifica 6 atributos clave de calidad:

Funcionalidad: el grado en que el software satisface las necesidades indicadas por los siguientes suba tributos: idoneidad, corrección, interoperatividad, conformidad y seguridad.

• Confiabilidad: cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes suba tributos: madurez, tolerancia a fallos y facilidad de recuperación.

• Usabilidad: grado en que el software es fácil de usar. Viene reflejado por los siguientes suba tributos: facilidad de comprensión, facilidad de aprendizaje y operatividad.

• Eficiencia: grado en que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguientes suba tributos: tiempo de uso y recursos utilizados.

• Facilidad de mantenimiento: la facilidad con que una modificación puede ser realizada. Está indicada por los siguientes suba tributos: facilidad de análisis, facilidad de cambio, estabilidad y facilidad de prueba.

• Portabilidad: la facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes suba tributos: facilidad de instalación, facilidad de ajuste, facilidad de adaptación al cambio.

Artículo: Norma ISO-9126 http://www.austral.edu.ar/aplic/webSIA/webSIA2004.nsf/6905fd7e3ce10eca03256e0b0056c5 b9/c18992b29a6c30e00325779e004ef56b/$FILE/Norma%20ISO%209126%20espa%C3%B1ol.p df

ISO 14598 – Evaluación de productos de software La norma ISO/IEC 14598 es un estándar que proporciona un marco de trabajo para evaluar la calidad de todo tipo de producto software e indica los requisitos para los métodos de medición y el proceso de evaluación, proporcionando métricas y requisitos para los procesos de evaluación, a través de 6 etapas.

· ISO/IEC 14598-1 Visión General: establece un resumen de las otras cinco etapas, explica la relación entre la evaluación del producto software y el modelo de calidad. Actividades: (Establecer los requerimientos de evaluación, Especificar la evaluación, Planear la evaluación, Ejecutar la evaluación). · ISO/IEC 14598-2 Planificación y Gestión: contiene requisitos y guías para las funciones de soporte tales como la planificación y gestión de la evaluación del producto del software. Actividades: (Preparación de políticas, definición de objetivos, Identificación de la tecnología, Asignación de responsabilidades, Evaluación de software desarrollado y adquirido).

· ISO/IEC 14598-3 Proceso de desarrolladores: Lo utiliza las organizaciones que planean desarrollar un producto o mejorar uno existente, realiza evaluaciones de producto utilizando indicadores que puede predecir la calidad de los productos finales. Actividades: (Organización, Planeamiento, Especificaciones, Diseño, Montaje) · ISO/IEC 14598-4 Proceso de comparadores: Lo utilizan las organizaciones que pretenden comparar o rehusar un producto de software existente, se aplica con el propósito de aceptación de un producto. Actividades: (Requerimientos, Especificación evaluación, Diseño evaluación, Ejecución evaluación). · ISO/IEC 14598-5 Proceso evaluadores: este proceso es utilizado por organizaciones encargadas de evaluar, provee los requisitos y guías para la evaluación del producto software. Promueve las siguientes características de proceso (repetible, Reproducible; Imparcial, Objetivo) Actividades: (Trazabilidad, Resultados, Problemas, Mejoras, Conclusiones) · ISO/IEC 14598-6 Modulo evaluación: Especifica las mediciones que van a ser tomadas sobre los atributos de calidad que se definieron en la etapa anterior, provee las guías para la documentación de la evaluación. Actividades: (Introducción, Alcance, Entradas, Resultados) La Norma ISO-14598 proporciona un marco de trabajo para evaluar la calidad de todos los tipos de software, indicando los requisitos que serán medidos, y analizados en este proceso. Implementar estándares que garanticen una correcta evaluación al software y mitigar los errores que pueda presentar cundo se esté ejecutando. Artículo: Gestión de software http://www.fing.edu.uy/inco/cursos/gestsoft/Presentaciones/Evaluacion%20de%20Productos %20-%20G2/Evaluacion%20de%20Productos.pdf

ISO/IEC 25000 Esta proporciona una guía para el uso de las nuevas series de estándares internacionales, llamados Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE). Es una norma que se basa en la ISO 9126 y 14598 y su principal objetivo es determinar una guía para el desarrollo de los productos de software con la especificación y evaluación de requisitos de calidad. Establece criterios para la especificación de requisitos de calidad de productos software, sus métricas y su evaluación. El producto de software debe incorporar unas características, de tal manera que se garantice su eficiencia de uso a los requerimientos de los clientes. Se recomienda que los requisitos de calidad deban ser proporcionales a las necesidades de la aplicación y lo crítico que sea el correcto funcionamiento del sistema implementado. La norma se compone por las siguientes divisiones: · SO/IEC 2500n. División de gestión de calidad. estas divisiones definen todos los modelos comunes, términos y referencias a los que se alude en las demás divisiones de SQuaRE

· ISO/IEC 2501n. División del modelo de calidad. presenta un modelo de calidad detallado, incluyendo características para la calidad interna, externa y en uso. · ISO/IEC 2502n. División de mediciones de calidad. Presenta un modelo de referencia de calidad del producto software, definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas para la calidad de software interna, externa y en uso. · ISO/IEC 2503n. División de requisitos de calidad. ayuda a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto software que va a ser desarrollado o como entrada para un proceso de evaluación. El proceso de definición de requisitos se guía por el establecido en la norma ISO/IEC 15288 (ISO, 2003). · ISO/IEC 2504n. División de evaluación de la calidad. proporciona requisitos, recomendaciones y guías para la evaluación de un producto software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores. · ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen requisitos para la calidad de productos de software “Off-The-Self” y para el formato común de la industria (CIF) para informes de usabilidad. Esta norma define tres vistas diferentes respecto al estudio de la calidad de un producto software: Vista interna: se ocupa de las propiedades del software como: el tamaño, la complejidad o la conformidad con las normas de orientación a objetos. Esta vista puede utilizarse desde las primeras fases del desarrollo para detectar deficiencia del software. Vista externa: analiza el comportamiento del software en producción y estudia sus atributos, por ejemplo: el rendimiento de un software en una máquina determinada, el uso de memoria de un programa o el tiempo de funcionamiento entre fallos. Esta vista se utiliza una vez el software este completo y listo para producción. Vista en uso: mide la productividad y efectividad del final al utilizar el software. Esta vista se utiliza una vez el software esté listo y será evaluado por el cliente y dependerá de los factores determinantes del mismo.

Artículo: Norma ISO/IEC-25000

http://www.redalyc.org/articulo.oa?id=92218339013 Fuente: Publicado por Luis Lozano http://estandarescalidadsoftware.blogspot.mx/ SPICE Es un estándar importante iniciativa internacional para apoyar el desarrollo de una Norma Internacional para la Evaluación de Procesos de Software. El proyecto tiene tres objetivos principales: Para desarrollar un proyecto de trabajo para un estándar para la evaluación de procesos de software. Para llevar a cabo los ensayos de la industria de la norma emergente. Para promover la transferencia de tecnología de la evaluación de procesos de software en la industria mundial del software a nivel mundial. El estándar SPICE creciente en número de métodos de evaluación disponibles, y la creciente utilización de la técnica comercial en áreas sensibles, fueron los factores clave que impulsaron el desarrollo y la aceptación de una propuesta para desarrollar un estándar internacional para la evaluación de procesos de software. Una Norma Internacional sobre Evaluación de Procesos de Software ofrecerá los siguientes beneficios a la industria y los s del software: Beneficios para la Industria del Software Los proveedores de software se someterá a un solo esquema de proceso de evaluación. Las organizaciones de desarrollo de software tendrán una herramienta para iniciar y sostener un proceso continuo de mejora. Los directores de programas tendrán un medio para garantizar que su desarrollo de software está en consonancia y apoya, las necesidades comerciales de la organización. CMMI Es un modelo de mejora de los procesos de construcción de software que provee los elementos necesarios para determinar su efectividad. Este modelo puede ser utilizado como guía para mejorar las actividades de un proyecto, área u organización, ya que proporciona un marco de referencia para evaluar la efectividad de los procesos actuales, facilitando con ello la definición de actividades, prioridades y metas para garantizar la mejora continua. Es el estándar más conocido para la mejora de procesos en mejora de procesos para el desarrollo de proyectos, gestión de proveedores y gestión de servicio. El CMMI establece cinco niveles de madurez los cuales son: Nivel 0: Incompleto El proceso no se realiza, o no se consiguen los objetivos. Nivel 1 Inicial o ejecutando: Este es el nivel en donde todas las empresas que no tienen procesos, es donde el proceso se ejecuta y se logra su objetivo, así sea fuera de presupuesto y de cronograma. Nivel 2 Repetible: Se da cuando el éxito de los resultados obtenidos se puede repetir. Nivel 3 Definido: Significa que la forma de desarrollar proyectos está definida, establecida, documentada y que existen métricas. Nivel 4 istrado: Los proyectos usan objetivos medibles y cuantificables para alcanzar cubrir las necesidades de los clientes y la organización. Es decir, se usan métricas para gestionar la organización.

Nivel 5 Optimizado: Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades, que mediante métricas son identificadas, evaluadas y puestas en práctica.

IEEE (Institute of Electrical and Electronics Engineers) Es un método de establecimiento y mejora del trabajo en equipo para procesos software, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Su creación se remonta al año 1884, contando entre sus fundadores a personalidades de la talla de Thomas Alva Edison, Alexander GrahamBell y Franklin Leonard Pope. En 1963 adoptó el nombre de IEEE al fusionarse asociaciones como el AIEE (American Institute of Electrical Engineers) y el IRE (Institute of Radio Engineers). Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales. Algunos de sus estándares son:       

VHDL POSIX IEEE 1394 IEEE 488 IEEE 802 IEEE 802.11 IEEE 754

Mediante sus actividades de publicación técnica, conferencias y estándares basados en consenso, el IEEE produce más del 30% de la literatura publicada en el mundo sobre ingeniería eléctrica, en computación, telecomunicaciones y tecnología de control, organiza más de 1000 conferencias al año en todo el mundo, y posee cerca de 900 estándares activos, con otros 700 más bajo desarrollo.

PSP El proceso personal del software es un método de autoconocimiento, que permite estimar cuánto se tarda un individuo en realizar una aplicación de software, para así calcular el presupuesto y asegurar la operatividad de los desarrollos. PSP se concentra en las prácticas de trabajo de los ingenieros en una forma individual. El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. El PSP sirve para producir software de calidad, donde cada ingeniero debe trabajar en la necesidad de realizar trabajo de calidad. TSP Team Software Process es un método de establecimiento y mejora del trabajo en equipo para procesos de software. Es un proceso para equipos de software, a través del cual se contribuye equipos de alto rendimiento, capaces de comprometerse con el plan y istración del

desarrollo de software, así como de producir productos de calidad y a bajo costo, logrando el mejor desempeño posible. Moprosoft Es una norma mexicana, basada en procesos para las industrias de software, la cual sirve para estandarizar operaciones y prácticas en gestión de ingeniería de software, para así elevar la capacidad de las organizaciones de ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Está enfocado a las Pymes de la Industria de Software en México. Está dirigido a las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software.

Cuadro comparativo

Estándares y Organismo Normas que regula

Aplicable a

CMMI

(SEI) Software Engineering Institute

Mejora de procesos de construcción de software y proyectos de TI.

PSP

ISO

Permite estimar cuánto se tarda un individuo en realizar una aplicación de software

PSP-TSP

ISO

Predice el tiempo y tamaño del software istración de calidad

ISO 25000

ISO

Establecen un modelo de calidad para el producto del software, además de definir la evaluación de la calidad del producto.

IEEE

IEEE

Serie de documentación para el desarrollo de software y proyectos de TI

TSP

Team Software Process

Es un método de establecimiento y mejora del trabajo en equipo para procesos de software

SPICE

MOPROSOFT

Programa de simulación con énfasis en circuitos integrados

Es una importante iniciativa internacional para apoyar el desarrollo de una Norma Internacional para la Evaluación de procesos del software

ISO

Norma mexicana, basada en procesos para las industrias de software, la cual sirve para estandarizar operaciones y prácticas en gestión de ingeniería de software

Autor: Fernando Aciniega http://fernandoarciniega.com/normas-y-estandares-de-calidad-para-el-desarrollo-desoftware/

Organizaciones de estándares de calidad El primer tipo de Organismo está integrado por consultores independientes, integrantes de departamentos o Secretarías de Estado, u otros individuos (ejemplos de este tipo organizaciones es la ITU, ISO, ANSI, etc.). El segundo tipo de Organismo está integrado por compañías fabricantes de equipos de telecomunicaciones que conjuntamente deciden y proponen estándares para entrar al mercado de las telecomunicaciones y redes. (e.g. ATM Forum, Frame Relay Forum, Gigabit Ethernet Alliance), Fuente: Evelio http://www.eveliux.com/mx/curso/estandares-y-organizaciones.html ISO The International Standards Organization Organización Internacional para la Estandarización. “El OSI es una organización dedicada a acuerdos mundiales sobre estándares internacionales en una amplia variedad de campos.” ITU-T International Telecommunications Union- Telecommunication Standards Sector Unión Internacional de Telecomunicaciones – Sector de Estándares de Telecomunicaciones. “La ITU-T es una organización de estandarización internacional relacionada con las Naciones Unidas que desarrolla estándares para telecomunicaciones.” ANSI Instituto Nacional Americano para la estandarización. La ANSI es una organización sin ánimo de lucro, es el representante con derecho a voto de los Estados Unidos tanto en ISO como en ITU-T. IEEE Institute of Electrical and Electronics Engineers

Instituto de Ingenieros Eléctricos y Electrónicos. “El IEEE es el grupo profesional más grande a nivel nacional involucrado en el desarrollo de estándares para la computación, comunicación, ingeniería eléctrica y electrónica." EIA Electronic Industries Association Asociación de Industrias Electrónicas. “EIA es una asociación de fabricantes de electrónica de los Estados Unidos." CEN Organismo encargado de la labor normalizadora dentro de Europa. Fundada en el 1961 en Paris. W3C Consorcio internacional que produce estándares para la www o RED GLOBAL. Su misión es guiar la web hacia su máximo potencial. Creada por Tim Berners-Lee en el 1994. Estándares: HTML, XML, CSS. IETF Internet engineering task force. Organización que se dedica a promover estándares de internet. Fue creada en EE. UU en 1986. ETSI Organismo encargado fundamentalmente de desarrollar estándares a nivel global en el entorno de las ciencias y la comunicación. Estándares: telefonía móvil GSM, tarjeta SIM, XDSL, DVB and DAB. Fuente: AR López https://es.slideshare.net/drakusalpha/organizaciones-de-estndares

Naturaleza de SRS La SRS son especificaciones para un producto particular de software, programa o juego de programas que realizan ciertas funciones en un ambiente específico. La SRS puede escribirse por:   

Uno o más representantes del proveedor Uno o más representantes del cliente o Por ambos (proveedor y cliente).

Aspectos básicos que se deben tener en cuenta:     

Funcionalidad Interfaces externas (personas, hardware, otro software) Rendimiento Atributos (portable, exacto, mantenimiento, seguridad, …) Restricciones (de diseño, idioma, integridad, limitaciones, ambiente, …)

Fuente: • IEEE Recommendad Practice for Software Requirements Specifications

Consideraciones para producir una buena SRS Naturaleza de la ERS Ambiente de la ERS El software puede contener toda la funcionalidad del proyecto o Puede ser parte de un sistema más grande En el último caso habrá una ERS que:  

Declara las interfaces entre el sistema y ese software modular, e Indica la funcionalidad del software modular

La ERS tiene un rol específico en el proceso de desarrollo de software, quien la define, debe tener cuidado para no ir más allá de los límites de ese rol La ERS   

Debe definir todos los requisitos del software correctamente No debe describir detalles de diseño o implementación No debe imponer restricciones adicionales al software (van en otro documento, por ejemplo, en el de aseguramiento de la calidad)

Características de una buena ERS 

Una buena ERS debe ser: 

Correcta



Inequívoca



Completa 

Con todos los requisitos relacionados con funcionalidad, rendimiento, restricciones de diseño, atributos e interfases externas.



Respuestas a todas las posibles entradas (válidas e inválidas)



Con todas las etiquetas y referencias a figuras, tablas, diagramas en la ERS



Definición de las unidades de medida.



Consistente



Organizada por orden de importancia y/o estabilidad

Esencial, condicionada a u opcional – Con/sin cambios 

Comprobable



Modificable



Trazable

Preparación conjunta de la ERS

Cliente y Proveedor en trabajo conjunto

Evolución de la ERS 

Cambios a medida que: 

Se conozca más a cerca del contenido del proyecto



Se llegue a detalles



Avance el proyecto



Se detecten deficiencias



Se detecten inexactitudes

Prototipos 

Ayudan a entender los problemas y/o soluciones



Muestran posibles comportamientos



Dan más estabilidad a la ERS



Generalmente hacen que en la implementación 

Haya menos cambios



Disminuya el tiempo

Diseño en la ERS 



Una ERS debe especificar 

Qué funciones serán realizadas



Con qué datos



Para producir qué resultados



En qué situación



Para quien

Una ERS no debe especificar 

Módulos en que divide el software



Funciones a los módulos



Flujo de información entre módulos



Controles entre módulos



Estructuras de datos



Necesidad de especificar condiciones de diseño en la ERS para casos especiales, con el fin de imponer restricciones de diseño por 

Seguridad



Confiabilidad



Necesidad de funciones en módulos separados



Restricciones de comunicaciones entre áreas del programa



Garantía de integridad en variables críticas



Disponibilidad física



Disponibilidad de programas/aplicativos/utilitarios



Cumplimiento de estándares

Requisitos del proyecto en la ERS 

La ERS debe estar dirigida al producto del software, no al proceso de producir el software



Algunos requisitos del proyecto, acordados entre el cliente y el proveedor, se incluyen en la ERS 

Costos



Tiempos de entrega



Procedimientos para reportes



Métodos para el desarrollo de Software



Aseguramiento de Calidad



Criterios para validación y verificación



Procedimientos para aceptación

Partes de la 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 Descripción global de la ERS 2. Descripción global del producto

2.1 Perspectiva del producto 2.2 Funciones del producto 2.3 Características de 2.4 Restricciones 2.5 Condiciones y dependencias 2.6. Repartir proporcionalmente los requisitos 3. Requisitos específicos Apéndices Índice Fuente: • IEEE Recommendad Practice for Software Requirements Specifications

Conclusión A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la formalización de la SRS, entre otras. Cada actividad y técnica de la IR utilizada individualmente, dará diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el área del problema son el mismo. Por esta razón, considero que no existe un modelo de proceso ideal para la IR; encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema. Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra a clientes, s, equipo de desarrollo, es de proyectos, etc.; por lo tanto, el proceso de IR no depende solamente de la forma en cómo se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados. Tomando en cuenta la magnitud de comunicación y el trabajo en equipo que debe existir en la IR, considero necesario enfatizar más en cerrar las brechas que todavía existen, incluyendo los siguientes elementos: Factores sociales: involucrar al grupo para compartir sus experiencias. Factores de problemas específicos: el dominio de la estructura y estándares disponibles. Factores organizacionales: tiempo y costo presupuestados. Factores de diseño: por ejemplo, interfaces de Es importante tomarse el tiempo necesario para conocer a nuestros clientes y s, así como su ambiente de trabajo. Esto, también ayuda a establecer una buena relación de trabajo y comunicación entre el equipo de desarrollo y los clientes. Es realmente necesario que los clientes y s participen en la definición de sus requerimientos, pues ellos son los que

deciden nuestro destino en el proyecto, deciden si les gustamos o no y además financian el proyecto.