Cuestionarios iniciales para proyecto de software

Nombre del proyecto
Especificación de Requisitos
Ref:
Fecha

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.

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

Customer
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

Customer
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

Customer
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.

Customer
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: 

Customer
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.








Customer
9
Lista de Distribución contactos y personas entrevistadas
Empresa, persona, cargo Fecha Objeto
Empresa 1
Personal autorizado emp. 1
Empresa 2
Empresa 3

Customer
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

Customer
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
¿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?

Customer
12
4 PERSPECTIVA DEL PRODUCTO
4.1 IDENTIFICACIÓN DE USUARIOS Y PERFILES
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.

Customer
13
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

Customer
14
Cod.
Procesos / consultas
Puede ser iniciado por
perfil perfil perfil perfil

Customer
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

Customer
16
Interfaces con otras aplicaciones
Operaciones paralelas
Funciones de auditoria
Cadena de aprobación

Customer
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?

Customer
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.

Customer
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?

Customer
20

Customer
21
4.2.7 Funcionalidades que no realizara
Módulo de…..
Sincronización con ….
Integración con….
Migración de los datos …

Customer
22
4.3 RELACIÓN CON OTROS SISTEMAS
Ciclo de vida del legacy ¿periodo de convivencia? ¿Fechas límite para su retirada?

Customer
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

Customer
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)

Customer
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

Customer
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.

Customer
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
¿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?

Customer
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.

Customer
29
5.5.5 Procesos principales:

Customer
30
6 OBJETOS Y MODULOS
Mapa de los módulos principales y secundarios del sistema

Customer
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

Customer
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.

Customer
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

Customer
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

Customer
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

Cuestionarios iniciales para proyecto de software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Cuestionarios iniciales para proyecto de software

Similaire à Cuestionarios iniciales para proyecto de software (20)

Dernier

Dernier (10)

Cuestionarios iniciales para proyecto de software