Plantilla de toma de requisitos softwarev 1.0

22.866 visualizaciones

Publicado el

Plantilla word para la toma de requisitos en proyectos de desarrollo de software. Independiente de la tecnología o el lenguaje de desarrollo .net o java. Especificación de Requisitos Software en la fase de análisis funcional. compatible con cualquier metodología de desarrollo, metrica 3, cascada, scrum, agile.
Basada en el ieee830.

Publicado en: Empresariales
3 comentarios
11 recomendaciones
Estadísticas
Notas
Sin descargas
Visualizaciones
Visualizaciones totales
22.866
En SlideShare
0
De insertados
0
Número de insertados
28
Acciones
Compartido
0
Descargas
1.299
Comentarios
3
Recomendaciones
11
Insertados 0
No insertados

No hay notas en la diapositiva.

Plantilla de toma de requisitos softwarev 1.0

  1. 1. Nombre del proyecto Especificación de Requisitos Ref: Fecha
  2. 2. 1 ACERCA DE ESTA PLANTILLA. Es relativamente sencillo encontrar una gran cantidad de documentación acerca de cómo realizar un documento de requisitos para los proyectos de desarrollo de software. Algunos ejemplos de interés se pueden encontrar en: http://cswww.essex.ac.uk/staff/turnr/cswww.essex.ac.uk_files/Mypapers/foundations- specification.pdf y en http://www.ctr.unican.es/asignaturas/is1/IEEE830_esp.pdf Esta plantilla se basaen el estándar del ieee830. En el que se realiza una propuesta coherente de todo lo que un documento de requisitos debería tener. Sin embargo, en la práctica, la plantilla propuesta por el propio documento no llega a la altura de las recomendaciones que sugiere. Esta plantilla es el resultado empírico de la toma de requisitos en una gran cantidad de proyectos, en los cuales era necesario muchas veces adecuarse a presupuestos y tiempos más limitados de lo deseable, con equipos de desarrollo poco homogéneos o con un perfil de “coder” más que de analista programador. La plantilla propuesta por el iee830 también tiene lagunas a la hora de especificar con detalle muchas tecnologías e incluso modas, pero sobre todo existe una falta absoluta de “Dominios”. Esto significa que la toma de requisitos debería estar sobre todo dirigida por el dominio del problema al que se pretende dar solución. Esta plantilla está dirigida de una forma genérica al desarrollo de aplicaciones de tipo LOB, (Line of Business), de tipo ERP (Enterprise Resource Planning) o de gestión. Pero no está especializada en áreas o sectores de negocio concretos. Esto es algo que permitirá proponer versiones con preguntas específicas del negocio. No deberían ser muchas y por tanto ánimo a todo aquel al que esta plantilla le resulte de utilidad que comparta las preguntas específicas que el mismo se haya encontrado en sus propios proyectos. Y de esta forma incrementar el número de autores que participan en esta plantilla. Para ello basta que me hagáis participes de vuestros comentarios y sugerencias, con el objeto de poder sacar versiones específicas para sectores de negocio concreto. La plantilla solo proporciona un punto de partida, una forma de evitar que un consultor aparezca con una hoja en blanco. Esperando que el cliente le cuente como funciona su negocio. Eso significara con bastante seguridad el fracaso del proyecto. El cliente nunca sabe describir cómo funciona su negocio, ni tampoco sabe lo que quiere. Solo sabe que necesita ayuda, que necesita sistematizar su negocio y añadirle una pequeña dosis de madurez sistematizando sus procesos con un software de apoyo. Pero el consultor se puede encontrar en una situación parecida, a no ser que sea la segunda vez que se enfrenta al problema. Esta plantilla no es que vaya a acudir al rescate del consultor, pero si proporciona las primeras preguntas. Por qué el trabajo de un consultor, no es dar respuestas, es realizar las preguntas adecuadas, en el orden correcto. Con el objetivo de reconducir las respuestas del cliente.
  3. 3. Customer Cuestionarios iníciales 3 Contenidos  1 Acerca de esta plantilla............................................................................... 2  OBJETO DEL DOCUMENTO................................................................................... 6  2 Organización del documento....................................................................... 7 2.1 Alcance del documento:.................................................................................. 7 2.2 documentos relacionados con el proyecto. ........................................................ 8 2.3 Nomenclaturas .............................................................................................10 2.4 Glosario, Conceptos, Convenciones o lenguaje específico del dominio..................10  3 Descripción............................................................................................... 11 3.1 Origen o Motivación del proyecto ....................................................................11 3.2 Contexto .....................................................................................................11 3.3 Control de Calidad ........................................................................................11  4 Perspectiva del Producto .......................................................................... 12 4.1 Identificación de usuarios y perfiles.................................................................12 4.2 Procesos y consultas .....................................................................................13 4.2.1 Restricciones y Políticas de la empresa..................................................15 4.2.2 Requisitos de Fiabilidad .......................................................................19 4.2.3 Requisitos de Disponibilidad.................................................................19 4.2.4 Requisitos de Mantenimiento................................................................19 4.2.5 Suposiciones y Dependencias...............................................................19 4.2.6 Requisitos Futuros ..............................................................................19 4.2.7 Funcionalidades que no realizara ..........................................................21 4.3 Relación con otros sistemas ...........................................................................22  5 Diseño ...................................................................................................... 23 5.1 Contexto Principios y Criterios ........................................................................23 5.2 Opciones de arquitectura. ..............................................................................24 5.3 Opciones alternativas ....................................................................................25 5.4 Requisitos Específicos....................................................................................26
  4. 4. Customer Cuestionarios iníciales 4 5.4.1 DESCRIPCION DEL ENTORNO DE DESARROLLO......................................26 5.5 Diseño de interfaces......................................................................................26 5.5.1 De usuario:........................................................................................27 5.5.2 Requerimientos de Accesibilidad y ergonomía ........................................27 5.5.3 Informes reporting y estadísticas..........................................................27 Funciones ............................................................................................................28 5.5.4 Módulos funcionales. Mapa de los módulos principales o Mapa de contextos limitados. DDD...............................................................................28 5.5.5 Procesos principales: ..........................................................................29  6 Objetos y modulos .................................................................................... 30 6.1 Personas, colectivos, organizaciones y roles. ....................................................31 6.1.1 Modulo personas, colectivos y entidades: ..............................................31 6.2 convenciones para el Diseño de pantallas ........................................................33
  5. 5. Customer Cuestionarios iníciales 5 Hoja de control Autor de la plantilla :Pulcker, descargado de SlideShare,Licencia de uso CreativeCommons Autor del documento: CREACIÓN 16 de julio del 2010 REVISADO POR FECHA APROBADO POR FECHA VERSIÓN FECHA COMENTARIO 1.0 Preparación Cuestionario entrevistas 1.1 Notas 1º entrevista
  6. 6. Customer Cuestionarios iníciales 6 OBJETO DEL DOCUMENTO El objeto de esta plantilla es servir de punto de arranque para la creación de documentos para la especificación de requisitos. Es conveniente evolucionar este documento a ir adaptándolo a diferentes contextos, añadiendo nuevas preguntas en función de los diferentes dominios de problemas en los que se vaya a utilizar de forma más común. Para cualquier sugerencia sobre su ampliación o duda sobre los conceptos utilizados pueden ponerse en contacto conmigo a través de mi correo electrónico en Slidesharepulcker El objeto del documento es servir de guía para las entrevistas de toma de requisitos con el cliente. De este documento se obtiene posteriormente un documento de requisitos. El documento se divide enlos siguientescapítulos y cada uno de ellos en un conjunto de secciones y estos en apartados que determinan los datos y la información a recoger durante las entrevistas de toma de requisitos para proyectos de desarrollo de software. Primer capitulo Organización del documento. Segundo Capitulo Descripción del proyecto / producto de software a desarrollar. Tercer Capitulo Elementos de Diseño del producto. Cuarto Capitulo Descripción de objetos de negocio. Anexos.
  7. 7. Customer Cuestionarios iníciales 7 2 ORGANIZACIÓN DEL DOCUMENTO. Nombre proyecto: Fecha de creación16/07/2010 13:58:00 Archivo: Cuaderno de campo Toma de Requisitos v 2.0.docx 2.1 ALCANCE DEL DOCUMENTO: El presente documento se utilizara para: Paso Concepto Objetivo OK A Establecer la definición inicial del cliente.   B Establecer la interpretación inicial del analista   C Confirmar y/o desechar con el cliente la interpretación de los requisitos   D Establecer la redefinición o dudas del analista.   E Obtener la especificación final de requisitos en doc adicional.  F Recoger la aceptación de requisitos. G Recoger las solicitudes de modificación. H Establecer los hitos iníciales del proyecto.  I Reflejar los hitos alcanzados. J Realizar seguimiento de los hitos. K Recoger las desviaciones del proyecto y sus causas. L Recoger la estimación de tiempos y costes. M Recoger la aprobación de tiempos y costes.  N Reflejar el cierre del proyecto. Ñ Recoger la aprobación de cierre del proyecto. Entregable Clasificación del documento: INTERNO, Calificación del documento: Operativo Cuestionario. Tipo de Proyecto, Producto Interno Licencia del Proyecto/ Producto Sujeto a estipulación del contrato de desarrollo Copyright Proyecto/Producto Sujeto a estipulación del contrato de desarrollo Versión: 
  8. 8. Customer Cuestionarios iníciales 8 2.2 DOCUMENTOS RELACIONADOS CON EL PROYECTO. doc Concepto Objetivo OK A Descripción inicial: Cuestionario Inicial.doc   B Presente documento. Cuestionario de ERS.  C Descripciones funcionales de interfaces de usuario.  D Guías de estilo corporativo del cliente:  E Descripción de sistemas con los que se ha de mantener la consistencia.       
  9. 9. Customer Cuestionarios iníciales 9 Lista de Distribución contactos y personas entrevistadas Empresa, persona, cargo Fecha Objeto Empresa 1 Personal autorizado emp. 1 Empresa 2 Personal autorizado emp. 2 Empresa 3 Personal autorizado emp. 3
  10. 10. Customer Cuestionarios iníciales 10 2.3 NOMENCLATURAS Cod. Pregunta si/no/ respuesta A ¿Existen nomenclaturas previas a seguir? Si En caso de No tenerlas será necesario especificarlas y recogerlas en un documento como parte de la documentación. B En caso afirmativo ¿Qué documento las recoge? 2.4 GLOSARIO,CONCEPTOS, CONVENCIONES O LENGUAJE ESPECÍFICO DEL DOMINIO Concepto Explicación
  11. 11. Customer Cuestionarios iníciales 11 3 DESCRIPCIÓN Descripción de la empresa/organización. URL: www.empresa.com Descripción funcional del proyecto Documentos Word: descripción funcional Documentos PPT. Capturas de pantallas por áreas. 3.1 ORIGEN O MOTIVACIÓN DEL PROYECTO El motivo que justifica el desarrollo del proyecto. Conocer estos motivos ayudara a la toma de decisiones por parte del equipo priorizando unas funcionalidades frente a otras. 3.2 CONTEXTO Pregunta si/no/ respuesta ¿Existe alguna normativa de calidad interna que sea necesario seguir o afecte al proyecto? ¿En caso afirmativo, cual? ISO 9000/9001 CMMI TIL Pregunta si/no/ respuesta ¿Existe alguna metodología de desarrollo, documentación y seguimiento de los proyectos? ¿En caso afirmativo, cual? Métrica 3 3.3 CONTROL DE CALIDAD Cd. Pregunta si/no respuesta A ¿Existe conjunto de pruebas para verificar el desarrollo? B ¿Existen datos que sea necesarios importar? C ¿Documento que explique su formato? D ¿Soporte de los datos?
  12. 12. Customer Cuestionarios iníciales 12 4 PERSPECTIVA DEL PRODUCTO 4.1 IDENTIFICACIÓN DE USUARIOS Y PERFILES Cod. Pregunta si/no/ respuesta La tabla de usuarios y perfiles es: A Existente: ¿Qué Documento explica su formato? ¿Cuáles son los procedimientos de identificación? ¿Cuáles son los procedimientos de autorización? ¿Cómo se revocan, actualizan los permisos? ¿Existen permisos horizontales (por dato, propietario del dato)? Lista de perfiles (ejemplo ) Descripción o agrupación Administrador aplicación RRHH Financiero Solo se tendrán en cuenta los perfiles aquí descritos.
  13. 13. Customer Cuestionarios iníciales 13 Cod. Pregunta si/no/ respuesta A ¿Los usuarios y/o perfiles están jerarquizados? B ¿Los usuarios pueden tener varios perfiles? C ¿Existe LDAP? En caso afirmativo ¿existe documentación? 4.2 PROCESOS Y CONSULTAS Cod. Procesos /consultas Descripción
  14. 14. Customer Cuestionarios iníciales 14 Cod. Procesos / consultas Puede ser iniciado por perfil perfil perfil perfil
  15. 15. Customer Cuestionarios iníciales 15 Pregunta respuesta Pregunta respuesta Pregunta respuesta Pregunta respuesta Pregunta respuesta Requisito requisito requisito 4.2.1 Restricciones y Políticas de la empresa Limitaciones del hardware
  16. 16. Customer Cuestionarios iníciales 16 Interfaces con otras aplicaciones Operaciones paralelas Funciones de auditoria Cadena de aprobación
  17. 17. Customer Cuestionarios iníciales 17 El log de la aplicación deberá reflejar los siguientes eventos ¿El log se escribirá en fichero de texto o en BD? El log ha de reflejar: Funciones de control Protocolos de comunicación Requisitos de habilidad La aplicación ha de poder ser utilizada por cualquier empleado por lo que se incluirá algún tipo de documentación o sistema de ayuda on line. Existirá una opción para enviar el informe de un bug o sugerencia al dpto. de informática. El Dpto de informática podrá reenviar el bug al equipo de desarrollo externalizado. ¿Cuáles son estas direcciones? ¿Cuál es el servidor de mail? ¿Cuál es el password y contraseña?
  18. 18. Customer Cuestionarios iníciales 18 Exigencias de disponibilidad y tolerancia a fallos El x%de los usuarios potenciales tiene que poder acceder de forma simultánea sin perdidas de rendimiento que no sean debidas a sobrecarga del hardware. Consideraciones acerca de la seguridad. Las medidas de seguridad serán las existentes en el cliente. Esta medidas son: Seguimiento de incidencias Pregunta respuestas ¿Qué usuarios pueden reportar incidencias del sistema? Si cualquier usuario puede enviar incidencias quien es el responsable interno de canalizarlas.
  19. 19. Customer Cuestionarios iníciales 19 4.2.2 Requisitos de Fiabilidad ¿Cuál es el nivel de tolerancia a los fallos con la que se desea trabajar? ¿Existen planes de contingencia? ¿Qué nivel de respuesta se necesita en caso de riesgo catastrófico? ¿Qué sistemas de backup hay disponibles? ¿Cuál es el nivel de redundancia que tienen los sistemas? Existe algún tipo de SLA ¿Cuál es su marco contractual? ¿Cómo se controla el cumplimiento del contrato? ¿Existen penalizaciones?, ¿Existen incentivos?. 4.2.3 Requisitos de Disponibilidad En caso de instalarse de forma dedicada en una CPU bajo los requerimientos recomendados de memoria disco y velocidad de reloj con el SO recomendado XXusuarios debieran poder conectarse simultáneamente sin pérdidas significativas de rendimiento. 4.2.4 Requisitos de Mantenimiento El Administrador de la aplicación tiene acceso a ¿todas las áreas y funciones o existen aéreas restringidas? ¿Qué elementos es necesario monitorizar? ¿Qué valores disparan alarmas, errores? ¿En qué circunstancias se realizaría una parada preventiva del sistema? 4.2.5 Suposiciones y Dependencias El producto obtenido al menos en la versión descrita en el ERS no tendrá que cumplir requisitos no especificados en el mismo. Se elaborara un prototipo no operativo de navegación de pantallas para confirmar el alcance del proyecto. 4.2.6 Requisitos Futuros ¿ Se desea un contrato de mantenimiento preventivo? ¿ Se desea un contrato de mantenimiento evolutivo? ¿Qué requisitos serían deseables pero no prioritarios, en la primera fase.? ¿Qué requisitos se pueden trasladar a fases posteriores? ¿Qué cambios tecnológicos se desean tener previstos? ¿Durante cuánto tiempo se debe mantener compatibilidad hacia atrás de elementos obsoletos?
  20. 20. Customer Cuestionarios iníciales 20
  21. 21. Customer Cuestionarios iníciales 21 4.2.7 Funcionalidades que no realizara Módulo de….. Sincronización con …. Integración con…. Migración de los datos …
  22. 22. Customer Cuestionarios iníciales 22 4.3 RELACIÓN CON OTROS SISTEMAS Ciclo de vida del legacy ¿periodo de convivencia? ¿Fechas límite para su retirada?
  23. 23. Customer Cuestionarios iníciales 23 5 DISEÑO 5.1 CONTEXTO PRINCIPIOS YCRITERIOS Preguntas respuesta ¿Plataforma? Windows, Linux, Unix, Mobile, Mac OS; Clientes:Windows, Servidores: Windows Número de ordenadores esperado. Se integrara en el site con url: Número de usuarios registrados previsto Número de usuarios no registrados previsto ninguno Nivel de velocidad exigido: alto, medio, bajo. Alto, sin delays Nivel de Seguridad exigido: alto, medio, bajo. El establecido actualmente. Fecha de inicio de proyecto deseada Fecha de finalización de proyecto deseada Tamaño de pantalla para la aplicación 640x480 800x600 1024x768 1152x864 1280x1024 1440x900 1600x1200 1680x1050 Otra ¿cual? ¿Multidioma? En caso afirmativo que idiomas es necesario tener en cuenta. (Solo proyectos web) Mantener compatibilidad con : IE explore, Fire-fox, , Safari,Crome, Opera (incluir versión), El sistema de caracteres será el UTF-8, Unicode? ¿EL acceso Web debe cumplir los estándares comunes de ergonomía? El proyecto comprende la entrega del código fuente de la aplicación documentada el código. ¿Se necesita Ayuda on line? Manual de usuario RootNamespace
  24. 24. Customer Cuestionarios iníciales 24 Cd. Instalación y despliegue del producto si/no respuesta A Hardware B Software C SO: D Aplicaciones de mercado E ¿Existe una aplicación previa? F ¿Es necesario importar los datos de dicha aplicación? Servidores de Bases de datos disponibles proyecto: G Producción: Dirección Usuario Pasword Identificación de sistema H Preproducción: Dirección Usuario Pasword Identificación de sistema Seguridad: I Sistemas de identificación de usuarios: J Tiene área pública K Tiene área privada L Firewalls: 5.2 OPCIONES DE ARQUITECTURA. Capa de persistencia Oracle 7 -8i -9i -10g 11 SQL server 2000, 2003, 2005, 2008, 2012 (R2) DB2 v8 –v8.2 MySQL 4.1 PostgreSQL 7.3.2 ORM: Nhibernate, entity framework (fluent, code first)
  25. 25. Customer Cuestionarios iníciales 25 Dominio Poco / Pojo, () EntityFactorys Recursos Sistemas de documentación automática, documentación xml del código. Aplicación Servicios distribuidos Fachada remota DTOs Mappers Clientes WCF, proxis SOAP Orquestación de servicios, Workflow Capa de presentación MVC ASP javascript HTML 5 5.3 OPCIONES ALTERNATIVAS Pregunta si/no ¿Existe la posibilidad de utilizar librerías o herramientas con causas o razones que lo justifiquen?, como por ejemplo: Incremento del Rendimiento Reducción de Precio Reducción de Tiempo de desarrollo Reducción de Coste de mantenimiento
  26. 26. Customer Cuestionarios iníciales 26 Reducción del coste de Gestión del proyecto Exigencias de Seguridad Independencia de terceras partes. Independencia de plataforma. Otras ventajas buscadas ¿cuáles? 5.4 REQUISITOS ESPECÍFICOS 5.4.1 DESCRIPCION DEL ENTORNO DE DESARROLLO. Visual Estudio 2010, 2012, 2013, Eclipse, Xamarin Framework .net versión 4.5. Share point Oracle Otrastecnologías. 5.5 DISEÑO DE INTERFACES Los estados, categorías, discriminantes y tipos se establecerán con menús desplegables. Si estos campos tienen una descripción se utilizara para el manual de usuario o la ayuda en línea. Estos menús desplegables se almacenaran en tablas de bases de datos. Estos menús desplegables se gestionaran como enumerados. El contenido de estas tablas será un identificador autogenerado como primary Key un texto de selección y opcionalmente un texto de descripción. Este texto podrá cambiarse en el futuro por una referencia a un recurso si se desea implementar la gestión de multidioma.
  27. 27. Customer Cuestionarios iníciales 27 5.5.1 De usuario: Guía de Estilo a seguir. Pregunta si/no ¿Existe guía e estilo a seguir? En caso afirmativo, Existen CSS Estándar o comunes a todas las aplicaciones que sea obligado adoptar. 5.5.2 Requerimientos de Accesibilidad y ergonomía Pregunta si/no/ respuesta ¿Es necesario cumplir alguno de los niveles de accesibilidad WAIpara discapacitados? En caso afirmativo ¿Cual? WAI A WAI AA WAI AAA Otras normativas o estándares: Especificar Requerimientos de Ergonomía (Usability) Requerimientos de Shopability ( indicador de la potencia comercial del sistema ) 5.5.3 Informes reporting y estadísticas Pregunta si/no respuesta ¿Existen herramientas de informes? En caso afirmativo ¿Cuáles? En caso negativo ¿Se desea incorporar una herramienta de mercado? ¿Se tienen definidos los informes que se desean? Si están definidos se tienen datos de prueba para los informes. ¿Qué perfiles pueden ver qué informes?
  28. 28. Customer Cuestionarios iníciales 28 FUNCIONES 5.5.4 Módulos funcionales. Mapa de los módulos principales o Mapa de contextos limitados. DDD Cod. Nombre del modulo y descripción MP MÓDULO PRINCIPAL / MS: MÓDULO DE SECUNDARIO O DE APOYO Cada uno de estos módulos tiene un significado semántico específico. La estructura interna de cada uno de ellos incluye además de los atributos que intuitivamente se pueden asociar los siguientes elementos: Un conjunto de métodos de clasificación. Un conjunto de roles e actuación. Es decir el rol que un usuario tiene al actuar sobre esto datos. Un conjunto de estados Cada acción cambia el estado del objeto al que el modulo hace referencia. Unos campos de filtrado Unos campos de búsqueda Unos campos de ordenación.
  29. 29. Customer Cuestionarios iníciales 29 5.5.5 Procesos principales:
  30. 30. Customer Cuestionarios iníciales 30 6 OBJETOS Y MODULOS Mapa de los módulos principales y secundarios del sistema
  31. 31. Customer Cuestionarios iníciales 31 6.1 PERSONAS, COLECTIVOS, ORGANIZACIONES Y ROLES. 6.1.1 Modulo personas,colectivos y entidades: ¿Qué categorías o formas de clasificación se desean utilizar con personas, empresas o colectivos?Marcar los deseados o añadir Personas físicas Personas jurídicas Colectivos Personas físicas: Datos relativos exclusivamente a personas, sin tener en cuenta sus roles actividades o formas de contacto. Dominio Req Descripción y comentarios
  32. 32. Customer Cuestionarios iníciales 32 Personas jurídicas, empresas: datos exclusivos de identificación para servicios externos. Dominio Req Descripción y comentarios Lon ID Nombre Nombre comercial Logotipo CIF Fecha de alta Fecha de Baja Se encapsulara en el cluster de usuarios y perfiles. Con respecto a los departamentos de organización interna. Organigrama Dominio Req Descripción y comentarios ID Nombre acrónimo Descripción ID Organigrama Reflexiva para establecer jerarquías de organización.
  33. 33. Customer Cuestionarios iníciales 33 6.2 CONVENCIONES PARA EL DISEÑO DE PANTALLAS Tipo de Menú, elegir Horizontal Vertical Desplegable Multinivel Otros describir Convenciones generales de configuración de pantalla Visualización de datos Pantallas de ficha de registro con etiqueta lateral con respecto al campo Pantallas de ficha de registro con etiqueta superior con respecto al campo Pantallas Grid estándar (Paginada) (Editable) Pantallas Grid con scroll (Editable) Tablas anidadas para relaciones 1-N (nivel de profundidad) Entrada de datos Añadir registro etiquetas en lateral con respecto al campo Añadir registro etiquetas superiores con respecto al campo Editar registro etiquetas en lateral con respecto al campo Editar registro etiquetas superiores con respecto al campo Grid Editable Grid con scroll
  34. 34. Customer Cuestionarios iníciales 34 Par de Idioma Cultura Escritura de izquierda a derecha Escritura de derecha a izquierda Localización de Idioma, moneda Opciones generales Cabecera BreadCrumb Mostrar estado de identificación Imprimir página Controles de página Mostrar calendario para fechas Mostrar tamaño máximo de líneas en listados Número máximo de líneas por defecto Tamaño máximo de campos de texto en columnas Ancho de columnas en Grid variable Controles de Texto Editor de campos texto con reachtext Controles de búsqueda La búsqueda por defecto es :contiene, comienza, Controles de selección Menús desplegables (pop ups) ¿se visualizan listas largas? Menús desplegables (pop ups) ¿se visualizan campos largos? O se truncan a … Entrada de datos Añadir registro etiquetas en lateral con respecto al campo Añadir registro etiquetas superiores con respecto al campo
  35. 35. Customer Cuestionarios iníciales 35 Editar registro etiquetas en lateral con respecto al campo Editar registro etiquetas superiores con respecto al campo Grid Editable Grid con scroll Categorías principales del menú por usuarios. Categorías Director Admin Sala SuperAdmin Técnico

×