REQUERIMIENTOS DEL SOFTWARE

PRESENTADO POR:

KERLY PARRA

SWEBOK

INTRODUCCION

El area del conocimiento de requisitos del software (KA) se refiere a la obtención, análisis, especificación, y validación de requisitos del software. Así como la gestión de requisitos durante todo el ciclo de vida del producto de software.

TEMAS PARA REQUISITOS DEL SOFTWARE

1. Fundamentos de los requisitos del software

2. Proceso de los requisitos3. Elicitaciòn de los requisitos4. Analisìs de requisitos5. Especificaciòn de requisitos6. Validaciòn de los requisitos7. Consideraciones practicas8. Herramientas de los requisitos del

software

FUNDAMENTOS DE LOS REQUISITOS DEL SOFTWARE

1. Definiciòn de un Requisito del Software

Un requisito del software es una propiedad que se debe exhibir por algo para resolver algún problema en el mundo real.

Una propiedad esencial de todos los requisitos de software es que sean verificables como un individuo funcióna como requisito funcional o en el nivel de sistema como un requisito no funcional.

2. Producto y Requisitos del Proceso

Los requisitos de un producto es una necesidad o restricción en el software a ser desarrollado .

Un requisito del proceso es esencialmente una restricción en el desarrollo del software .

3. Requisitos Funcionales y No Funcionales

Los requisitos funcionales describen las funciones que el software va a ejecutar,también se puede describir como uno de los que un conjunto finito de pasos de prueba puede ser escrito para validar su comportamiento.

Los requisitos no funcionales son los que actuan para restringir la solución. Los requisitos no funcionales son a veces conocidos como restricciones o requisitos de calidad.

4. Propiedades Emergentes

Algunos requisitos representan propiedades emergentes de los requisitos de software, es decir, que no puede ser abordados por un solo componente, pero que dependerá de cómo todos los componentes de software inter operan.

5. Requisitos Cuantificables

Los requisitos del software deben expresarse tan claramente y como sin ambigüedad como sea posible, y, en su apropiado, cuantitativamente. Es importante evitar los requisitos vagos y no verificables que dependen para su interpretación sobre subjetiva juicio.

El software debe ser confiable. El software debe ser fácil de usar.

6. Requisitos del Sistema y Requisitos del Software

Combinación de elementos que interactúan para lograr un objetivo determinado. Estos incluyen hardware, software,personas, información, técnicas, instalaciones, servicios, y otros elementos de apoyo, según lo definido por el Consejo Internacional de Software e Ingeniería de Sistemas.

PROCESO DE LOS REQUISITOS

1. Modelos de Procesos

No es una actividad anticipada discreta del ciclo de vida del software, sino más bien un proceso iniciado en el comienzo de un proyecto que sigue ser refinado a lo largo del ciclo de vida.

Identifica los requisitos del software como la configuración de artículos y gestiona usando la gestión de la configuración misma de software como prácticas de otros productos o procesos del ciclo de vida del software

Necesita ser adaptado a la organización y contexto del proyecto.

2. Actores del Proceso

En este tema se presentan los roles de las personas que participan en el proceso de requisitos.

Usuarios: Este grupo comprende a los que va a operar el software.

Clientes: Este grupo comprende a los que han encargado el software o que representan el mercado objetivo de software.

Los analistas de mercado: Un producto de mercado masivo no tendrá un cliente puesto en marcha.

Reguladores: Muchos dominios de aplicación, tales como la banca y el transporte público, son regulados.

Los ingenieros de software: Estos individuos tienen un interés legítimo en sacar provecho de desarrollo el por software.

3.  Apoyo y Gestión de Procesos

Se presenta los recursos de la gestión de proyectos necesarios y consumidos por el proceso de los requisitos.

Su principal objetivo es hacer que el vínculo entre a las actividades del proceso identificadas.

4. Calidad y Mejora del Proceso

Se refiere a la evaluación de la calidad y la mejora del proceso de los requisitos.

El proceso de calidad y mejora están estrechamente relacionados tanto a la Calidad del Software KA e Ingeniería del Proceso del Software KA, que comprende:

Cobertura de proceso de los requisitos por normas y modelos de mejora

Medidas de proceso de los requisitos de evaluación comparativa

Planificación e implementación de mejora; Seguridad / mejora de la CIA / planificación y implementación.

 

ELICITACIÒN DE LOS REQUISITOS

Se refiere a los orígenes de los requisitos de software y cómo el ingeniero de software puede recogerlos. Es la primera etapa en la construcción de una comprensión del problema que el software requiere para resolver.

Un elemento crítico de la obtención de requisitos es informar el alcance del proyecto.

1. Fuentes de los Requisitos

Los requisitos tienen muchas fuentes en el software típico, y es esencial que todas las fuentes potenciales estés identificadas y evaluadas.

Objetivos. Proporcionan la motivación para el software, pero son a menudo vagamente formulados.

Conocimiento de Dominio. El ingeniero de software necesita adquirir o tener conocimiento disponible sobre el dominio de aplicación.

El entorno operativo. Los requerimientos se derivan del ambiente en el que se ejecutará el software.

2. Técnicas de Obtención

Se centra en las técnicas para conseguir actores humanos para articular requisitos pertinentes de la información.

Entrevistas. Entrevistar a los interesados es un medios "tradicional" de los requisitos de obtención

Escenarios. Valiosos medios de escenarios proporcionan una e licitación para proporcionar contexto a las necesidades del usuario

Prototipos. Esta técnica es una herramienta valiosa para aclarar los requisitos ambiguos

Facilitando reuniones. El propósito de estas reuniones es tratar de lograr un sumaria de efecto.

ANALISIS DE REQUISITOS

 Este tema tiene que ver con el proceso de análisis requisitos a:

Detectar y resolver los conflictos entre requisitos

Descubrir los límites del software y cómo debe interactuar con su organización y entorno operativo

Elaborar requisitos del sistema para derivar requisitos del software

1. Clasificación de Requisitos

Los requisitos pueden clasificarse en un número de dimensiones. Algunos ejemplos son los siguientes:

Si el requisito es sobre el producto o el proceso. Los requisitos en el proceso pueden limitar la elección del contratista, adaptar el proceso de ingeniería del software, o las normas que deben respetarse.

La prioridad del requisito. Cuanto mayor sea la prioridad, más esencial el requisito es para cumplir con los objetivos generales del programa. A menudo clasificado en una escala fija tal como obligatorio, altamente deseable, deseable, u opcional, la prioridad a menudo tiene que ser equilibrado contra el costo de desarrollo e implementación.

2. El Modelado Conceptual

El desarrollo de modelos de un problema del mundo real es clave para el análisis de los requisitos de software. Su propósito es ayudar en la comprensión de la situación en la que se produce el problema, así como representa una solución.

Varios tipos de modelos se pueden desarrollar. Estos incluyen diagramas de casos de uso, los modelos de flujo de datos, modelos de estado, los modelos basados en objetivos, las interacciones del usuario, modelos de objetos, modelos de datos, y muchos otros.

3. Asignación Arquitectónica de Diseños y de los Requisitos

En algún momento, la arquitectura de la solución debe ser derivada. El diseño arquitectónico es el punto en que el proceso se superpone con los requisitos del software o sistemas de diseño se ilustra cómo de imposible que es para desacoplar limpiamente las dos tareas.

La asignación es importante para permitir un análisis detallado de requisitos

4. Negociación de los Requisitos

Se refiere a la resolución de problemas con los requisitos de los conflictos ocurren entre dos actores que requieren mutuamente características incompatibles, entre los requisitos y los recursos, o entre requisitos funcionales y no funcionales

Los requisitos de prioridades son necesarios, no sólo como un medio para filtrar los requisitos importantes, sino también con el fin de resolver los conflictos.

5. Análisis Formal

El mayor análisis formal se concentra en relativamente las últimas etapas de análisis de requisitos. Es generalmente contraproducente para aplicar formalización hasta que los objetivos de negocio y necesidades de los usuarios.

ESPECIFICACION DE REQUISITOS

Para la mayoría de las carreras de ingeniería, el término "especificación" se refiere a la asignación de numéricos valores o límites a los objetivos de diseño de un producto.Se refiere a la producción de un documento que puede ser revisado de forma sistemática, evaluado y aprobado

1. El Documento de la Definicion del Sistema

Este documento (a veces conocido como el usuario requisitos documento o concepto de las operaciones documento) registra los requisitos del sistema. El define los requisitos del sistema de alto nivel desde la perspectiva de dominio.

2. Requisitos del sistema de Especificaciones

Los desarrolladores de sistemas con software sustancial y los componentes de software-un no avión moderno, por ejemplo, separa a menudo la descripción de los requisitos del sistema de la descripciónde los requisitos de software.

3. Especificacion de Requisitos del Software

La especificacion de Requisitos del software establece la base para un acuerdo entre los clientes y contratistas o proveedores (en los proyectos impulsados por el mercado, estos roles pueden ser reproducidos por la comercialización y divisiones de desarrollo) en lo que el producto del software, así como lo que no se espera hacer.

VALIDACION DE LOS REQUISITOS

Los documentos de requerimientos pueden estar sujetos a validaciones y procedimientos de verificación. los requisitos pueden ser validados para asegurarse de que el ingeniero del software ha entendido los requisitos; También es importante verificar que un documento de requisitos se ajusta a las normas de la empresa y que es comprensible, coherente y completo.

1. Comentarios de los Requisitos

Tal vez los medios más comunes de la validación es por inspección o revisión de los documentos de requisitos. Se asigna un grupo de revisores en un breve buscador de errores, suposiciones erróneas, falta de claridad, y la desviación de la práctica estándar.

Los comentarios pueden ser constituidos al término del documento de definición del sistema, la especificación de los documentos del sistema, los requisitos de especificaciones de los documentos del software, la especificación de la línea de base para un nuevo lanzamiento, o en cualquier otro paso en la proceso

2. Prototipos

Prototipos es comúnmente un medio para validar la interpretación que el ingeniero del software de los requisitos del software, así como para la obtención de un nuevo requisito.

La ventaja de prototipos es que pueden hacer que sea más fácil de interpretar los supuestos del ingeniero del software y, cuando sea necesario, dar información útil sobre por qué están equivocados

3. Valdaciòn del Modelo

Es típicamente necesario validar la calidad de los modelos desarrollados durante el análisis. Por ejemplo, en modelos de objetos, es útil para realizar un análisis estático para verificar que las rutas de comunicación existen entre los objetos que, en los grupos de dominio de interés, el intercambio de datos.

4. Pruebas de Aceptaciòn

Una propiedad esencial de un requisito del software es que debería ser posible para validar que el producto terminado satisface. Los requisitos que no pueden ser validados son en realidad "deseos“.

En la mayoría de los casos, el diseño de pruebas de aceptación hace por cómo los usuarios finales normalmente realizan negocios utilizando el sistema.

CONSIDERACIONES PRACTICAS

El proceso de requisitos se extiende por la totalidad ciclo de vida del software. La gestión del cambio y del mantenimiento de los requisitos de un Estado querefleja con precisión el software a construir, o que se ha construido, son clave para el éxito del proceso de ingenieria del software.

1. Naturaleza Iteractiva del Proceso de los Requisitos

Hay una presión general en la industria del software para los ciclos de desarrollo cada vez más cortos, y esto es particularmente pronunciado en sectores de mercado altamente competitivo. Por otra parte, la mayoría de los proyectos están limitados de alguna manera por su entorno, y muchos son mejoras para, o las revisiones, existentes del software donde la arquitectura es un hecho.

2. Cambiar a Gestion

La gestión del cambio es fundamental para la gestión de requisitos. En este tema se describe el papel de gestión del cambio, los procedimientos que deben estar en su lugar, y el análisis que se debe aplicar a los cambios propuestos.

3. Atributos de los Requisitos

Los requisitos deben consistir no sólo de una especificación de lo que se requiere, sino también de la informacion de auxiliares, que ayudan a administrar e interpretar los requisitos. Los atributos de los requisitos deben definir la grabada y actualizada del software bajo el desarrollo o mantenimiento evolucionado.

4. Trazado de los Requisitos

El rastreo de los requisitos tiene que ver con la fuente recuperación de los requisitos y la predicción de los efectos de los requisitos. El rastreo es fundamental a la realización de análisis de impacto cuando los requisitos cambian. Un requisito debe ser trazable hacia atrás a los requisitos y las partes interesadas que lo motivan (de un requisito de software de nuevo al requisito (s) del sistema que ayuda a satisfacer

5. Medicion de los Requisitos

Como una cuestión práctica, es típicamente útil tener algún concepto del "volumen" de los requisitos para un producto de software en particular. Este número es útil para evaluar el "tamaño" de un cambio en los requisitos, en la estimación del costo de una tarea desarrollo o mantenimiento, o simplemente para utilizar como denominador en otras mediciones .

HERRAMIENTAS DE LOS REQUISITOS DEL SOFTWARE

Las herramientas para hacer frente a los requisitos del software caen a rasgos grandes en dos categorías: herramientas para el modelado y herramientas para la gestión de requisitos.