Anlisis de requisitos del software [PRESSMAN, 2002] La ingeniera de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificacin.

Se refinan en detalle los requisitos del sistema. Tanto el desarrollador como el cliente tienen un papel activo en la ingeniera de requisitos. El cliente intenta replantear un sistema confuso, a nivel de descripcin de datos, funciones y comportamiento, en detalles concretos. El desarrollador acta como interrogador, como consultor, como persona que resuelve problemas y como negociador. El anlisis y la especificacin de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engaan. El contenido de comunicacin es muy denso. Abundan las ocasiones para malas interpretaciones o falta de informacin. Es muy probable que haya ambigedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente annimo: S que cree que entendi lo que piensa que di je, pero no estoy seguro de que se d cuenta de que lo que escuch no es lo que yo quise decir. El anlisis de requisitos es una tarea de ingeniera del software que cubre el hueco entre la definicin del software a nivel sistema y el diseo de software. El anlisis de requerimientos permite al ingeniero de sistemas especificar las caractersticas operacionales del software (funcin, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software. Tareas de anlisis El anlisis de requisitos del software se puede subdividir en cinco reas de esfuerzo: 1. Reconocimiento del problema 2. Evaluacin y sntesis 3. Modelado 4. Especificacin 5. Revisin Todos los mtodos de anlisis se relacionan por un conjunto de principios operativos: 1. Debe representarse y entenderse el dominio de la informacin de un problema. 2. Deben definirse las funciones que debe realizar el software. 3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos), 4. Deben dividirse los modelos que representan informacin, funcin y comportamiento de manera que se descubran los detalles por capas (o jerrquicamente). 5. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la implementacin. Durante el anlisis se sugiere: 1. 2. 3. 4. 5. 6. Entender el problema antes de empezar a crear el modelo de anlisis. Desarrollar prototipos que permitan al usuario entender cmo ser la interaccin hombre-mquina. Registrar el orden y la razn de cada requerimiento, Usar mltiples planteamientos de requerimientos. Priorizar los requerimientos. Trabajar para eliminar la ambigedad.

Funciones y habilidades del analista La funcin principal de un analista del software o ingeniero de requisitos es llevar a cabo las actividades necesarias para cumplir con las cinco reas de esfuerzo descritas en la seccin anterior. Para lo cual hace uso de las siguientes tcnicas:

1. 2. 3. 4. 5. 6.

Entrevistas Talleres Observacin Encuestas Revisin documental Uso de especificaciones formales para requerimientos (formatos estndar de documentos, UML, etc.)

El ingeniero de requisitos debe poseer habilidades particulares para facilitar la comunicacin con el cliente y ganar su confianza. Ingeniera de Requisito Conceptos [SOMMERVILLE, 2002] Requisitos del Software: Es la descripcin de los servicios y restricciones de un sistema de software, es decir, lo que el software debe hacer y bajo qu circunstancias debe hacerlo. Ingeniera de Requisitos del Software: requisitos del software. Es el proceso de descubrir, analizar, documentar y verificar los

Stakeholders: Este trmino se utiliza para referirse a cualquier persona que tiene influencia directa o indirecta sobre los requisitos del sistema. Entre los stakeholders se encuentran los usuarios finales que interactan con el sistema y todos aquellos en la organizacin s que vern afectados por dicho sistema. Los stakeholders tambin son los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los administradores del negocio, los expertos en el dominio del sistema, los representantes de los trabajadores, etc. El proceso de la ingeniera de requisitos

Las actividades del proceso son: 1. Comprensin del dominio 2. Recoleccin de requisitos 3. Clasificacin 4. Resolucin de conflictos 5. Priorizacin 6. Verificacin de requisitos

7.

Anlisis

Actividades de la Ingeniera de Requisitos. [SOMMERVILLE, 2002] La ingeniera de requisitos incluye dos actividades principales: la obtencin de requisitos, que da como resultado una especificacin del sistema que el cliente comprende, y el anlisis, que da como resultado un modelo de anlisis que los desarrolladores pueden interpretar sin ambigedad. [BRUEGGE, 2002]

La obtencin de requisitos: descripcin del propsito del sistema e implica el reto mayor. El cliente, los desarrolladores y los usuarios identifican un rea problema y definen un sistema que resuelve el problema. Esto es especificacin de los requisitos del software (SRS) y sirve como contrato entre el cliente y los desarrolladores. La SRS se estructura y formaliza durante el anlisis para producir un modelo de anlisis. Tanto la SRS como el modelo de anlisis representan la misma informacin. Difieren slo en el lenguaje y notacin que usan. La SRS est escrita en lenguaje natural, mientras que el modelo de anlisis se expresa, por lo general, en una notacin formal o semiformal. La especificacin del sistema es la base de la comunicacin con los stakeholders. El modelo de anlisis es la base de la comunicacin entre los desarrolladores. La obtencin de requisitos y el anlisis se enfocan slo en la visin del sistema que tiene el usuario.

Tipos de requisitos Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementacin. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interacte el sistema. Requisitos no funcionales: Describen atributos slo del sistema o del ambiente del sistema que no estn relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisin, tipo de plataforma (lenguajes de programacin y/o sistemas operativos, etc.)

Caractersticas de una buena SRS [IEEE Std 830-1998] 1. 2. 3. Correcta: cada requisito especificado es un requisito que el software debe cumplir. No ambigua: cada requisito especificado tiene slo una interpretacin. Completa: a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeo, restricciones de diseo, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificacin del sistema debe ser reconocido y tratado. b) Definicin de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS as como la definicin de todos los trminos y unidades de medida.

4.

Consistente: no se contradice a s misma, es decir, si ningn subconjunto de requisitos ah descritos se contradicen o entran en conflicto. Jerarquizada de acuerdo a la importancia y/o estabilidad: cada requisito tienen un identificador que indique la importancia o estabilidad del requisito. Verificable: cada requisito especificado es verificable. En general cualquier requisito ambiguo no es verificable. Modificable: su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fcil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una SRS: a) Tenga una organizacin coherente y fcil de usar con una tabla de contenido, un ndice y referencias cruzadas explcitas. b) No sea redundante (esto es, el mismo requisito no debe aparecer en ms de un Parte en la SRS). c) Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros Requisitos. Rastreable: si el origen de cada uno de sus requisitos es clara y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentacin. Se recomiendan los siguientes dos tipos de rastreabilidad: a) Rastreabilidad hacia atrs (esto es, a estados previos del desarrollo). b) Rastreabilidad hacia enfrente (esto es, a todos los documentos Derivados del SRS).

5.

6. 7.

8.

BIBLIOGRAFIA [BRUEGGE, 2002]

Ingeniera de Software Orientado a Objetos Bruegge, Bernd y Dutoit, Allen Prentice-Hall, 2002 ISBN: 970-26-0010-3 IEEE Recommended Practice for Software Requirements Specifications Software Engineering Standards Committee of the IEEE Computer Society ISBN 0-7381-0332-2 Ingeniera del Software. Un enfoque prctico. 5ta. Edicin Pressman, Roger McGraw-Hill, 2002 ISBN 84-481-3214-9 Ingeniera de Software. 6ta. Edicin Sommerville, Ian Prentice-Hall, 2002 ISBN 970-26-0206-8

[IEEE Std 830-1998]

[PRESSMAN, 2002]

[SOMMERVILLE, 2002]

[ISURJC]

Curso de Ingeniera del Software I Universidad Rey Juan Carlos http://kybele.escet.urjc.es/asignatura.asp?Nombre1=ISI

TAREAS DE LA INGENIERIA DE REQUISITOS

"por lo general las semillas mas importantes del los desastres mas importantes en software se siembra en los primeros 3 meses de inicio del proyecto "[Carpers Jones, 2013] Identifica nueva necesidad de negocios, se decubre nuevo mercado y nuevo servicio. identificar ambito general del proyecto. identificar amplitud y profundidad del mercado. analisis preliminar de factibilidad. descripcion funcional del ambito del proyecto.

INICIO

Realizar en forma organizada la recopilacion de informacion Problema de ambito: el limite del sistema esta mal definido o los usuarios especifican detalles innecesarios. Problema de comprension: los usuarios no estan seguros de que es lo que necesitan. Problema de volatilidad: los problemas cambian conforme cambia el tiempo.

OBTENCION

Creacion de modelo de analisis Define dominio de la informacion, funciones y compartimiento del problema. Desarrollo de un modelo tecnico refinado de las funciones, caracterizticas y restricciones del software.

ELABORACION

NEGOCIACION

negociar con el cliente alcances y limites del sistema.

Ordenar requisitos y establecer prioridades. Identificar y analizar riesgos de cada requisito.

ESPECIFICACION

Producto final de la ingenieria de requisitos y se convierte en materia prima de las siguientes actividades.

Documento escrito que combina que combina descripciones de lenguaje natural modelos graficos. Describe funcion de un sistema basado en computadora y las restriciones que regiran su desarrollo.

VALIDACION

Deteccion y correccion de errores, conflictos, omisiones

Orden

Garantiza consistencia de requisitos. Examina la especificacion para asegurar que todos los requisitos se han establecido de manera precisa. Revision tecnica formal.

GESTION

Rastreo de requisitos.

reastrea requisitos segun sus caracterizticas, el codigo fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas. Actividades que ayudan a identificar los cambios en los requisitos en cualquier momento del proyecto

ADEMAS DE ESTAS TAREAS TAMBIEN COMPRENDE:

IDENTIFICAR STAKEHOLDERS: Personas interesadas en el desarrollo del sistema. ENTENDER NECESIDADES: De los usuarios. IDENTIDFICAR REQUERIMIENTOS: provienen de los objetivos que se plantean en el inicio, se indican por medio de sentencias. ACLARECER Y REFINAR LOS REQUERIMIENTOS: Cuando se tiene plena seguridad de que los requerimientos indican las necesidades reales del cliente. ANALIZAR LOS REQUERIMIENTOS: Cuando los requerimientos estan bien definidos. ESPECIFICAR LOS REQUERIMIENTOS: Cada requerimiento debe expresarse en forma detallada. PRIORIZA REQUERIMIENTOS: Niveles de importancia de los requerimientos. DERIVAR LOS REQUERIMIENTOS: Detallar los requerimientos no visibles. PATROCINAR LOS REQUERIMIENTOS: Se clasifican en: Hardware, Software y entrenamiento. ASIGNAR LOS REQUERIMIENTOS: Asigna los requerimientos a diferentes subsistemas y componentes internos. HACER SEGUIMIENTO DE LOS REQUERIMIENTOS: Capacidad de permitir que un requerimiento satisfechos pueda ser referenciado dentro del sistema. MANEJAR LOS REQUERIMIENTOS: Se desarrollo un sistema de control de los requerimientos necesario para adicionar modificar y borrar los requerimientos . PROBAR Y VERIFICAR LOS REQUERIMIENTOS: Asegurarse que los requerimientos estan bien. VALIDAR LOS REQUERIMIENTOS: Se confirma que son reales y que han sido implementados.