ANLISIS 4. REQUISITOS

Este tema tiene que ver con el proceso de anlisis de requisitos a: Detectar y resolver los conflictos entre requisitos. Descubrir los lmites del software y cmo debe interactuar con su entorno organizacional y operativo. Requisitos del sistema elaborados para derivar los requisitos de software.La visin tradicional de anlisis de requerimientos ha sido que sea reducido a modelado conceptual usando uno de varios mtodos de anlisis, tales como el mtodo de anlisis estructurado. Si bien el modelado conceptual es importante, Incluimos la clasificacin de los requisitos para ayudar a informar a las compensaciones entre los requisitos (clasificacin requisitos) y el proceso de creacin de estos compensaciones (requisitos de negociacin).Se debe tener cuidado para describir los requisitos suficientes, precisamente para permitir a los requisitos para ser validados, su aplicacin para ser verificada, y sus costes a estimar.4.1. Clasificacin de requerimientosLos requisitos pueden ser clasificados en un nmero de dimensiones.Algunos ejemplos son los siguientes: Si el requisito es funcional o no funcional (ver seccin 1.3, Funcional y requisitos no funcionales).

Si el requisito se deriva de uno o ms requisitos de alto nivel o una propiedad emergente (ver seccin 1.4, las propiedades emergentes), o est siendo impuesta directamente en el software por una de las partes interesadas o de alguna otra fuente.

Si el requisito es en el producto o el proceso (ver seccin 1.2, del producto y requisitos de proceso). Requisitos sobre el proceso pueden limitar la eleccin del contratista, el proceso de ingeniera de software para ser adoptado, o las normas que deben cumplirse.

La prioridad requisito. Cuanto mayor sea la prioridad, ms esencial es el requisito para cumplir con los objetivos generales del programa. A menudo clasifican en una escala de coma fija como obligatoria, muy deseable, deseable o opcional, la prioridad a menudo tiene que ser equilibrada contra el costo de desarrollo y aplicacin.

El alcance de la prescripcin. mbito de aplicacin se refiere a la medida en que un requisito afecta a los componentes de software y de software. Algunos de los requisitos, en especial a algunos que no funcionales, tienen un alcance global en que su satisfaccin no puede ser asignado a un componente discreto. Por lo tanto, un requisito con el alcance global puede afectar fuertemente la arquitectura de software y el diseo de muchos componentes, mientras que uno con un alcance limitado puede ofrecer una serie de opciones de diseo y tienen poco impacto en la satisfaccin de otras necesidades.

Volatilidad / estabilidad. Algunos requisitos cambiarn durante el ciclo de vida del software- e incluso durante el propio proceso de desarrollo. Es til si alguna estimacin de la probabilidad de que un requisito cambiar puede hacerse. Por ejemplo, en una bancaaplicacin, los requisitos para las funciones para calcular y el inters de crdito a los clientes cuentas tienden a ser ms estable que un requisito para apoyar un tipo particular de cuenta libre de impuestos. El primero refleja una caracterstica fundamental del dominio bancario (que las cuentas pueden ganar intereses), mientras que los segundos pueden dejarlo obsoleto por un cambio en la legislacin del gobierno. Cmo marcar requisitos potencialmente voltiles puede ayudar al ingeniero de software de establecer un diseo que es ms tolerante de cambio.

Otras clasificaciones pueden ser apropiados, dependiendo de la prctica normal de la organizacin y la propia aplicacin.Existe una fuerte coincidencia entre atributos requisitos de clasificacin y requisitos (ver seccin 7.3, Requisitos Atributos).

4.2. Modelado conceptualEl desarrollo de modelos de un problema del mundo real es clave para el anlisis de los requisitos de software.Su propsito es ayudar en la comprensin de la situacin en la que se produce el problema, as como que representa una solucin. Por lo tanto, los modelos conceptuales comprenden modelos de entidades del dominio del problema, configurado para reflejar sus relaciones del mundo real y dependencias. Este tema est estrechamente relacionado con los modelos de ingeniera de software y Mtodos KA.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. Muchas de estas notaciones de modelado son parte de la Unified Modeling Language (UML). Usar diagramas de casos, por ejemplo, se utilizan habitualmente para representar escenarios en los que el lmite que separa a los actores (usuarios o sistemas en el entorno externo) Del comportamiento interno, donde cada caso de uso representa una funcionalidad del sistema.

Los factores que influyen en la eleccin de la notacin de modelado incluyen los siguientes: La naturaleza del problema. Algunos tipos de software exigen que ciertos aspectos se analizarn especialmente rigurosa. Para los modelos de ejemplo, estatales y paramtricas, que son parte de SysML [4], es probable que sean ms importantes para el software en tiempo real de los sistemas de informacin, mientras que por lo general sera lo contrario para los modelos de objetos y de actividad.

La experiencia del ingeniero de software. A menudo es ms productivo adoptar una notacin de modelado o el mtodo con el que el ingeniero de software con experiencia.

Los requisitos del proceso del cliente (ver seccin 1.2, Productos y Procesos Requisitos). Los clientes pueden imponer su notacin o mtodo favorecido o prohibir cualquier con las que estn familiarizados. Este factor puede entrar en conflicto con el factor anterior.

Tenga en cuenta que, en casi todos los casos, es til comenzar mediante la construccin de un modelo del contexto software. El contexto software proporciona una conexin entre los programas informticos destinados y su entorno externo.Esto es crucial para entender el contexto del software en su entorno operativo y para la identificacin de sus interfaces con el medio ambiente.Este subtema no busca "ensear" un estilo de modelado en particular o la notacin sino ms bien proporciona orientacin sobre el propsito y la intencin de la modelizacin.4.3. Diseo y requisitos arquitectnicos de asignacinEn algn momento, la arquitectura de la solucin debe ser derivada. El diseo arquitectnico es el punto en el que el proceso se superpone con los requisitos de software o sistemas de diseo e ilustra cun imposible es disociar limpiamente las dos tareas.Este tema est estrechamente relacionado con la estructura del software y la arquitectura en el diseo de software KA. En muchos casos, los actos de ingeniera de software como arquitecto de software debido a que el proceso de anlisis y la elaboracin de los requisitos exige que se identifiquen los componentes de la arquitectura / diseo que se encargarn de satisfacer los requisitos. Se trata de requisitos de asignacin de-la asignacin de componentes de la arquitectura responsables de la satisfaccin de las necesidades.Asignacin es importante para permitir un anlisis detallado de las necesidades. Por lo tanto, por ejemplo, una vez que un conjunto de requisitos se ha asignado a un componente, los requisitos individuales se pueden analizar an ms para descubrir nuevos requisitos sobre cmo el componente necesita interactuar con otros componentes con el fin de satisfacer los requerimientos asignados.En grandes proyectos, la asignacin estimula una nueva ronda de anlisis para cada subsistema. Como ejemplo, los requisitos para un rendimiento de frenado en particular para un coche (distancia de frenado, la seguridad en malas condiciones de conduccin, la suavidad de la aplicacin, la presin del pedal necesarios, y as sucesivamente) pueden asignarse al hardware de frenado (conjuntos mecnicos e hidrulicos) y una sistema de frenos antibloqueo (ABS). Slo cuando un requisito para un sistema de frenado antibloqueo ha sido identificado, y los requisitos que se le asignen, se puede utilizar las capacidades del ABS, el hardware de frenado y propiedades emergentes (tales como el peso del coche) para identificar los requisitos detallados de software del ABS.El diseo arquitectnico est estrechamente identificado con el modelado conceptual (ver seccin 4.2, Modelado Conceptual).

4.4. Requerimientos de negociacin

Otro trmino comnmente utilizado para este subtema es "resolucin de conflictos". Esto se refiere la resolucin de problemas con los requisitos que se producen conflictos entre dos partes interesadas que requieran funciones incompatibles entre s, entre las necesidades y los recursos, o entre requisitos funcionales y no funcionales, por ejemplo. En la mayora de los casos, no es aconsejable para el ingeniero de software para hacer una decisin unilateral, por lo que se hace necesario consultar con la parte interesada (s) para llegar a un consenso sobre una compensacin adecuada. A menudo es importante, por razones contractuales, que tales decisiones volvern trazable al cliente. Hemos clasificado esto como un tema de anlisis de requisitos de software porque los problemas surgen como el resultado del anlisis. Sin embargo, un caso fuerte tambin se puede hacer por considerarlo un tema de validacin requisitos (ver tema 6, Requisitos de validacin).Requisitos priorizacin es necesario, no slo como un medio para filtrar los requisitos importantes, sino tambin con el fin de resolver los conflictos y planificar las entregas escalonadas, lo que significa tomar decisiones complejas que requieren un conocimiento detallado de dominioy buenas habilidades de estimacin. Sin embargo, a menudo es difcil obtener informacin real que puede actuar como una base para tales decisiones. Adems, los requisitos a menudo dependen unos de otros, y las prioridades son relativas. En la prctica, los ingenieros de software realizan requisitos priorizacin con frecuencia sin necesidad de conocer todos los requisitos.Requisitos priorizacin puede seguir un enfoque de valor costo que implica un anlisis de las partes interesadas definen en una escala de los beneficios o el valor agregado que la aplicacin del requisito de las trae, contra las penas de no haber implementado un requisito particular. Tambin implica un anlisis de los ingenieros de software de estimacin en una escala el costo de la implementacin de cada requisito, relativoa otros requisitos. Otro enfoque requisitos priorizacin llama el proceso analtico jerrquico implica la comparacin de todos los pares nicos de los requisitos para determinar cul de los dos es de mayor prioridad, y en qu medida.

4.5. Anlisis formalAnlisis preocupaciones formales no slo el tema 4, sino tambin las secciones 5.3 y 6.3. En este tema tambin se relaciona con los mtodos formales en los modelos de ingeniera de software y mtodos rea de Conocimiento.Anlisis formal ha hecho un impacto en algunos dominios de aplicacin, en particular los de los sistemas de alta integridad. La expresin formal de requisitos requiere un lenguaje con semntica definida formalmente. El uso de un anlisis formal para los requisitos de expresin tiene dos beneficios.En primer lugar, permite a los requisitos expresados en el lenguaje para especificar con precisin y sin ambigedades, por lo tanto (en principio) para evitar la posibilidad de una mala interpretacin. En segundo lugar, los requisitos se puede razonar sobre, permitiendo propiedades deseadas del software especificado por demostrar. Razonamiento formal requiere soporte de herramientas para ser practicable para distintos de los sistemas triviales nada, y las herramientas generalmente se dividen en dos tipos: demostradores de teoremas o las damas modelo. En ninguno de los casos puede ser completamente a prueba automatizado, y el nivel de competencia en razonamiento formal sea necesario con el fin de utilizar las herramientas restringe la aplicacin ms amplia de anlisis formal.

El mayor anlisis formal se centra en etapas relativamente tardas de anlisis de requisitos. En general, es contraproducente para solicitar la formalizacin hasta que los objetivos de negocio y necesidades de los usuarios han entrado en un enfoque ntido a travs de medios tales como los descritos en otras partes de la seccin 4. Sin embargo, una vez que los requisitos se han estabilizado y se han elaborado para especificar las propiedades del concreto del software, puede ser beneficioso para la formalizacin de al menos los requisitos crticos. esto permite validacin esttica que el software especificado por los requisitos s tiene las propiedades (por ejemplo, ausencia de estancamiento) que el cliente, los usuarios, y el ingeniero de software de esperar que tenga.

5.3 INDAGACIN DE LOS REQUERIMIENTOSLa indagacin de los requerimientos (actividad tambin llamada recabacin de los requerimientos) combina elementos de la solucin de problemas, elaboracin, negociacin y especificacin.A fin de estimular un enfoque colaborativo y orientado al equipo, los participantes trabajan juntos para identificar el problema, proponer elementos de la solucin, negociar distintas visiones y especificar un conjunto preliminar de requerimientos para la solucin [Zah90].

5.3.1 Recabacin de los requerimientos en forma colaborativa

Se han propuesto muchos enfoques distintos para recabar los requerimientos en forma colaborativa.Cada uno utiliza un escenario un poco diferente, pero todos son variantes de los siguientes lineamientos bsicos:

Tantos ingenieros de software como otros participantes dirigen o intervienen en las reuniones.

Se establecen reglas para la preparacin y participacin.

Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos importantes, pero con la suficiente informalidad para que estimule el libre flujo de ideas.

Un facilitador (cliente, desarrollador o participante externo) controla la reunin.

Se utiliza un mecanismo de definicin (que pueden ser hojas de trabajo, tablas sueltas, etiquetas adhesivas, pizarrn electrnico, grupos de conversacin o foro virtual).

La meta es identificar el problema, proponer elementos de la solucin, negociar distintos enfoques y especificar un conjunto preliminar de requerimientos de la solucin en una atmsfera que favorezca el logro de la meta. Para entender mejor el flujo de eventos conforme ocurren, se presenta un escenario breve que bosqueja la secuencia de hechos que llevan a la reunin para obtener requerimientos, a lo que sucede durante sta y a lo que sigue despus de ella.Durante la concepcin (vase la seccin 5.2), hay preguntas y respuestas bsicas que establecen el alcance del problema y la percepcin general de lo que constituye una solucin. Fuera de estas reuniones iniciales, el desarrollador y los clientes escriben una o dos pginas de solicitud de producto.Se selecciona un lugar, fecha y hora para la reunin, se escoge un facilitador y se invita a asistir a integrantes del equipo de software y de otras organizaciones participantes. Antes de la fecha de la reunin, se distribuye la solicitud de producto a todos los asistentes.Por ejemplo, considere un extracto de una solicitud de producto escrita por una persona de mercadotecnia involucrada en el proyecto CasaSegura. Esta persona escribe la siguiente narracin sobre la funcin de seguridad en el hogar que va a ser parte de CasaSegura:

Nuestras investigaciones indican que el mercado para los sistemas de administracin del hogar crece a razn de 40% anual. La primera funcin de CasaSegura que llevemos al mercado deber ser la de seguridad del hogar. La mayora de la gente est familiarizada con sistemas de alarma, por lo que sta deber ser fcil de vender.La funcin de seguridad del hogar protegera, o reconocera, varias situaciones indeseables, como acceso ilegal, incendio y niveles de monxido de carbono, entre otros. Empleara sensores inalmbricos para detectar cada situacin. Sera programada por el propietario y telefoneara en forma automtica a una agencia de vigilancia cuando detectara una situacin como las descritas. En realidad, durante la reunin para recabar los requerimientos, otros contribuiran a esta narracin y se dispondra de mucha ms informacin. Pero aun con sta habra ambigedad, sera probable que existieran omisiones y ocurrieran errores. Por ahora bastar la descripcin funcional anterior.

Mientras se revisa la solicitud del producto antes de la reunin, se pide a cada asistente que elabore una lista de objetos que sean parte del ambiente que rodear al sistema, los objetos que producir ste y los que usar para realizar sus funciones. Adems, se solicita a cada asistente que haga otra lista de servicios (procesos o funciones) que manipulen o interacten con los objetos. Por ltimo, tambin se desarrollan listas de restricciones (por ejemplo, costo, tamao, reglas del negocio, etc.) y criterios de desempeo (como velocidad y exactitud). Se informa a los asistentes que no se espera que las listas sean exhaustivas, pero s que reflejen la percepcin que cada persona tiene del sistema.

Entre los objetos descritos por CasaSegura tal vez estn incluidos el panel de control, detectores de humo, sensores en ventanas y puertas, detectores de movimiento, alarma, un evento (activacin de un sensor), una pantalla, una computadora, nmeros telefnicos, una llamada telefnica, etc. La lista de servicios puede incluir configurar el sistema, preparar la alarma, vigilar los sensores, marcar el telfono, programar el panel de control y leer la pantalla (observe que los servicios actan sobre los objetos). En forma similar, cada asistente desarrollar una lista de restricciones (por ejemplo, el sistema debe reconocer cuando los sensores no estn operando, debe ser amistoso con el usuario, debe tener una interfaz directa con una lnea telefnica estndar, etc.) y de criterios de desempeo (un evento en un sensor debe reconocerse antes de un segundo, debe implementarse un esquema de prioridad de eventos, etctera).

Las listas de objetos pueden adherirse a las paredes del cuarto con el empleo de pliegos de papel grandes o con lminas adhesivas, o escribirse en un tablero. Alternativamente, las listas podran plasmarse en un boletn electrnico, sitio web interno o en un ambiente de grupo de conversacin para revisarlas antes de la reunin. Lo ideal es que cada entrada de las listas pueda manipularse por separado a fin de combinar las listas o modificar las entradas y agregar otras. En esta etapa, estn estrictamente prohibidos las crticas y el debate.

Una vez que se presentan las listas individuales acerca de un rea temtica, el grupo crea una lista, eliminando las entradas redundantes o agregando ideas nuevas que surjan durante el anlisis, pero no se elimina ninguna. Despus de crear listas combinadas para todas las reas temticas, sigue el anlisis, coordinado por el facilitador. La lista combinada se acorta, se alarga o se modifica su redaccin para que refleje de manera apropiada al producto o sistema que se va a desarrollar. El objetivo es llegar a un consenso sobre la lista de objetos, servicios, restricciones y desempeo del sistema que se va a construir.En muchos casos, un objeto o servicio descrito en la lista requerir mayores explicaciones. Para lograr esto, los participantes desarrollan mini especificaciones para las entradas en las listas. Cada mini especificacin es una elaboracin de un objeto o servicio. Por ejemplo, la correspondiente al objeto Panel de control de Casa Segura sera as:

El panel de control es una unidad montada en un muro, sus dimensiones aproximadas son de 9 por 5 pulgadas. Tiene conectividad inalmbrica con los sensores y con una PC. La interaccin con el usuario tiene lugar por medio de un tablero que contiene 12 teclas. Una pantalla de cristal lquido de 3 por 3 pulgadas brinda retroalimentacin al usuario. El software hace anuncios interactivos, como eco y funciones similares.

Las mini especificaciones se presentan a todos los participantes para que sean analizadas. Se hacen adiciones, eliminaciones y otras modificaciones. En ciertos casos, el desarrollo de las mini especificaciones descubrir nuevos objetos, servicios o restricciones, o requerimientos de desempeo que se agregarn a las listas originales. Durante todos los anlisis, el equipo debe posponer los aspectos que no puedan resolverse en la reunin. Se conserva una lista de aspectos para volver despus a dichas ideas.

5.3.2 Despliegue de la funcin de calidad

El despliegue de la funcin de calidad (DFC) es una tcnica de administracin de la calidad que traduce las necesidades del cliente en requerimientos tcnicos para el software. El DFC se concentra en maximizar la satisfaccin del cliente a partir del proceso de ingeniera del software [Zul92]. Para lograr esto, el DFC pone el nfasis en entender lo que resulta valioso para el cliente y luego despliega dichos valores en todo el proceso de ingeniera. El DFC identifica tres tipos de requerimientos [Zul92]:Requerimientos normales. Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el cliente. Si estos requerimientos estn presentes, el cliente queda satisfecho. Ejemplos de requerimientos normales son los tipos de grficos pedidos para aparecer en la pantalla, funciones especficas del sistema y niveles de rendimiento definidos.

Requerimientos esperados. Estn implcitos en el producto o sistema y quiz sean tan importantes que el cliente no los mencione de manera explcita. Su ausencia causar mucha insatisfaccin. Algunos ejemplos de requerimientos esperados son: fcil interaccin humano/mquina, operacin general correcta y confiable, y facilidad para instalar el software.

Requerimientos emocionantes. Estas caractersticas van ms all de las expectativas del cliente y son muy satisfactorias si estn presentes. Por ejemplo, el software para un nuevo telfono mvil viene con caractersticas estndar, pero si incluye capacidades inesperadas (como pantalla sensible al tacto, correo de voz visual, etc.) agrada a todos los usuarios del producto.Aunque los conceptos del DFC son aplicables en todo el proceso del software [Par96a], hay tcnicas especficas de aqul que pueden aplicarse a la actividad de indagacin de los requerimientos. El DFC utiliza entrevistas con los clientes, observacin, encuestas y estudio de datos histricos (por ejemplo, reportes de problemas) como materia prima para la actividad de recabacin de los requerimientos. Despus, estos datos se llevan a una tabla de requerimientos llamada tabla de la voz del cliente que se revisa con el cliente y con otros participantes. Luego se emplean varios diagramas, matrices y mtodos de evaluacin para extraer los requerimientos esperados y tratar de percibir requerimientos emocionantes [Aka04].

5.3.3 Escenarios de uso

A medida que se renen los requerimientos, comienza a materializarse la visin general de funciones y caractersticas del sistema. Sin embargo, es difcil avanzar hacia actividades ms tcnicas de la ingeniera de software hasta no entender cmo emplearn los usuarios finales dichas funciones y caractersticas. Para lograr esto, los desarrolladores y usuarios crean un conjunto de escenarios que identifican la naturaleza de los usos para el sistema que se va a construir. Los escenarios, que a menudo se llaman casos de uso [Jac92], proporcionan la descripcin de la manera en la que se utilizar el sistema. Los casos de uso se estudian con ms detalle en la seccin 5.4.

5.3.4 Indagacin de los productos del trabajo

Los productos del trabajo generados como consecuencia de la indagacin de los requerimientos variarn en funcin del tamao del sistema o producto que se va a construir. Para la mayora de sistemas, los productos del trabajo incluyen los siguientes:

Un enunciado de la necesidad y su factibilidad.

Un enunciado acotado del alcance del sistema o producto.

Una lista de clientes, usuarios y otros participantes que intervienen en la indagacin de los requerimientos.

Una descripcin del ambiente tcnico del sistema.

Una lista de requerimientos (de preferencia organizados por funcin) y las restricciones del dominio que se aplican a cada uno.

Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o producto en diferentes condiciones de operacin.

Cualesquiera prototipos desarrollados para definir requerimientos. Cada uno de estos productos del trabajo es revisado por todas las personas que participan en la indagacin de los requerimientos.