FACULTAD DE INGENIERÍA

Tecnología en Sistemas

Definición de requisitos

¿será esto cierto?

La solicitud del usuario

Lo que entendió el líder del proyecto

El diseño del analista de sistemas

El enfoque del programador

La recomendación del consultor

La documentación del proyecto

La implantación en producción

El presupuesto del proyecto

El soporte operativo

Lo que el usuario necesitaba

Introducción.• Muchos de los problemas encontrados en el desarrollo

de software se generan debido a la falta de claridad en la recolección de documentación y a la pobre tarea de recolección y validación de los requerimientos entregados por los que finalmente serán 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 administración 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 tecnología para apoyar esta condición.

Definición de Requisitos

• El *IEEE, en su Standard Glossary of Software Engineering Terminology define un requerimiento como:

“Condición o capacidad que tiene que ser alcanzada o poseída por un sistema o por uno de sus componentes

para satisfacer un requerimiento, un contrato, un estándar, una especificación u otro documento

impuesto formalmente.”

*The Institute of Electrical and Electronics Engineers, fundado en 1884, entre sus fundadores están: Thomas Alva Edison, Alexander Graham Bell y Frankiln Leonard Pope.

Los diez errores informáticos más 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 informáticos más graves de la historia.

FUNCIONALES NO FUNCIONALESNiveles de Requisitos

REQUISITOS DE NEGOCIO

Documento de Visión y Alcance

REQUISITOS DE USUARIO

REGLAS DE NEGOCIO

ATRIBUTOS DE

CALIDADDocumento de Casos de Uso

REQUISITOS DEL SISTEMA

REQUISITOS FUNCIONALES

Especificación de Requisitos de Software

INTERFACES EXTERNAS

RESTRICCIONES

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 vía e-mail la confirmación de la reserva al usuario”

Requerimientos de Negocio

• Representan los objetivos de alto nivel de la organización o del cliente que requiere el sistema.

• Los requerimientos de negocio típicamente 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 visión y alcance de la compañía, 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- Descripción 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 aerolínea a través de una página web”

Requerimientos del Sistema• Los requerimientos para un sistema de software determinan lo

que hará el sistema y definen las restricciones de su operación e implementación.

• Sirven como base para definir el contrato de la especificación del sistema y por lo tanto, debe ser una especificación completa y consistente del sistema. Son utilizados por los ingenieros de software como el punto de partida para el diseño del sistema.

Requerimientos del Sistema• En principio, los requerimientos del sistema deberán 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 información de diseño.

Ejemplos:• El programa funcionará en cualquiera de los sistemas operativos

actuales de Microsoft Windows (XP, Vista y Windows 7, 32- o 64-bit).

• La aplicación 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 deberán ser detallados aún más durante la fase de diseño, por el proveedor que realizará el diseño y construcción del Sistema de Información.

Reglas de Negocio• Incluyen políticas corporativas, regulaciones de gobierno,

estándares industriales, prácticas contables y algoritmos computacionales.

• Estas Reglas no son en si requerimientos de software!!! ya que estas existen fuera de los límites de cualquier especificación de un sistema de software.

• Ejemplo de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000“.

"Un problema puede ser definido como la diferencia entre las cosas

como se perciben y las cosas como se desean”

A través de la definición de problema, podemos ver entonces que la actividad de "Análisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalúen las necesidades iníciales de todos los involucrados en el proyecto y que se proponga una solución de alto nivel para resolverlo.

Análisis del Problema

Se debe dar respuesta a las siguientes preguntas:

¿Cuál es el proceso básico de la empresa?

¿Qué datos utiliza o produce este proceso?

¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo?

¿Qué controles de desempeño utiliza?

Identificación de Requerimientos

Preguntas Claves:

¿Cuál es la finalidad de esta actividad dentro de la empresa?

¿Qué pasos se siguen para llevarla a cabo?

¿Dónde se realizan estos pasos?

¿Quiénes los realizan?

¿Cuánto tiempo tardan en efectuarlos?

¿Con cuánta frecuencia lo hacen?

¿Quiénes emplean la información resultante?

Comprensión del Proceso

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

Identificación de Datos Empleados e Información Generada

La frecuencia con la que se presentan las actividades en una empresa cambia mucho. Por consiguiente se debe investigar con cuánta frecuencia se repite una actividad. Conocer esta información nos puede llevar a considerar más preguntas importantes para determinar la razón de esta frecuencia y su efecto sobre las actividades de la empresa.

Frecuencia y Volumen del Proceso

Muchas veces la manera más fácil de obtener esta información es identificar el objetivo de la actividad:

¿Cuál es la causa de la actividad?

Examinar los métodos de control:

• ¿Existen estándares específico de desempeño?

• ¿Quién se encarga de comparar el desempeño contra los estándares?

• ¿Cómo se detectan los errores?• ¿Cómo se corrigen los errores?• ¿Se cometen demasiados errores?

Identificación de Controles

Requerimientos de las Transacciones de los UsuariosLista de preguntas para obtener una descripción apropiada del

sistema:Volumen • ¿Cuál 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?• ¿Cuáles son los métodos de control utilizados?• ¿Qué criterios se emplean para medir y evaluar el desempeño? • ¿Qué métodos se emplean para detectar lagunas en los controles?• ¿Se toman precauciones especificas de seguridad para protección contra una actividad

impropia?• ¿Existen métodos 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?• ¿Cuánto tiempo tarda cada actividad?¿Qué factores intervienen en la duración de la actividad?• ¿Qué retrasos ocurren o pueden ocurrir?• ¿Cómo interactúan los elementos entre sí?• ¿Cuál es el costo de la operación del sistema?• ¿Se satisfacen los objetivos específicos de la gerencia?

Requerimientos de las Transacciones de los Usuarios

Lista de preguntas para obtener una descripción apropiada del sistema:

DATOS • ¿Qué datos entran al sistema y cuál 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?• ¿Quiénes utilizan la información generada por el sistema? ¿Con qué finalidad la

utilizan?• ¿Qué es lo que no se utiliza (partes extrañas)?• ¿Qué datos faltan con mayor frecuencia?• ¿Existen datos desarrollados o empleados sobre un BD?• ¿Qué tablas de referencia, diagramas u otros datos se utilizan?• ¿Cómo están codificados o abreviados los datos y actividades? OTROS • ¿Quiénes son las personas clave en el sistema?¿Por qué son importantes?

A diferencias de las actividades de transacción, las relacionadas con decisiones no siguen un procedimiento especifico.

Preguntas para determinar los requerimientos de las decisiones:

•¿Qué información se utiliza para tomar la decisión?•¿Cuál es la fuente de esta información?•¿Qué sistemas de transacciones producen los datos utilizados en el proceso de decisión? •¿Qué otros datos son necesarios y no es posible obtener el procesamiento de transacciones?•¿Qué datos se originan en fuentes externas a la organización?•¿Cómo se deben procesar los datos para producir la información necesaria?•¿Cómo debe presentarse la información?

Requerimientos de: Decisión de los Usuarios

Roles…• Dentro del proceso de Levantamiento y análisis de

requerimientos surgen dos roles básicos y vitales para la evolución exitosa de dicho proceso:1. Cliente 2. Ingeniero de Requerimientos (IR)

• Cliente es un individuo u organización 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 IREl 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.• Obtención 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 están:

Paciencia para escuchar Entrevistar e Interrogar. Capacidad de análisis. Observación. Facilidad de expresión oral y escrita. Organización. Metodología. Relaciones interpersonales.

EL IR

COMPETENCIASOrientación de servicio al cliente, Solución de problemas, Comunicación, Gestión Efectiva, Efectividad en el trabajo,

Toma de desiciones, Trabajo en equipo, Desarrollo de personal, Iniciativa, Liderazgo, Enfoque de resultados,

Administración y evaluación de proyectos y recursos.

COMPETENCIASOrientación de servicio al cliente, Solución de problemas, Comunicación, Gestión Efectiva, Efectividad en el trabajo,

Toma de desiciones, Trabajo en equipo, Desarrollo de personal, Iniciativa, Liderazgo, Enfoque de resultados,

Administración y evaluación de proyectos y recursos.

HABILIDADESPensamiento convergente, Pensamiento divergente,

Pensamiento Sistémico, Lectura de compresión, Abstracción, Análisis, Síntesis, Crítica.

HABILIDADESPensamiento convergente, Pensamiento divergente,

Pensamiento Sistémico, Lectura de compresión, Abstracción, Análisis, Síntesis, Crítica.

CONOCIMIENTOSNegocio (dominio de la aplicación o en su defecto del modelo de negocio),

Tecnologías de información, Factor humano, Modelado de negocios, Ingeniería de requerimientos,

Ingeniería de software y tecnología.

CONOCIMIENTOSNegocio (dominio de la aplicación o en su defecto del modelo de negocio),

Tecnologías de información, Factor humano, Modelado de negocios, Ingeniería de requerimientos,

Ingeniería de software y tecnología.

TIPS… Para el Levantamiento de Requisitos

EL IRENFOQUE AL CLIENTE:

Las organizaciones dependen de sus Clientes y por lo tanto deberían 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 propósito y la orientación de la organización. Ellos deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organización.

TIPS… Para el Levantamiento de Requisitos

PARTICIPACIÓN DEL PERSONAL:

El personal a todos los niveles, es la esencia de una organización y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organización.

EL IR

ENFOQUE BASADO EN HECHOS PARA LA TOMA DE DECISIONES:

Las decisiones eficaces se basan en el análisis de los datos y la información.

EL IR

ENFOQUE BASADO EN PROCESOS:

Un resultado deseado se alcanza más 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, innovación).

EL IR

Resultados…• Productos excelentes de software son resultado de una buena

ejecución basada en excelentes requerimientos.

• Los requerimientos de alta calidad son resultado de : Buena comunicación, Colaboración eficaz y ante todo Sociedad entre el IR y el Cliente.

Enfoque basado en ProcesosCONCEPTOS BASICOS:• PROCESO: Conjunto de actividades mutuamente relacionadas o

que interactúan, 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, están fundamentadas en la comprensión

de que todo trabajo se logra mediante un proceso. • Cada organización 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 ejecución 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 organización. Permite además un mejor desempeño y la obtención de mejores resultados no sólo en los procesos sino en los productos y servicios, así como la posibilidad de un mejoramiento continuo de manera integral.

Términos y Definiciones

LA CADENA DE SUMINISTRO

Proveedor Cliente

Servicio Material

ORGANIZACIÓN

PRODUCTO

Conjunto de personas e instalaciones con una disposición de responsabilidades, autoridades y relaciones

Organización o persona que proporciona un producto Organización o

persona que recibe un producto

Enfoque basado en Procesos

PROCEDIMIENTOForma especificada de llevar a cabo una

actividad o proceso– puede estar documentado o no.

PRODUCTOResultado de un proceso

Oportunidades de Seguimiento y Medición(Antes, durante y después de la realización del

proceso)

SalidasEntradas PROCESOConjunto de actividades mutuamente relacionadas o que interactúan que transforman elementos de entrada en resultados

EFFECTIVENESS

EFICACIA DEL PROCESO Extensión en la que se realizan las actividades planificadas y se alcanzan los resultados planificados

OF EFICIENCIA DEL PROCESO Resultados alcanzados vs. Recursos utilizados

(Incluye los recursos)

Ventas Ingreso de Crédito Planeac. Producción Almacén Logística de Entrega pedidos Distribución

Límites de funciones Procesos

Proceso de Cumplimiento de Pedidos de Clientes

Organización Funcional y Procesos

Ventas Ingreso de Crédito Planeac. Producción Almacén Logística de Entrega pedidos Distribución

Límites de funciones Procesos

Proceso de Cumplimiento de Pedidos de Clientes

Organización Funcional y Procesos

ORGANIZACION POR FUNCIONES

ORGANIZACION POR PROCESOS

VS.

Organización 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 través de procesos.

• Para el análisis de un proceso es posible su descomposición en componentes cada vez mas detallados hasta llegar al nivel de actividad especifica requerido.

Despliegue de procesos

Proceso

Suministro de agua potable

Salida

Distribución Comercialización

Producción

Entrada

Ventas e instalación

Facturación Atención reclamos

Administración de medidores

Cobranzas

FORMATO DE GESTIÓN DE PROCESOS

Tenga en cuenta:“Las organizaciones son tan eficientes como lo son sus

procesos...

.... y un proceso es tan fuerte como su actividad más débil”

Conclusión..• De acuerdo a lo analizado como tareas de un IR y a lo definido

como características del levantamiento de requerimientos podemos concluir que básicamente se puede generar la siguiente subdivisión:

– Levantamiento– Análisis– Especificación– Verificación

• Cada etapa deberá contar con técnicas claras, estándares, métodos y herramientas que permitan madurar los pasos del proyecto.

Desarrollo de requerimientos

HERRAMIENTAS Y ESTANDAR

METODOS DE DOCUMENTACION

TECNICAS DE IDENTIFICACION DE REQUERIMIENTOS

METODO DE ESPECIFICACION

DE REQUERIMIENTOS

VALIDACION

EXCELENTESREQUERIMIENTOS

Identificación, Análisis y Especificación de Requerimientos.

• Los requerimientos son: Una especificación de lo que debería ser implementado. Ellos son descripciones de como el sistema debería comportarse o son también un atributo o propiedad del sistema. Ellos pueden ser una restricción o condición en el proceso de desarrollo del sistema.

• Es indispensable que todos y cada uno de los requerimientos, estén excelentemente definidos, claros, validados. ¿Como distinguir si una especificación de un requerimiento es buena o tiene problemas?

• No es fácil, pero hay técnicas en las que se puede apoyar, como la del manejo de características.

Características de Excelentes Requerimientos/Requisitos (R/R)…

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

Necesarios• Cada R/R debería documentar algo que el usuario Realmente

necesita.• Algo que es requerido por un estándar, 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 atrás 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 interpretación “igual” del mismo.

• Escribir los R/R en lenguaje natural, y no en términos computacionales, ayuda que un requerimiento pueda ser interpretado y entendido sin ambigüedades.

• Una forma efectiva para revelar ambigüedad 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 electrónicas de los clientes.”

Verificables

• Trate de aplicar métodos 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 resolución 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 prestación de servicios, sistema P.O.S o factura por computador, deberán imprimir al final del día, el –comprobante informe diario – por cada servidor.”

Completos

• R/R mal especificados, podrían esconder información que no es fácil 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 información 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 técnico pueda realizar un proceso automático de restauración de facturas electrónicas”

• Cada R/R especifica una funcionalidad o condición 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 documentación 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 revisión de los R/R.

Correctos

Viables• Es mas fácil implementar R/R cuando se conocen limitaciones

técnicas, la capacidad, y las condiciones del ambiente que rodea el proyecto.

• Para detectar requerimientos “NO VIABLES” es importante incluir dentro del equipo de análisis de requerimientos un miembro de la parte técnica o de ingeniería, 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 técnicamente o no, o que es excesivamente costoso de implementar.

• EJEMPLO: “Se requiere almacenar las facturas electrónicas por un periodo de 10 años , 1 año para consultar en línea y 9 años en medios magnéticos”.

Priorizables• Si todos los R/R, tienen el mismo nivel

de prioridad, hay una mala identificación y especificación de R/R.

• Cada R/R o un conjunto de ellos debe poderse distribuir en los diferentes cortes, fases de liberación 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: Partición por Fases o entregables.

Consistentes

• Si un R/R tiene conflicto con otro requerimiento de software, este R/R o ambos tiene problemas en la especificación.

• 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 aplicación”.

Tips

• A continuación se muestra una lista de “tips” utilizables como guías, para los procesos de análisis y especificación de requerimientos y requisitos.

• Estos tips, pueden ser utilizados por el ingeniero analista, consultor, o en general la persona que realiza levantamiento, análisis y validación de requerimientos y requisitos.

• Consisten en revisar las características que definen los requerimientos y aplicar estrategias.

Revisando características... “Necesarios”

¿Si no tuviera ...<R/R>.... podría ..<Alternativa>.. ?

¿En caso de que no estuviera ..< R/R >.. Se podría utilizar ..< otra opción, idea o alternativa >... con ese objetivo?

¿Que pasa si ...< R/R >.... No existe?

Si no llega a acuerdo con el USUARIO, y sigue considerándolo INNECESARIO Escale en: Nivel organizacional o Conocimiento del dominio.

Si no llega a acuerdo con el USUARIO, y sigue considerándolo INNECESARIO Presente modelos similares y resultados obtenidos: Mismo Dominio u Otros dominios, Busque justificaciones técnicas.

Revisando características... “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 interpretación>...?

¿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 Valídelo con miembros del dominio, diferentes a la fuente.

Si continua siendo ambiguo desde su punto de vista Arme un grupo heterogéneo de discusión de ambigüedades

¿Si utilizamos el método ..<un método específico>.. Para obtener ..<resultado esperado en el requerimiento>.. Hallaríamos el mismo resultado?

¿qué fórmula podríamos aplicar para llegar al ..<resultado esperado en el requerimiento>..?

Si no es posible verificar el requerimiento directamente con el usuario Apóyese en bibliografía y teorías.

Si no es posible verificar el requerimiento directamente con el usuario Busque expertos del dominio tanto internos como externos al proyecto para validarlo

Revisando características... “Verificables”

Revisando características... “Completos”

¿ En ...<requerimiento>... Se expone ... <necesidad, condición, restricción>... Hasta donde podríamos delimitar ...<idea por completar>...?

Si considera, que aún después de validaciones y consultas el requerimiento no está completo Asigne tareas al usuario donde entregue formalmente resultados

Afirmación 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 ..<condición de requerimiento>.. También ocurra que ...<resultado que afirma o rechace el resultado esperado en el requerimiento>..?

Si considera o intuye que no está correcto Diseñe y desarrolle una encuesta de respuestas en opción excluyentes, que valide cual es el concepto correcto para un parte específica del problema

Revisando características... “Correctos”

Revisando características... “Viables”

¿Es posible lograr ..<resultado esperado en el R/R>.. Contando con ..<tecnología, o recursos con los que se cuentan en el proyecto>.. De una manera fácil o trasparente?

¿ Que implicación técnica tendría ..<planteamiento inicial de R/R>... Para lograr ...<resultado esperado en el R/R>?

Si considera no viable el requerimiento y aún así no ha podido llegar a acuerdo con el usuario Busque opinión de terceros al proyecto que tenga un buen nivel de credibilidad.

Si considera no viable el requerimiento y aún así no ha podido llegar a acuerdo con el usuario Justifique y demuestre la complicación en términos económicos

¿ Si tenemos ...<resultado esperado en el R/R>... para ..<Hito o marca de tiempo reconocible en el proyecto>... Podríamos ...<objetivo medible, planteado en el proyecto para una fecha>...?

¿ Podríamos ...< Hito o marca de tiempo reconocible en el proyecto >... Si pudiéramos obtener ..<otro R/R comparable o consecuente>.. Aún si no tuviéramos ...<resultado del R/R en cuestión>...?

Si aún no consigue llegar a un nivel de priorización 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 aún no consigue llegar a un nivel de priorización razonable y alcanzable con el cliente Escale en: Nivel organizacional o Conocimiento del dominio. Y trate de definir la priorización a este nivel.

Revisando características... “Priorizables”

Para ..<Fuente del otro R/R con el cual no estamos siendo consistentes>.. El concepto o idea ...<idea del R/R en cuestión>... 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 aún no consigue ser consistente entre los R/R que identificó Reúna las fuentes y plantee la problemática para encontrar la verdadera solución.

Si aún no consigue ser consistente entre los R/R que identificó Escale en: Nivel organizacional o Conocimiento del dominio, y plantee la problemática de inconsistencia para encontrar la verdadera solución.

Revisando características... “Consistentes”

Redacción de Requerimientos.

• Vital para entendimiento• Buena redacción, facilita interpretación• Redacción estándar, facilita comprensión• La redacción cumple un papel principal en la

etapa de validación de requerimientos.• La consistencia en redacción agiliza todos los

procesos con los requerimientos (Todos los requerimientos tienen el mismo estilo de redacción)

Recomendaciones

• Se recomienda que en forma narrativa se plasme en un documento lo que el usuario en términos 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.• Identifique sentencias que implican

requerimientos• Identifique sentencias de tipo verbos ,

acciones y un resultado

Modelo Redacción de Requerimientos nuevos.

[LUGAR, TIEMPO, EVENTO, OBJETO] + “debe, deberá, no debe, no deberá” +[ACCIÓN, VERBO, SENTENCIA]

+ [AQUIEN, SUJETO] + [RESULTADO,

CONSECUENCIA]

• “El sistema en el módulo de ventas debe ofrecer una opción mediante la cual el usuario pueda ver una comparación de lo presupuestado versus la venta real en un rango de fechas para un artículo determinado”

• “Cuando el tiempo de conexión exceda el valor predeterminado como máximo el sistema debe cancelar la sesión informándole al usuario que el tiempo se agotó y que por lo tanto será desconectado”

Modelo Redacción de Requerimientos nuevos.

• [LUGAR, TIEMPO, EVENTO, OBJETO] + “debe, deberá, no debe, no deberá” +[ACCIÓN, VERBO, SENTENCIA]

+ [AQUIEN, SUJETO] + [RESULTADO,

CONSECUENCIA]

En caso de que al momento de validar la carga de los archivos se presenten inconsistencias de estructura con respecto a los planos se debe presentar al usuario un mensaje que diga: “La carga no ha sido exitosa puesto que el archivo presenta error de estructura <Causa de la falla de estructura>”.

Modelo de redacción de requerimientos para modificaciones y errores

[OPCIÓN, MODULO,EVENTO, OBJETO]+ [CONDICIONES, PARAMETROS,

AMBIENTE]+ [RESULTADO ACTUAL, ERROR, ESTADO]+ [ACCIÓN, (CORREGIR, MODIFICAR)]+ [RESULTADO ESPERADO, DESTINO]

“En el reporte de mercados objetivos, al aplicarle filtros por asesor y zona, muestra la información en desorden. Se debe corregir de tal forma que salga ordenado por número de cédula del asesor y agrupado por zona”

Modelo de redacción de requerimientos para modificaciones y errores

[OPCIÓN, MODULO,EVENTO, OBJETO]+ [CONDICIONES, PARAMETROS,

AMBIENTE]+ [RESULTADO ACTUAL, ERROR, ESTADO]+ [ACCIÓN, (CORREGIR, MODIFICAR)]+ [RESULTADO ESPERADO, DESTINO]Actualmente cuando el usuario

comerciante ingresa al pedido sugerido de CENmci el orden de las columnas que se presentan es el siguiente: :“Ajuste Fab.”, “AP”, “Ajuste Com.” , “Días Inv Sug” y en adelante las que siguen, es necesario reorganizar dichas columnas para que los ajustes aparezcan juntos así: “Ajuste Fab.” “Ajuste Com.” “AP”, “Días Inv Sug” y en adelante las que siguen.

Mas tips..• Mantenga sentencias y párrafos CORTOS• Escriba sentencias completas, con una

apropiada gramática, ortografía y puntuación

• Asegúrese de que el proyecto tenga definido un glosario

• La y o la ó pueden implicar requerimientos compuestos.

• Utilice siempre términos consistentes y definidos en el glosario

• Para reducir ambigüedades evite términos subjetivos como: Amigable, fácil, simple, rápido, eficiente, soporte, fuerte, superior, aceptable, robusto, máximo, mínimo, óptimo.