ser esto cierto?

La solicitud del usuario

Lo que entendi el lder del proyecto

El diseo del analista de sistemas

El enfoque del programador

La recomendacin del consultor

La documentacin del proyecto

La implantacin en produccin

El presupuesto del proyecto

El soporte operativo

Lo que el usuario necesitaba

Introduccin.
Muchos de los problemas encontrados en el desarrollo de software se generan debido a la falta de claridad en la recoleccin de documentacin y a la pobre tarea de recoleccin y validacin de los requerimientos entregados por los que finalmente sern usuarios. Por tanto es necesario tener en cuenta que los requerimientos son el punto clave para marcar la diferencia entre el xito y fracaso de los proyectos de desarrollo de software.

Tenga en cuenta.
El Superproceso de levantamiento y administracin de requerimientos debe considerar como premisa inicial que el usuario no sabe lo que quiere. Por lo tanto se deben desarrollar organizacionalmente personas, procesos y tecnologa para apoyar esta condicin.

Definicin de Requisitos
El *IEEE, en su Standard Glossary of Software Engineering Terminology define un requerimiento como: Condicin o capacidad que tiene que ser alcanzada o poseda por un sistema o por uno de sus componentes para satisfacer un requerimiento, un contrato, un estndar, una especificacin u otro documento impuesto formalmente.
*The Institute of Electrical and Electronics Engineers, fundado en 1884, entre sus fundadores estn: Thomas Alva Edison, Alexander Graham Bell y Frankiln Leonard Pope.

Los diez errores informticos ms graves de la historia

Que se te cuelgue el computador raramente es muy grave, pero que un programa falle en un sistema que puede matar a alguien, siempre lo es. veamos algunos de los fallos informticos ms graves de la historia.

Niveles de Requisitos
REQUISITOS DE NEGOCIO

Documento de Visin y Alcance

REQUISITOS DE USUARIO

REGLAS DE NEGOCIO ATRIBUTOS DE CALIDAD INTERFACES EXTERNAS RESTRICCIONES

Documento de Casos de Uso

REQUISITOS DEL SISTEMA REQUISITOS FUNCIONALES

Especificacin de Requisitos de Software

Requierements levels

Requisitos Funcionales
Especifican la funcionalidad del software que los desarrolladores deben construir en el producto para posibilitar a los usuarios a completar sus tareas y que a su vez satisfagan los requerimientos de negocio. Algunas veces los requerimientos Funcionales son llamados de comportamiento y normalmente se escriben con la tradicional sentencia DEBER. Un ejemplo de un requerimientos funcional es: El sistema deber enviar va e-mail la confirmacin de la reserva al usuario

Requerimientos de Negocio
Representan los objetivos de alto nivel de la organizacin o del cliente que requiere el sistema. Los requerimientos de negocio tpicamente provienen del patrocinador principal del proyecto, el cliente, el administrador de los usuarios o el departamento de mercadotecnia. En algunos casos se manejan documentos independientes para el levantamiento de los requerimientos de negocio y en otros casos hacen parte de un nico documento que define todas las solicitudes de los usuarios. Lo que es claro es que los requerimientos de negocio se basan en la visin y alcance de la compaa, y de esta manera se orienta el software esperado.

Requerimientos de Usuario
Describen los objetivos del usuario o tareas que los usuarios deben ser capaces de ejecutar con el producto. Las formas mas comunes de representar requerimientos de usuario incluyen: - Casos de Uso - Descripcin de Escenarios - Tablas Evento Respuesta. Los requerimientos de usuario describen entonces que es lo que el usuario es capaz de hacer con el sistema , por ejemplo Hacer una reserva de una aerolnea a travs de una pgina web

Requerimientos del Sistema

Los requerimientos para un sistema de software determinan lo que har el sistema y definen las restricciones de su operacin e implementacin. Sirven como base para definir el contrato de la especificacin del sistema y por lo tanto, debe ser una especificacin completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseo del sistema.

Requerimientos del Sistema

En principio, los requerimientos del sistema debern establecer lo que ste har y no la manera en que se implementar. Sin embargo, en el nivel de detalle requerido para especificar el sistema completamente, es casi imposible excluir toda la informacin de diseo. Ejemplos: El programa funcionar en cualquiera de los sistemas operativos actuales de Microsoft Windows (XP, Vista y Windows 7, 32- o 64-bit). La aplicacin web debe funcionar correctamente en los siguientes browsers: iExplorer (Ver. 7 en adelante), Google Chrome, Firefox, Mozilla, Opera.

Requisitos No Funcionales
Estos requerimientos son adicionales a los requerimientos funcionales que debe cumplir el sistema y corresponden a aspectos tales como la disponibilidad, mantenibilidad, flexibilidad, seguridad, escalabilidad, modificabilidad, usabilidad (facilidad de uso), etc. Los requerimientos no funcionales debern ser detallados an ms durante la fase de diseo, por el proveedor que realizar el diseo y construccin del Sistema de Informacin.

Reglas de Negocio
Incluyen polticas corporativas, regulaciones de gobierno, estndares industriales, prcticas contables y algoritmos computacionales. Estas Reglas no son en si requerimientos de software!!! ya que estas existen fuera de los lmites de cualquier especificacin de un sistema de software. Ejemplo de reglas de negocio: "Un cliente al que facturamos ms de 10.000 al ao es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000.

Anlisis del Problema

"Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean A travs de la definicin de problema, podemos ver entonces que la actividad de "Anlisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalen las necesidades inciales de todos los involucrados en el proyecto y que se proponga una solucin de alto nivel para resolverlo.

Identificacin de Requerimientos
Se debe dar respuesta a las siguientes preguntas:
Cul es el proceso bsico de la empresa? Qu datos utiliza o produce este proceso?

Cules son los lmites impuestos por el tiempo y la carga de trabajo?

Qu controles de desempeo utiliza?

Comprensin del Proceso

Preguntas Claves: Cul es la finalidad de esta actividad dentro de la empresa? Qu pasos se siguen para llevarla a cabo? Dnde se realizan estos pasos? Quines los realizan?

Cunto tiempo tardan en efectuarlos?

Con cunta frecuencia lo hacen? Quines emplean la informacin resultante?

Identificacin de Datos Empleados e Informacin Generada

Detectar qu datos se utilizan para llevar a cabo cada actividad.

Frecuencia y Volumen del Proceso

La frecuencia con la que se presentan las actividades en una empresa cambia mucho. Por consiguiente se debe investigar con cunta frecuencia se repite una actividad. Conocer esta informacin nos puede llevar a considerar ms preguntas importantes para determinar la razn de esta frecuencia y su efecto sobre las actividades de la empresa.
Muchas veces la manera ms fcil de obtener esta informacin es identificar el objetivo de la actividad: Cul es la causa de la actividad?

Identificacin de Controles
Examinar los mtodos de control: Existen estndares especfico de desempeo? Quin se encarga de comparar el desempeo contra los estndares? Cmo se detectan los errores? Cmo se corrigen los errores? Se cometen demasiados errores?

Requerimientos de las Transacciones de los Usuarios Lista de preguntas para obtener una descripcin apropiada del sistema:
Volumen Cul es el volumen de actividades que se presentan? Con que frecuencia ocurren las actividades? Ocurren las actividades de acuerdo con un ciclo? Control Qu reas necesitan un control especifico? Cules son los mtodos de control utilizados? Qu criterios se emplean para medir y evaluar el desempeo? Qu mtodos se emplean para detectar lagunas en los controles? Se toman precauciones especificas de seguridad para proteccin contra una actividad impropia? Existen mtodos para evadir el sistema? Por qu se presentan? Procesos Qu procesos, pasos o funciones constituyen esta actividad? Qu es lo que da inicio a la actividad? Cunto tiempo tarda cada actividad?Qu factores intervienen en la duracin de la actividad? Qu retrasos ocurren o pueden ocurrir? Cmo interactan los elementos entre s? Cul es el costo de la operacin del sistema? Se satisfacen los objetivos especficos de la gerencia?

Requerimientos de las Transacciones de los Usuarios

Lista de preguntas para obtener una descripcin apropiada del sistema:
DATOS Qu datos entran al sistema y cul es su origen? En qu forma se reciben los datos del sistema?En qu forma son almacenados? Qu datos son almacenados en el sistema o como parte de las actividades del mismo? Quines utilizan la informacin generada por el sistema? Con qu finalidad la utilizan? Qu es lo que no se utiliza (partes extraas)? Qu datos faltan con mayor frecuencia? Existen datos desarrollados o empleados sobre un BD? Qu tablas de referencia, diagramas u otros datos se utilizan? Cmo estn codificados o abreviados los datos y actividades? OTROS Quines son las personas clave en el sistema?Por qu son importantes?

Requerimientos de: Decisin de los Usuarios

A diferencias de las actividades de transaccin, las relacionadas con decisiones no siguen un procedimiento especifico.
Preguntas para determinar los requerimientos de las decisiones:

Qu informacin se utiliza para tomar la decisin? Cul es la fuente de esta informacin? Qu sistemas de transacciones producen los datos utilizados en el proceso de decisin? Qu otros datos son necesarios y no es posible obtener el procesamiento de transacciones? Qu datos se originan en fuentes externas a la organizacin? Cmo se deben procesar los datos para producir la informacin necesaria? Cmo debe presentarse la informacin?

Roles
Dentro del proceso de Levantamiento y anlisis de requerimientos surgen dos roles bsicos y vitales para la evolucin exitosa de dicho proceso: 1. Cliente 2. Ingeniero de Requerimientos (IR) Cliente es un individuo u organizacin de quien derivan directa o indirectamente necesidades para ser cubiertas en un producto de tipo software.

En el argot de proyectos dentro del grupo de clientes se encuentran los stakeholders quienes : solicitan, pagan, seleccionan, especifican, usan y reciben una salida generada por el software.

El IR
El IR es el individuo que tiene la responsabilidad principal de: Definir los requerimientos de negocio, usuarios y funcionales. Identificar stakeholders del proyecto y clases de usuarios. Obtencin de requerimientos. Analizar los requerimientos. Escribir especificaciones de requerimientos. Modelar los requerimientos. Validar los requerimientos. Identificar la prioridad de los requerimientos. Las necesidades de los stakeholders del proyecto. El IR es un rol de proyecto, no necesariamente un titulo de trabajo.

EL IR
Es importante tener en cuenta que no todo el mundo tiene la capacidad para asumir el rol de IR, dentro de las habilidades con que se debe contar estn: Paciencia para escuchar Entrevistar e Interrogar. Capacidad de anlisis. Observacin. Facilidad de expresin oral y escrita. Organizacin. Metodologa. Relaciones interpersonales.

COMPETENCIAS Orientacin de servicio al cliente, Solucin de problemas, Comunicacin, Gestin Efectiva, Efectividad en el trabajo, Toma de desiciones, Trabajo en equipo, Desarrollo de personal, Iniciativa, Liderazgo, Enfoque de resultados, Administracin y evaluacin de proyectos y recursos.

EL IR

HABILIDADES Pensamiento convergente, Pensamiento divergente, Pensamiento Sistmico, Lectura de compresin, Abstraccin, Anlisis, Sntesis, Crtica.

CONOCIMIENTOS Negocio (dominio de la aplicacin o en su defecto del modelo de negocio), Tecnologas de informacin, Factor humano, Modelado de negocios, Ingeniera de requerimientos, Ingeniera de software y tecnologa.

TIPS Para el Levantamiento de Requisitos

EL IR
ENFOQUE AL CLIENTE: Las organizaciones dependen de sus Clientes y por lo tanto deberan comprender las necesidades actuales y futuras de los Clientes, satisfacer los requisitos de los Clientes y esforzarse en exceder las expectativas de los mismos. LIDERAZGO: Los lideres establecen la unidad de propsito y la orientacin de la organizacin. Ellos deberan crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organizacin.

TIPS Para el Levantamiento de Requisitos

EL IR
PARTICIPACIN DEL PERSONAL: El personal a todos los niveles, es la esencia de una organizacin y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organizacin.

EL IR
ENFOQUE BASADO EN HECHOS PARA LA TOMA DE DECISIONES: Las decisiones eficaces se basan en el anlisis de los datos y la informacin.

EL IR
ENFOQUE BASADO EN PROCESOS: Un resultado deseado se alcanza ms eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso y cuando se conocen en detalle los procesos que generan la necesidad (requieren mejoras, innovacin).

Resultados
Productos excelentes de software son resultado de una buena ejecucin basada en excelentes requerimientos. Los requerimientos de alta calidad son resultado de : Buena comunicacin, Colaboracin eficaz y ante todo Sociedad entre el IR y el Cliente.

Enfoque basado en Procesos

CONCEPTOS BASICOS: PROCESO: Conjunto de actividades mutuamente relacionadas o que interactan, las cuales transforman elementos de entrada en resultados. PRODUCTO: Resultado de un proceso, puede ser un Producto tangible o un Servicio.

Enfoque basado en Procesos

Las normas ISO 9000, estn fundamentadas en la comprensin de que todo trabajo se logra mediante un proceso. Cada organizacin existe para realizar un trabajo que agregue valor. Para analizar un proceso se debe tener en cuenta que el mismo consta de: entradas, resultados, actividades interrelacionadas que agregan valor, personal responsable de su ejecucin y recursos.

Por qu?... Enfoque basado en Procesos

Un enfoque basado en procesos nos permite un mejor y continuo control sobre los procesos y las interrelaciones entre ellos, lo cual sin lugar a dudas representa una ventaja competitiva para la organizacin. Permite adems un mejor desempeo y la obtencin de mejores resultados no slo en los procesos sino en los productos y servicios, as como la posibilidad de un mejoramiento continuo de manera integral.

Trminos y Definiciones
LA CADENA DE SUMINISTRO
Conjunto de personas e instalaciones con una disposicin de responsabilidades, autoridades y relaciones

ORGANIZACIN

Proveedor
Organizacin o persona que proporciona un producto

Cliente

Organizacin o persona que recibe un producto

Servicio

Material

PRODUCTO

Enfoque basado en Procesos

PROCEDIMIENTO Forma especificada de llevar a cabo una actividad o proceso puede estar documentado o no.

EFICACIA DEL PROCESO

Extensin en la que se realizan las actividades planificadas y se alcanzan EFFECTIVENESS los resultados planificados

Entradas
(Incluye los recursos)

PROCESO
Conjunto de actividades mutuamente relacionadas o que interactan que transforman elementos de entrada en resultados

Salidas

PRODUCTO
Resultado de un proceso

Oportunidades de Seguimiento y Medicin

(Antes, durante y despus de la realizacin del proceso)

OF EFICIENCIA DEL PROCESO

Resultados alcanzados vs. Recursos utilizados

Organizacin Funcional y Procesos

Ventas Ingreso de pedidos Crdito Planeac. Produccin Almacn Logstica de Entrega Distribucin

Proceso de Cumplimiento de Pedidos de Clientes Proceso de Cumplimiento de Pedidos de Clientes

Lmites de funciones

Procesos

Organizacin Funcional y Procesos

ORGANIZACION POR FUNCIONES

VS.

ORGANIZACION POR PROCESOS

Organizacin Funcional y Procesos

La estructura de una empresa generalmente es funcional y se gestiona verticalmente, sin embargo los resultados del trabajo fluyen horizontalmente y se realizan a travs de procesos. Para el anlisis de un proceso es posible su descomposicin en componentes cada vez mas detallados hasta llegar al nivel de actividad especifica requerido.

Despliegue de procesos
Entrada

Proceso
Suministro de agua potable

Salida

Produccin

Distribucin

Comercializacin

Ventas e instalacin

Facturacin

Cobranzas

Atencin reclamos

Administracin de medidores

FORMATO DE GESTIN DE PROCESOS

Tenga en cuenta:
Las organizaciones son tan eficientes como lo son sus procesos... .... y un proceso es tan fuerte como su actividad ms dbil

Conclusin..
De acuerdo a lo analizado como tareas de un IR y a lo definido como caractersticas del levantamiento de requerimientos podemos concluir que bsicamente se puede generar la siguiente subdivisin: Levantamiento Anlisis Especificacin Verificacin

Cada etapa deber contar con tcnicas claras, estndares, mtodos y herramientas que permitan madurar los pasos del proyecto.

Desarrollo de requerimientos
EXCELENTES REQUERIMIENTOS

VALIDACION
METODO DE ESPECIFICACION DE REQUERIMIENTOS TECNICAS DE IDENTIFICACION DE REQUERIMIENTOS METODOS DE DOCUMENTACION HERRAMIENTAS Y ESTANDAR

Identificacin, Anlisis y Especificacin de Requerimientos.

Los requerimientos son: Una especificacin de lo que debera ser implementado. Ellos son descripciones de como el sistema debera comportarse o son tambin un atributo o propiedad del sistema. Ellos pueden ser una restriccin o condicin en el proceso de desarrollo del sistema. Es indispensable que todos y cada uno de los requerimientos, estn excelentemente definidos, claros, validados. Como distinguir si una especificacin de un requerimiento es buena o tiene problemas? No es fcil, pero hay tcnicas en las que se puede apoyar, como la del manejo de caractersticas.

Caractersticas de Excelentes Requerimientos/Requisitos (R/R)

Necesarios. No Ambiguos. Verificables. Completos. Correctos. Viables. Priorizables. Consistentes.

Necesarios
Cada R/R debera documentar algo que el usuario Realmente necesita. Algo que es requerido por un estndar, por variables externas indispensables, o por movimientos del mercado y del negocio. Es necesario aquel R/R que forma parte de un contrato firmado y establecido. Una manera de identificar R/R necesario, es si la fuente del R/R viene de una fuente con autoridad para especificarlos. Al revisar un R/R, navegue hacia atrs hacia la fuente y valide si son o no necesarios.

No Ambiguos
Un R/R es no ambiguo si todos los lectores del requerimiento pueden llegar a una simple y consistente interpretacin igual del mismo. Escribir los R/R en lenguaje natural, y no en trminos computacionales, ayuda que un requerimiento pueda ser interpretado y entendido sin ambigedades. Una forma efectiva para revelar ambigedad es hacer revisiones de los documentos, diagramas, casos de uso, desarrollar prototipos, pintar borradores de interfaces y revisar escenarios de cada uno de ellos. EJEMPLO: Se requiere implementar una funcionalidad que permita gestionar las facturas electrnicas de los clientes.

Verificables
Trate de aplicar mtodos formales, para realizar pruebas que confirmen que el R/R est correctamente especificado. Se puede utilizar, soportes, libros, documentos legales, para verificar el requerimiento. EJEMPLO:La resolucin 3878 del 28 de Junio de 1996 plantea frente los Reportes de Control Fiscal que: las personas que utilicen para el registro de sus bienes o prestacin de servicios, sistema P.O.S o factura por computador, debern imprimir al final del da, el comprobante informe diario por cada servidor.

Completos
R/R mal especificados, podran esconder informacin que no es fcil de detectar. Puede ayudar a no tener R/R incompletos, enfocarse en conocer las tareas del usuario y no sesgarse en las funciones de un sistema. Si usted sabe que tiene informacin que falta algo por conocer, utilice estrategia de marcas o banderas, lo cual generen tareas pendientes por determinar. EJEMPLO : Se requiere contar con una funcionalidad en la cual el rea de soporte tcnico pueda realizar un proceso automtico de restauracin de facturas electrnicas

Correctos
Cada R/R especifica una funcionalidad o condicin que debe contener el software No podemos contar con interpretaciones incorrectas de funcionalidades a implantar El punto de referencia para validar si un R/R es correcto o no, es la fuente del mismo, el usuario directamente, o la documentacin de alto nivel que origin el R/R pueden determinar si el requerimiento es correcto o no. Por ello, es esencial incluir a los usuarios durante el proceso de revisin de los R/R.

Viables
Es mas fcil implementar R/R cuando se conocen limitaciones tcnicas, la capacidad, y las condiciones del ambiente que rodea el proyecto. Para detectar requerimientos NO VIABLES es importante incluir dentro del equipo de anlisis de requerimientos un miembro de la parte tcnica o de ingeniera, as como un miembro del dominio del producto o mercado. Este tipo de personas, pueden ayudar a determinar de una manera real, que es posible tcnicamente o no, o que es excesivamente costoso de implementar.

EJEMPLO: Se requiere almacenar las facturas electrnicas por un periodo de 10 aos , 1 ao para consultar en lnea y 9 aos en medios magnticos.

Priorizables
Si todos los R/R, tienen el mismo nivel de prioridad, hay una mala identificacin y especificacin de R/R. Cada R/R o un conjunto de ellos debe poderse distribuir en los diferentes cortes, fases de liberacin de software o producto. Si todos los R/R son de alta prioridad, el equipo de desarrollo no tendr facilidad para incluir o modificar nuevos R/R durante la etapa de desarrollo. EJEMPLO: Particin entregables. por Fases o

Consistentes
Si un R/R tiene conflicto con otro requerimiento de software, este R/R o ambos tiene problemas en la especificacin. Los R/R deben estar acordes con las reglas del negocio y con las variables externas que afectan el dominio del negocio. EJEMPLO: Se hace necesario el manejo de un identificador nico por cada archivo plano, tanto en los archivos recibidos como en los generados por la aplicacin.

Tips
A continuacin se muestra una lista de tips utilizables como guas, para los procesos de anlisis y especificacin de requerimientos y requisitos. Estos tips, pueden ser utilizados por el ingeniero analista, consultor, o en general la persona que realiza levantamiento, anlisis y validacin de requerimientos y requisitos. Consisten en revisar las caractersticas que definen los requerimientos y aplicar estrategias.

Revisando caractersticas... Necesarios

Si no tuviera ...<R/R>.... podra ..<Alternativa>.. ? En caso de que no estuviera ..< R/R >.. Se podra utilizar ..< otra opcin, idea o alternativa >... con ese objetivo? Que pasa si ...< R/R >.... No existe?
Si no llega a acuerdo con el USUARIO, y sigue considerndolo INNECESARIO Escale en: Nivel organizacional o Conocimiento del dominio. Si no llega a acuerdo con el USUARIO, y sigue considerndolo INNECESARIO Presente modelos similares y resultados obtenidos: Mismo Dominio u Otros dominios, Busque justificaciones tcnicas.

Revisando caractersticas... No Ambiguos

Qu es para usted ...<Resultado esperado del R/R>...? Es lo mismo ...<Resultado esperado del R/R>... Si se tuviera ...<Resultado planteado del R/R o interpretacin>...? Significa lo mismo ...<Necesidad planteada en el R/R>.... En el rea ...<rea del dominio fuente del R/R>... que en ... <otra rea del dominio, distinta a la de la fuente del R/R>...?

Si continua siendo ambiguo desde su punto de vista Valdelo con miembros del dominio, diferentes a la fuente. Si continua siendo ambiguo desde su punto de vista Arme un grupo heterogneo de discusin de ambigedades

Revisando caractersticas... Verificables

Si utilizamos el mtodo ..<un mtodo especfico>.. Para obtener ..<resultado esperado en el requerimiento>.. Hallaramos el mismo resultado? qu frmula podramos aplicar para llegar al ..<resultado esperado en el requerimiento>..? Si no es posible verificar el requerimiento directamente con el usuario Apyese en bibliografa y teoras. Si no es posible verificar el requerimiento directamente con el usuario Busque expertos del dominio tanto internos como externos al proyecto para validarlo

Revisando caractersticas... Completos

En ...<requerimiento>... Se expone ... <necesidad, condicin, restriccin>... Hasta donde podramos delimitar ...<idea por completar>...?

Si considera, que an despus de validaciones y consultas el requerimiento no est completo Asigne tareas al usuario donde entregue formalmente resultados

Revisando caractersticas... Correctos

Afirmacin comparativa: Cuando ...<planteamiento del requerimiento>... El resultado ser ...<resultado esperado en el requerimiento>... y no obtendremos ...<planteamiento de resultado que contradice el planteado>...
Existe la posibilidad que cuando ..<condicin de requerimiento>.. Tambin ocurra que ...<resultado que afirma o rechace el resultado esperado en el requerimiento>..?

Si considera o intuye que no est correcto Disee y desarrolle una encuesta de respuestas en opcin excluyentes, que valide cual es el concepto correcto para un parte especfica del problema

Revisando caractersticas... Viables

Es posible lograr ..<resultado esperado en el R/R>.. Contando con ..<tecnologa, o recursos con los que se cuentan en el proyecto>.. De una manera fcil o trasparente? Si considera no viable el requerimiento y an as no ha podido llegar a acuerdo con el usuario Busque opinin de terceros al proyecto que tenga un buen nivel de credibilidad.

Que implicacin tcnica tendra ..<planteamiento inicial de R/R>... Para lograr ...<resultado esperado en el R/R>?

Si considera no viable el requerimiento y an as no ha podido llegar a acuerdo con el usuario Justifique y demuestre la complicacin en trminos econmicos

Revisando caractersticas... Priorizables

Si tenemos ...<resultado esperado en el R/R>... para ..<Hito o marca de tiempo reconocible en el proyecto>... Podramos ...<objetivo medible, planteado en el proyecto para una fecha>...? Podramos ...< Hito o marca de tiempo reconocible en el proyecto >... Si pudiramos obtener ..<otro R/R comparable o consecuente>.. An si no tuviramos ...<resultado del R/R en cuestin>...? Si an no consigue llegar a un nivel de priorizacin razonable y alcanzable con el cliente Coloque los requerimientos en una tabla de ranking de importancia y lleve al cliente a organizarlos en esa tabla de ranking, con posiciones nicas.

Si an no consigue llegar a un nivel de priorizacin razonable y alcanzable con el cliente Escale en: Nivel organizacional o Conocimiento del dominio. Y trate de definir la priorizacin a este nivel.

Revisando caractersticas... Consistentes

Para ..<Fuente del otro R/R con el cual no estamos siendo consistentes>.. El concepto o idea ...<idea del R/R en cuestin>... difiere con el nuestro dado que para . ..< Fuente del otro R/R con el cual no estamos siendo consistentes >... Esto representa ...<resultado de otro R/R con el que tenemos conflicto>... Est correcto nuestro planteamiento o el de ..<otra fuente>..? Si an no consigue ser consistente entre los R/R que identific Rena las fuentes y plantee la problemtica para encontrar la verdadera solucin. Si an no consigue ser consistente entre los R/R que identific Escale en: Nivel organizacional o Conocimiento del dominio, y plantee la problemtica de inconsistencia para encontrar la verdadera solucin.

Redaccin de Requerimientos.
Vital para entendimiento Buena redaccin, facilita interpretacin Redaccin estndar, facilita comprensin La redaccin cumple un papel principal en la etapa de validacin de requerimientos. La consistencia en redaccin agiliza todos los procesos con los requerimientos (Todos los requerimientos tienen el mismo estilo de redaccin)

Recomendaciones
Se recomienda que en forma narrativa se plasme en un documento lo que el usuario en trminos de necesidades exprese, posteriormente analice el documento tratando de segmentarlo en posibles requerimientos. Extraiga sentencia que contienen palabra deber o debe
Busque en cada documento aquellas sentencias que tiene la palabra deber o debe.

Modelo Redaccin de Requerimientos nuevos.

[LUGAR, TIEMPO, EVENTO, OBJETO] + debe, deber, no debe, no deber +[ACCIN, VERBO, SENTENCIA] + [AQUIEN, SUJETO] + [RESULTADO, CONSECUENCIA]

El sistema en el mdulo de ventas debe ofrecer una opcin mediante la cual el usuario pueda ver una

Modelo Redaccin de Requerimientos nuevos.

[LUGAR, TIEMPO, EVENTO, OBJETO] + debe, deber, no debe, no deber +[ACCIN, VERBO, SENTENCIA] + [AQUIEN, SUJETO] + [RESULTADO, CONSECUENCIA]

En caso de que al momento de validar la carga de los archivos se presenten

Modelo de redaccin de requerimientos para modificaciones y errores

[OPCIN, MODULO,EVENTO, OBJETO] + [CONDICIONES, PARAMETROS, AMBIENTE] + [RESULTADO ACTUAL, ERROR, ESTADO] + [ACCIN, (CORREGIR, MODIFICAR)] + [RESULTADO ESPERADO, DESTINO] En el reporte de mercados objetivos, al

Modelo de redaccin de requerimientos para modificaciones y errores

[OPCIN, MODULO,EVENTO, OBJETO] + [CONDICIONES, PARAMETROS, AMBIENTE] + [RESULTADO ACTUAL, ERROR, ESTADO] + [ACCIN, (CORREGIR, MODIFICAR)] + [RESULTADO ESPERADO, DESTINO] Actualmente cuando el usuario comerciante ingresa al pedido

Mas tips..
Mantenga sentencias y prrafos CORTOS Escriba sentencias completas, con una apropiada gramtica, ortografa y puntuacin Asegrese de que el proyecto tenga definido un glosario La y o la pueden implicar requerimientos compuestos. Utilice siempre trminos consistentes y definidos en el glosario Para reducir ambigedades evite trminos subjetivos como: Amigable,