DISCIPLINA DE REQUERIMIENTOS

Requerimientos
Propósito
• Establecer y mantener el acuerdo con los clientes y otros stakeholders en lo que el sistema debe hacer. • Proporcionar a los diseñadores del sistema un buen entendiendo de los requerimientos del sistema. • Definir los límites de (fronteras) el sistema. • Proveer una base para la planificación del contenido técnicos de iteraciones. • Proveer una base para la estimación de costo y tiempo para desarrollar el sistema. • Definir una interfaz de usuario para el sistema, enfocando en las necesidades y metas de los usuarios.
TOPICOS AVANZADOS II

DISCIPLINA DE REQUERIMIENTOS

Requerimientos

TOPICOS AVANZADOS II

DISCIPLINA DE REQUERIMIENTOS

Requerimientos: Actividades

TOPICOS AVANZADOS II

DISCIPLINA DE REQUERIMIENTOS Requerimientos: Artefactos TOPICOS AVANZADOS II .

un modelo de casos de uso. los casos de uso y la Especificación Suplementaria son desarrollados para describir el sistema totalmente .en un esfuerzo que ven todos los stakeholders. TOPICOS AVANZADOS II . como las fuentes importantes de información (además de los requerimientos del sistema).lo que el sistema hará . incluso clientes y los usuarios potenciales.DISCIPLINA DE REQUERIMIENTOS Requerimientos Los Artefactos Un documento Visión.

El documento de Visión mantiene la base contractual de los requerimientos visible a los stakeholders. Cada proyecto necesita una fuente para capturar las expectativas de los stakeholders. El documento visión es escrito desde perspectiva de los clientes. enfocándose en los rasgos esenciales del sistema y los niveles aceptables de calidad. el perfil del usuario (quién estará usando el sistema).DISCIPLINA DE REQUERIMIENTOS Requerimientos Los Artefactos – El documento Visión El documento Visión provee una visión completa del sistema de software bajo el desarrollo y apoya el contrato entre los procuradores y la organización de desarrollo. TOPICOS AVANZADOS II . También debe especificar las capacidades operacionales. La Visión debe incluir una descripción de qué rasgos serán incluidos así como aquéllos que se consideraron pero no se incluyeron. y las interfaces interoperacionales con las entidades fuera del límite del sistema dónde sea aplicable.

TOPICOS AVANZADOS II . implementación y prueba. lo cual permite que: • Los Clientes y usuarios puedan validar que el sistema se volverá lo que ellos esperaron. Cada caso de uso en el modelo se describe en detalle. el mismo modelo de caso de usos se usa en el análisis del sistema. • Los Diseñadores del sistema puedan construir lo que se espera. diseño. mostrando paso a paso cómo el sistema actúa recíprocamente con los actores. y lo que el sistema hace en el caso de uso. los usuarios. La función de casos de uso unificar a lo largo del ciclo de vida del software. El modelo de casos de uso consiste en casos de uso y actores. y los diseñadores del sistema con respecto a la funcionalidad del sistema.DISCIPLINA DE REQUERIMIENTOS Requerimientos Los Artefactos – El Modelo de Casos de Uso El modelo de casos de uso debe servir como un medio de comunicación y puede servir como un contrato entre el cliente.

y controlar los cambios a los requerimientos del producto. informar. TOPICOS AVANZADOS II . Los Artefactos – Plan de Administración de Requerimientos Un Plan de Administración de Requerimientos especifica la información y los mecanismos de control que se definirán y usarán para medir. porque juntos capturan todos los requerimientos del software (funcionales y no funcionales) que son necesarios para servir como una especificación de requerimientos de software completa.DISCIPLINA DE REQUERIMIENTOS Requerimientos Los Artefactos – Las Especificaciones Suplementarias Las Especificaciones Suplementarias son un complemento importante del modelo de casos de uso.

Estos artefactos mantienen los mecanismos de la retroalimentación importantes en las iteraciones posteriores para descubrir los requerimientos desconocidos o inciertos.DISCIPLINA DE REQUERIMIENTOS Requerimientos Los Artefactos – Otros artefactos complementarios Complementariamente a los anteriores artefactos. TOPICOS AVANZADOS II . El Storyboard de los Casos de Uso y el Prototipo de la Interfaz de Usuario son resultados de Modelado de la Interfaz de Usuario y Prototipado que se hace en paralelo con otras actividades de requerimientos. los artefactos siguientes también se desarrollan: • Glosario • Storyboard de los Casos de Uso • Prototipo de la Interfaz de Usuario El Glosario es importante porque define una terminología común que se usa de forma consistente por el proyecto u organización.

TOPICOS AVANZADOS II . aplicado al modelo de caso de usos. • El Análisis y Diseño es la disciplina que consigue su entrada primaria (el modelo de casos de uso y el glosario) de los Requerimientos. incluyendo el Modelo de Dominio y un contexto organizacional para el sistema.DISCIPLINA DE REQUERIMIENTOS Requerimientos Relación con Otras Disciplinas • La disciplina de Modelado de Negocio proporciona a las Reglas de Negocio. Los Casos del uso y las Especificaciones Suplementarias proporcionan la entrada en requerimientos usados para planear y diseñar las pruebas. el Modelo de Casos de Uso de Negocio y una Modelo del Objeto de Negocio. se generan las demandas de cambio. • La disciplina de Prueba. Pueden descubrirse fallas en el modelo caso de uso durante el análisis & diseño. prueba el sistema para verificar el código contra el modelos de casos de uso.

El modelo de casos de uso y el Plan de Administración de Requerimientos son las entradas importantes para la planificación de las actividades de cada iteración. El mecanismo para proponer un cambio es someter una Demanda de Cambio la cual es revisada por todo el Equipo de Control de Cambio. • La disciplina de Ambiente desarrolla y mantiene los artefactos de apoyo que se usan durante la administración de requerimientos y el modelado de los casos de uso. • La disciplina de Administración de Proyecto planea el proyecto y cada iteración (descrito en un Plan de la Iteración). así como las Pautas de Modelado de Caso de Uso y Pautas de Interfaz Usuario TOPICOS AVANZADOS II .DISCIPLINA DE REQUERIMIENTOS Requerimientos Relación con Otras Disciplinas • La disciplina de Configuración y Administración del Cambio provee el mecanismo de control de cambio de los requerimientos.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Un requerimiento se define como "una condición o capacidad a que un sistema debe contener. Una categorizarlos es descrita como modelo FUCDS+ [GRA92]: Funcionalidad Usabilidad Confiabilidad Desempeño Soporte El "+" en FUCDS+ le recuerda que incluya los tales requerimientos como: • • • • Diseño de restricciones Requerimientos de aplicación Requerimientos de interfaz Requerimientos físicos manera de TOPICOS AVANZADOS II .“ Hay muchos tipos diferentes de requerimientos.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Funcionalidad • • • • Los requerimientos funcionales pueden incluir: Las Características las Capacidades la Seguridad Usabilidad • • • • • • • • Los requerimientos de usabilidad pueden incluir subcategorías como: Factores Humanos Estética la consistencia en la interfaz del usuario (vea las Pautas: La usuariointerfaz) la ayuda en línea y contexto-sensible los wizards y agentes la documentación del usuario los materiales de entrenamiento TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Confiabilidad • • • • • • Los requerimientos de confiabilidad a ser considerado son: La frecuencia y severidad de la falla Capacidad de recuperación Previsibilidad Exactitud El tiempo entre fallas (MTBF) TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Desempeño Un requerimiento de desempeño impone las condiciones sobre los requerimientos funcionales. puede especificar los parámetros de desempeño para: • la velocidad • la eficacia • la disponibilidad • la exactitud • el tiempo de respuesta • el tiempo de la recuperación • el uso del recurso TOPICOS AVANZADOS II . Por ejemplo. para una acción dada.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Soporte o Supportability Los requerimientos de Soporte pueden incluir: • La testability o capacidad de prueba: el grado a que un sistema o el componente facilita el establecimiento de criterio de la prueba y el desempeño de las pruebas para determinar si los criterios se han conseguido [IEEE 90]. u otros atributos. o adaptarse a un ambiente cambiante. Nota: testability no es sólo una medida para el software. mejorar su desempeño. • La mantenibilidad la facilidad con que un sistema de software o componente puede modificarse para corregir las fallas. TOPICOS AVANZADOS II . • La adaptabilidad la facilidad con que el software satisface diferentes restricciones del sistema y necesidades del usuario. también puede aplicar a los esquema de prueba. • La compatibilidad la habilidad de dos o más sistemas o componentes de realizar sus funciones requeridas mientras comparten el mismo hardware o ambiente del software.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Soporte o Supportability Los requerimientos de Soporte pueden incluir: • La capacidad de servicio o serviceability • La instalabilidad: de fácil instalación • La locabilizacion: El proceso de adaptar un programa para un mercado internacional específico que incluye traducción de la interfaz del usuario. el resizing de las cajas de dialogo. y probar los resultados para asegurar que el programa todavía trabaja. TOPICOS AVANZADOS II . personalizando características (si necesario). • La Internacionalización: El proceso de desarrollar un programa central cuyas características de diseño y diseño del código no hace asunciones basadas en un solo idioma o sitio y de quien la base de código de fuente simplifica la creación de ediciones del idioma diferentes de un programa.

Los ejemplos son: • las normas requeridas • los idiomas de aplicación • las políticas para la integridad de la base de datos • los límites del recurso • los ambientes de operación restricción de diseño. a menudo llamado una especifica o restringe el diseño de un sistema Requerimientos de Implementación Un requerimiento de implementación especifica o restringe la codificación o construcción de un sistema. TOPICOS AVANZADOS II .DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Requerimientos de Diseño Un requerimiento diseño.

como las configuraciones de la red físicas requeridas. por ejemplo. TOPICOS AVANZADOS II .DISCIPLINA DE REQUERIMIENTOS Conceptos: Requerimientos Requerimientos de Interfaz Un requerimiento de interfaz especifica: • un ítem externo con el cual el sistema debe interactuar • una restricción de formato. tiempo u otros factores usados en la interacción Requerimiento Físico Un requerimiento físico especifica una característica física que un sistema debe poseer. • material • forma • tamaño • peso Este tipo de requerimiento puede usarse representar los requerimientos del hardware.

sin embargo. y puede venir de muchas fuentes. TOPICOS AVANZADOS II . Recolectar requerimientos puede parecer una tarea bastante sencilla. En los proyectos reales. organizar.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos ¿Que es la Administración de Requerimientos? La administración de requerimientos es que es un acercamiento sistemático a determinar. usted se encontrará con dificultades debido a: Los requerimientos no siempre son obvios. La clave de una administración efectiva de los requerimientos incluye mantener una declaración clara de los requerimientos. y establecer y mantener el acuerdo entre el cliente y el equipo de proyecto en relación con los requerimientos cambiantes del sistema. Los requerimientos no siempre son fáciles de expresar claramente en las palabras. y documentar los requerimientos del sistema. junto con los atributos aplicables para cada tipo de requerimiento y el seguimiento con otros requerimientos y otros artefactos del proyecto.

Hay que muchas partes interesadas. E igualmente. Para ayudarle a manejar estas dificultades. los requerimientos cambian.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos ¿Que es la Administración de Requerimientos? Hay muchos tipos diferentes de requerimientos a diferentes niveles de detalle y también se relacionan entre si y con otros entregables del proceso de ingeniería de software. las habilidades siguientes son importantes: • El análisis del problema • Comprender las necesidades del stakeholder • Definir el sistema • Manejar el alcance del proyecto • Refinar la definición del sistema • Manejar los requerimientos cambiantes TOPICOS AVANZADOS II . lo que significa que los requerimientos necesitan ser manejados por los grupos de personas que realizan distintas funciones.

así como los las restricciones de negocio que atañen a la solución. y proponer soluciones de alto nivel. Se debe de haber analizado el caso de negocio para el proyecto. las necesidades iniciales de los stakeholder. TOPICOS AVANZADOS II .DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Análisis del Problema El análisis del problema se hace para entender los problemas. También. para que exista un buen entendimiento del retorno que se espera en la inversión hecha en el sistema a construirse. Es un acto de razonar y analizar para encontrar "el problema detrás del problema". se busca llegar al/los problem(as) real(es). y determinar quién son los stakeholders. Durante el análisis del problema. se define desde la perspectiva de negocio cuales son los límites de la solución.

los ejemplos serían clientes. TOPICOS AVANZADOS II . y expertos del dominio. acceder a esas fuentes. Si usted está desarrollando un sistema de información a ser usado internamente dentro de su compañía. usted puede incluir en el proyecto a personas como: el usuario final con experiencia y al especialista de dominio del negocio en su equipo de desarrollo. usuarios finales. Usted necesita saber cómo determinar las mejores fuentes. y también cómo obtener la mejor información de ellos. Si usted está desarrollando un producto a ser vendido a un lugar del mercado.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Entendiendo las Necesidades de los Stakeholders Los requerimientos provienen de muchas fuentes. socios. usted puede hacer uso extenso de sus personas de mercadeo para entender bien las necesidades de los clientes en ese mercado.

y que se han priorizado entre si. TOPICOS AVANZADOS II . El resultado del estas actividades es una lista de demandas o necesidades que se describen textual y gráficamente. encuestas. y el análisis competitivo. tormenta de ideas.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Entendiendo las Necesidades de los Stakeholders Las actividades para descubrir requerimientos pueden requerir el uso de técnicas como: entrevistas. prototipos conceptuales.

Parte de esta actividad puede incluir los prototipos tempranos y el modelo de diseño directamente relacionado a las demandas de los stakeholders más importantes. y el alcance inicial.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Definiendo el Sistema Definir el sistema significa traducir y organizar las necesidades de los stakeholders en una descripción significante del sistema a ser construido. El resultado de definición del sistema es una descripción del sistema en lenguaje natural y gráfico. Temprano en la definición del sistema. el grado de especificidad de requerimientos (cuántos y en qué detalle). la prioridad requerida y el esfuerzo estimado. las decisiones son hechas sobre qué constituye un requerimiento. TOPICOS AVANZADOS II . la formalidad del idioma. técnico y manejo de riesgos. el formato de la documentación.

se debe desarrollar el sistema incrementalmente. Demasiado proyectos sufren de desarrolladores trabajando en lo llamado "Easter eggs“ (características que el desarrollador cree interesante y desafiante) en vez de enfocarse en las tareas que pueden minimizar riesgo en el proyecto o estabilizar la arquitectura de la aplicación. Para hacer esto. es necesario negociar el alcance (de cada iteración) con los stakeholders del proyecto. es necesario priorizar cuidadosamente los requerimientos.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Manejando el Alcance del Proyecto Para una eficiente acometida de un proyecto. basado en las entradas proveídas por los stakeholders y administrando su alcance. escogiendo los requerimientos cuidadosamente para cada incremento. TOPICOS AVANZADOS II . Para asegurarse que se resuelve o mitiga los riesgos lo más pronto posible en un proyecto.

desempeño. Usted puede ver a menudo una necesidad de producir tipos diferentes de descripción para públicos diferentes. es una manera muy eficaz de comunicar el propósito del sistema y definir los detalles del sistema. Se sabe que la metodología de casos de uso. sino también con cualquier requerimiento legal o regulador. a menudo en combinación con los prototipos visuales simples. Necesita no sólo cubrir la funcionalidad.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Refinando la Definición del Sistema La definición detallada del sistema necesita ser presentada de tal manera que sus stakeholders pueden entender y estar de acuerdo con esta. fiabilidad. TOPICOS AVANZADOS II . soportabilidad y mantenibilidad. Los casos de uso ayudan a colocar los requerimientos en un contexto. usabilidad. Usted debe hacer el esfuerzo para que la audiencia entienda los documentos que se están produciendo para describir el sistema. ya que ellos muestran cómo el sistema se usará.

TOPICOS AVANZADOS II .DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Refinando la Definición del Sistema Otro componente de la definición detallada del sistema es declarar cómo el sistema debe probarse. Los planes de la prueba y definiciones de qué pruebas se van a realizar dicen qué capacidades del sistema se verificarán.

y que se usan los links de traceabilidad para representar las dependencias entre los requerimientos y otros artefactos del ciclo de vida del desarrollo. sino que un cambio en un requerimiento puede tener impacto en otros requerimientos.DISCIPLINA DE REQUERIMIENTOS Conceptos: Administración de Requerimientos Administrando los Cambios de Requerimientos No importa cuan cuidadoso sea usted para definir sus requerimientos. TOPICOS AVANZADOS II . establecer la traceabilidad entre los artículos relacionados. habrá siempre cosas que cambian. y el control de cambio. Es necesario asegurarse de poseer una estructura de sus requerimientos que es elástica a los cambios. determinar cuales dependencias son importantes rastrear. La administración del cambio las actividades como establecer una línea base. Lo que hace complejo de manejar los requerimientos cambiantes no es sólo lo que implica un requerimiento cambiado o el tiempo tiene que ser gastado en llevar a cabo una nueva característica en particular.

modelos de análisis y diseño de elementos. sobre todo aquéllos requerimientos relacionados. los procedimientos de la prueba. Elementos del proyecto involucrados en la traceabilidad se llaman “artículos del traceabilidad”. artefactos de pruebas (los casos de prueba. y documentación de apoyo del usuario final y material de entrenamiento. etc. Los artículos del traceabilidad típicos incluyen diferentes tipos de requerimientos.). TOPICOS AVANZADOS II .DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad Introducción Traceabilidad es la habilidad de rastrear un elemento del proyecto con otros elementos relacionados del proyecto.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad Propósito de la Traceabilidad • • • • • • Entender la fuente de requerimientos Manejar el alcance del proyecto Manejar los cambios a los requerimientos Evaluar el impacto en el proyecto de un cambio en un requerimiento Evalar el impacto de un fracaso de una prueba en los requerimientos (es decir si las faltas de la prueba el requerimiento no puede satisfacerse) Verificar que todos los requerimientos del sistema son cumplidos por la aplicación. TOPICOS AVANZADOS II . • Verificar que la aplicación hace lo que se pensaba que hacía.

a su vez. etc. El modelo de casos de uso. con otros requerimientos importantes (como los requerimientos no funcionales. TOPICOS AVANZADOS II . así como las reglas de negocio y los requerimientos de los stakeholders. se traduce en un juego de necesidades stakeholder/usuarios y características del sistema.) en las Especificaciones Suplementarias. define cómo las características se traducen en la funcionalidad del sistema. especificados en el documento de Visión.DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad Propósito de la Traceabilidad La traceabilidad le ayuda a entender y manejar la entrada de los requerimientos. restricciones de diseño. Los detalles de cómo el sistema interactua con el mundo externo se captura en los casos del uso.

Un concepto importante para ayudar a manejar los cambios en los requerimientos es marcar links de traceabilidad sospechosas. Para un sistema grande. Esto hace que el rol responsable deba repasar el cambio y determinar si los artículos asociados necesitarán también cambiar.DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad Propósito de la Traceabilidad La traceabilidad le permite también seguir cómo estas característica técnicas detalladas se traducen en un diseño. use pueden empaquetarse casos y las Característica técnicas Suplementarias juntas para definir una Especificación de Requerimientos de Software (SRS) para una caracteristica particular u otra agrupación del subsistema. Cuando un requerimiento (u otro artículo del traceabilidad) cambia. TOPICOS AVANZADOS II . y cómo se documenta para el usuario. cómo se prueba. todos los eslabones asociados con ese requerimiento son marcados como sospechosos. Este concepto también ayuda analizar el impacto de cambios potenciales.

Cuales son todos los requerimientos suplementarios unidos a pruebas cuyo estado es el no probados. Cuales son los resultados de todas las pruebas que fallaron. Cual es el estado de pruebas en todos los casos del uso en la iteración #n.DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad Propósito de la Traceabilidad La Traceabilidad puede ayudar en: Cuales necesidades del usuario que no se unen a las caracteristicas del producto. en el orden critico. TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad Traceabilidad Típica Los artículos del traceabilidad más importantes son: • • • Necesidades de Usuarios/Stakeholder (del documento Visión. El Caso de prueba (u otro elemento del modelo de la prueba). Elemento de Diseño (del modelo de diseño). TOPICOS AVANZADOS II . puede remontarse más allá a las Demandas de Stakeholder individuales) Las Características del producto (del documento Visión).) • • • • Caso de Uso La Sección de Casos de Usos (secciones de un caso del uso detallado). Requerimientos suplementarios (de las Especificaciones Suplementarias.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Traceability o Traceabilidad TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Conceptos: Tipos de Requerimiento Tradicionalmente." La noción de tipos de requerimientos es para ayudar separando los niveles diferentes de abstracción y propósitos de nuestros requerimientos. Cada requerimiento declara "una condición o capacidad que el sistema debe conformar. los requerimientos parecen declaraciones de texto que encaja en una de las categorías mencionadas en el Concepto: Los requerimientos. TOPICOS AVANZADOS II . Las Especificaciones Suplementarias pueden contener otros "requerimientos del software". El documento Visión nos ayuda a guardar rastros de "necesidades clave de los usuario " y características del sistema. como restricciones de diseño o los requerimientos legales o reguladores en nuestro sistema. El modelo del casos de uso es una manera eficaz de expresar los "requerimientos funcionales del software" detallados. por consiguiente los casos de uso pueden necesitar ser rastreados y mantenidos como requerimientos.

La vista de casos de usos es refinada y considerada inicialmente en cada iteración. clases. TOPICOS AVANZADOS II .DISCIPLINA DE REQUERIMIENTOS Conceptos: Vista de Casos de Uso Hay sólo una vista de casos de uso del sistema que ilustra los casos de uso y los escenarios que abarcan arquitecturalmente una conducta significante. o los riesgos técnicos.

diseño. Así que. Las vistas arquitectónicas se documentan en un Documento de Arquitectura de Software. sobre todo durante la fase de la Elaboración. para llevar otros aspectos específicos de la arquitectura del software. en esencia. La arquitectura se representa por varias vistas arquitectónicas diferentes que en su esencia son extractos que ilustran los elementos "arquitecturalmente significantes" de los modelos. y Vista de Implementación. Hay cuatro vistas: la Vista Lógica.DISCIPLINA DE REQUERIMIENTOS Conceptos: Vista de Casos de Uso Las actividades de análisis. las vistas arquitectónicas pueden ser vistas como abstracciones o simplificaciones de los modelos construidos. en las cuales se hacen más visible las características mas importantes dejando los detalles al lado. como una vista de seguridad. Vista del Proceso. TOPICOS AVANZADOS II . La producción y validación de esa arquitectura es el enfoque principal de las iteraciones tempranas. Vista del Despliegue. Usted puede agregar vistas diferentes. e implementación subsecuentes a los requisitos se centra en la noción de una arquitectura. La arquitectura es un medio importante para aumentar la calidad de cualquier modelo construido durante el desarrollo del sistema.

John Gould y sus colegas de IBM desarrollaron un acercamiento en la década de los 1980 llamado Diseñando para Usabilidad qué abarca la mayoría de las definiciones normalmente aceptadas. Sin embargo. Este fue desarrollado de la experiencia práctica en varios sistemas interactivos.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Qué es el diseño centrado en el usuario? No hay ningún acuerdo general claro en lo que constituye el diseño centrado en el usuario. El acercamiento tiene cuatro componentes principales como se describen a continuación. • • • • Enfocado en el Usuario Integrado con el diseño Pruebas de Usuario Tempranas Diseño iterativo TOPICOS AVANZADOS II . el más notable en 1984” Sistema de Mensajería de los Juegos Olímpicos” de IBM .

DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Enfocado en el Usuario Gould sugiere que los desarrolladores deban decidir quienes serán los usuarios y como involúcralos a ellos en la brevedad posible. Mismo • Consiga que los usuarios piensen en alto mientras trabajan • Diseño Participativo • Incluya a los usuarios expertos en el equipo de diseño • Realice análisis de las tareas • Haga uso de cuestionarios y encuestas • Desarrolle las metas probables TOPICOS AVANZADOS II . sus tareas y requisitos: • Hable con los usuarios • Visite las oficinas del cliente · • Observe a usuarios trabajar • el Vídeo de los usuarios trabajando • Aprenda sobre la organización de trabajo • Pruébelo ud. Él sugiere un numero de maneras para familiarizarse con los usuarios.

pero éstos deben complementarse por los tipos de actividades que Gould describe.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Enfocado en el Usuario En RUP. debido a que parte del argumento detrás de esto es que las personas frecuentemente describen lo de que ellos hacen bastante diferentemente a cómo ellos lo hacen. TOPICOS AVANZADOS II . Se olvidan a menudo de las tareas normalmente realizadas y detalles aparentemente insignificantes como el lugar de trabajo o la existencia de trozos "misteriosos" de papel o los omitió porque ellos no son "oficialmente" parte del proceso actual. se usan los talleres en varias etapas claves.

Ésta es una diferencia importante entre el diseño centrado en el usuario y otras técnicas completamente incrementales.el framework . Esto asegura que el diseño incremental es llevado a cabo en las subsiguientes fases permite que le framework y que la interfaz del usuario sea consistente en apariencia.para el diseño detallado de la interfaz usuario. Una característica importante del diseño integrado es el acercamiento global . Gould también hace resaltar que la usabilidad debe ser responsabilidad de un grupo.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Integrado con el diseño Las tareas de Usabilidad deben realizarse desde temprano en el desarrollo. terminología y concepto. TOPICOS AVANZADOS II . Estas tareas incluirían el esbozo de la interfaz del usuario y el bosquejo del manual de usuario o la ayuda en línea. el cual es desarrollado y probado en una fase temprana.

sino que también mejora el reuso de componentes de interfaz. usuario) TOPICOS AVANZADOS II . muchas de las clases de dominio se representarán como las clases de frontera en la interfaz. (Esto no sólo ayuda a los usuarios. Como el diseño de interfaz de usuario progresa en la disciplina de requerimientos. Las clases de frontera. y las relaciones entre ellas. debe ser consistente con el modelo de dominio y debe representarse de forma consistente a través de todas las partes del sistema en diseño. este framework puede establecerse usando un modelo de dominio para asegurar que toda la terminología y conceptos que aparecerán en la interfaz del usuario son conocidos y entendidos en general dentro del negocio y con los usuarios en particular.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Integrado con el diseño Dentro del RUP.

TOPICOS AVANZADOS II . narrativa ilustrada (usando el mockups para la ilustración). ellos son claramente más eficaces en costo que el descubrimiento de un diseño inapropiado o los requisitos entendidos mal una vez la implementación esta en marcha. storyboards. etc. típicamente los dibujos y mockups describieron como los prototipos de bajo-fidelidad. Éstos pueden tomar forma narrativa. Mockups puede usarse junto con los casos de uso para escribir escenarios concretos de uso para el sistema bajo diseño. Mientras estos acercamientos son poco familiares a muchos diseñadores del software.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Pruebas de Usuario Tempranas Las pruebas de usuario tempranas del prototipo. Los prototipos envolventes seguirán después en el proceso.

Note que en los métodos centrados a usuario. El diseño iterativo es bueno para problemas que necesitan un refinado entendimiento y poseen requisitos cambiantes. el diseño iterativo tiene lugar dentro de un framework integrado.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Diseño iterativo El desarrollo orientado a objetos se ha vuelto sinónimo de proceso iterativo. pero también la inherente complejidad de producir soluciones que pueden tratar con necesidades diversas. TOPICOS AVANZADOS II . Esto es con el tiempo en parte debido a las necesidades cambiantes de usuarios. El diseño iterativo es un componente importante de diseño centrado en el usuario.

DISCIPLINA DE REQUERIMIENTOS

Conceptos: Diseño Centrado en el Usuario
Por qué el diseño centrado en el Usuario?
Consiguiendo las Necesidades de los Usuarios Los sistemas interactivos confían en su habilidad para acomodar las necesidades de usuarios para su éxito. Esto significa no sólo identificando las comunidades del usuario diversas sino también reconociendo el rango de las habilidades, experiencia y preferencias de usuarios individuales. La atención frecuentemente se enfoca en cómo los usuarios deben realizar las tareas en lugar a cómo ellos prefieren realizarlas. En muchos casos el problema de preferencia es mucho más de simplemente sentirse en el mando, aunque ése es un problema importante en sí mismo. La preferencia también se determinará por la experiencia, habilidad y el contexto de uso. Estos características son considerados suficientemente importantes en el proceso de diseño para garantizar un estándar internacional, [ISO 13407], el titulado diseño centrado en el humano procesa para los sistemas interactivos.
TOPICOS AVANZADOS II

DISCIPLINA DE REQUERIMIENTOS

Conceptos: Diseño Centrado en el Usuario
Por qué el diseño centrado en el Usuario?
Diseño de Interfaz de Usuario Los usuarios entienden y actúan recíprocamente con un sistema a través de su interfaz de usuario. Los conceptos, imágenes y terminología presentadas en la interfaz deben ser apropiadas a las necesidades de usuarios. Por ejemplo, un sistema que les permite a clientes comprar sus propios boletos sería muy diferente a usado profesionalmente por el personal de ventas de boleto. Las diferencias principales no están en los requisitos o en los casos de uso detallados, pero si en las características de los usuarios y los ambientes en que los sistemas podrían operar.

TOPICOS AVANZADOS II

DISCIPLINA DE REQUERIMIENTOS

Conceptos: Diseño Centrado en el Usuario
Por qué el diseño centrado en el Usuario?
Diseño de Interfaz de Usuario La interfaz del usuario también debe servir para una amplia gama de experiencia a lo largo de por lo menos dos dimensiones, computadora y experiencia del dominio, ver Figura 1. La experiencia de la computadora no sólo incluye la familiaridad general con las computadoras, sino también la experiencia del sistema bajo el desarrollo. Los usuarios con poca experiencia con las computadoras o el dominio del problema, están ubicados en la esquina izquierda cercana de la figura, requerirán un acercamiento substancialmente diferente en la interfaz del usuario a los usuarios especialistas, mostrados aquí en la esquina derecha lejana.

TOPICOS AVANZADOS II

DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Diseño de Interfaz de Usuario TOPICOS AVANZADOS II .

fácil de recordar) Fácil aprender y recordar. web (los hipervínculos) o estilo de interfaz de menú (la pregunta y respuesta o formulario de llenado simple serían muy frustrantes para los usuarios experimentados) La terminología dominio específica y conceptos Enfoque en la facilidad de uso (directo. con atajos (shortcuts) múltiples y técnicas para permitir el control del usuario Sofisticado con muchos los rasgos avanzados y personalizables. el estilo de la interfaz es simple. el formulario de llenado simple. Premiado para usar. poderoso sin parecer complejo.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Diseño de Interfaz de Usuario de interfaz de usuario Bajo La experiencia de la computadora Algunos factores que afectan el diseño Alto La pregunta simple y respuesta. El formulario de llenado complejo. La motivación TOPICOS AVANZADOS II . web (los hipervínculos) o estilo de interfaz de menú La experiencia del dominio Entrenamiento La frecuencia de uso La terminología y conceptos comunes Enfoque en la facilidad de aprender (consistente. predecible. personalizado) Fácil usar.

debemos evitar diseñar a humanos hipotéticos. TOPICOS AVANZADOS II . Éstos son un subconjunto de los Actores de Negocio humanos (para los usuarios fuera de del negocio) y los Trabajadores de Negocio encontrados al trabajar en la disciplina de Modelado de Negocio. este esfuerzo se enfoca en los usuarios finales.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Diseño centrado en el usuario en el RUP Desarrollar sistemas apropiadamente para las necesidades del usuario significa un esfuerzo significante en análisis de requerimientos. Sin embargo. un punto sustancial de énfasis en un diseño centrado en el usuario es lo que se entiende como los requisitos de las personas reales que llenarán los roles descritos en los artefactos arriba expresados. En particular. En el diseño centrado a usuario.

TOPICOS AVANZADOS II . y habla con el cliente sobre el trabajo. Cada uno tiene sus propios atributos y esto es llamado el contexto de uso. sino también de los usuarios. vaya donde el cliente trabaja.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Diseño centrado en el usuario en el RUP Los artefactos que describen a los usuarios finales sólo deben escribirse después del contacto sustancial.. Ellos se detallan en el estándar ISO para el diseño centrado en el usuario.“ Esta acometida no sólo se usa para tener un buen entendimiento de los requisitos del sistema.. En el diseño centrado en el usuario este contacto de primera mano es la parte de un proceso llamado la pregunta contextual. Hugh Beyer y Karen Holtzblatt (en su libro el Diseño Contextual) describa la premisa de pregunta contextual como: ". observa al cliente cuando él o ella trabajan. sus tareas y ambientes. de primera mano con los usuarios.

el software. los atributos físicos. los materiales. los ambientes físicos y sociales. la asignación de actividades. las capacidades Ambientes El hardware. frecuencia y duración de desempeño. las preferencias. TOPICOS AVANZADOS II . el ambiente del legislativo. el ambiente social y cultural.DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Diseño centrado en el usuario en el RUP Estándar ISO para el diseño centrado en el usuario Contexto Tareas Atributos Las metas de uso del sistema. las normas pertinentes. salud y consideraciones de seguridad. No deben describirse las tareas solamente por lo que se refiere a las funciones o rasgos proporcionados por un producto o sistema. el entrenamiento. la habilidad. los pasos operacionales entre el humano y los recursos tecnológicos. la experiencia. el ambiente técnico. los hábitos. la educación. Usuarios (for each different type or role) El conocimiento.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Diseño centrado en el usuario en el RUP Relaciones entre contextos TOPICOS AVANZADOS II .

Business Worker (internal users) Detailed: Actor High-level: Stakeholder Requests. Vision [Section: User Profiles] High-level: Business Actor (external users).DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Diseño centrado en el usuario en el RUP Estándares ISO para el diseño centrado a usuario para los contextos y los artefactos de RUP ISO 13407 Context Ambiente the RUP Artifact High-level: Business Vision [Section: Customer Environment]. Vision [Section: Product Features] Detailed: Use-Case Storyboard Use Case Usuarios Roles Tareas TOPICOS AVANZADOS II . Stakeholder Requests. Vision [Section: User Environment] High-level: Business Vision [Section: Customer Profiles]. Stakeholder Requests.

y Casos de Uso esenciales Caso de Uso genérico para retirar dinero de un telecajero User Action insert card enter PIN press key press key enter amount press key take card take cash TOPICOS AVANZADOS II System Response read magnetic strip request pint verify PIN display transaction option menu display account menu prompt for amount display amount return card dispense cash .DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Escenarios. Casos de Uso.

DISCIPLINA DE REQUERIMIENTOS Conceptos: Diseño Centrado en el Usuario Por qué el diseño centrado en el Usuario? Escenarios. y Casos de Uso esenciales Casos de Uso esenciales para retirar dinero de un telecajero User Intention identify self System Responsibility verify identity offer choices choose dispense cash take cash TOPICOS AVANZADOS II . Casos de Uso.

DISCIPLINA DE REQUERIMIENTOS Workflow Detail: Define the System TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Workflow Detail: Manage the Scope of the System TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Workflow Detail: Refine the System Definition TOPICOS AVANZADOS II .

DISCIPLINA DE REQUERIMIENTOS Workflow Detail: Manage Changing Requirements TOPICOS AVANZADOS II .