Como Redactar BuenosRequisitos

1 Cómo redactar requisitos

Procesos del Desarrollo de Software – 3º Grado en Ingeniería Informática

Cómo redactar requisitos

Curso 2010-2011

José Miguel Fuentes


Índice

• La importancia del requisito en el ciclo de vida de desarrollo de software• Cómo debería ser una especificación de requisitos• Estructura de la especificación• Especificaciones completas• Especificaciones consistentes• Una especificación de requisitos no es una novela• Redacción del requisito• Ejemplos• Referencias

3

La importancia del requisito


4

Current situation in sw. development

Factores de éxito % de respuestas1. User Involvement 15.9%

2. Executive Management Support 13.9%

3. Clear Statement of Requirements 13.0%

4. Proper Planning 9.6%

5. Realistic Expectations 8.2%

6. Smaller Project Milestones 7.7%

7. Competent Staff 7.2%

8. Ownership 5.3%

9. Clear Vision & Objectives 2.9%

10. Hard-Working, Focused Staff 2.4%

Other 13.9%


40% relacionados

con requisitos

15.9%

13.0%

8.2 %

2.9 %

Basados en requisitos

5

La importancia del requisito

• Cuanto antes… mejor!!– No hay que esperar hasta las pruebas de aceptación para determinar si

hemos omitido algo o hemos entendido mal a un interesado– Aplicar revisiones y técnicas para detectar requisitos de baja calidad lo

antes posible


6

Cómo debería ser una especificación de requisitos

• Completa: describe todas las necesidades relevantes para los stakeholders

• Consistente: carece de conflictos entre requisitos• Correcta: todo es pertinente y no contiene errores• Modificable: facilidad para efectuar cambios de forma sencilla,

completa y consistente• Verificable: existencia de un proceso acotado que determine si

el sistema final satisface el requisito• Trazable: el origen del requisito está marcado de forma clara; y

se puede seguir el impacto del requisito a lo largo del SDLC• Clara y no ambigua: una única interpretación

IEEE 830, 1998Cómo redactar requisitos

7

Cómo debería ser una especificación de requisitos


Sigla Concepto Descripción

S eSpecífico Claros y simples: qué, por qué…

M Medible Se puede cuantificar y evaluar

A Alineado Con la estrategia o con el fin del sistema

R Realista Puede conseguirse con un número de recursos lógico

T limitado en Tiempo

Establece un periodo de tiempo claro

"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning

him safely to Earth"

8

Estructura de la especificación

• Un proyecto mediano puede tener centenares de requisitos• Estos requisitos no se escriben y se olvidan:

– Pueden ser firmados, con lo que son pieza clave en contratos– Son la fuente del diseño– Se verificará el software contra ellos

• La correcta organización de los mismos es vital• Claves:

– Utiliza estándares de estructuración de especificaciones de requisitos– Aclara el objetivo global a cumplir por el sistema– Emplea descripciones textuales y gráficas– Ordena y agrupa tus requisitos de forma lógica– Relaciona unos requisitos con otros para facilitar su entendimiento– Relaciona los requisitos con otros activos


9

Especificaciones completas

• ¿Qué podemos hacer para no olvidar nada…– Revisión por pares: junto con compañeros más experimentados, expertos

en la materia, cliente y otros interesados– Emplear check-lists– Comparar la especificación contra taxonomías propias de la materia– Reutilizar requisitos de proyectos previos

• Reutilización de grano grueso: componentes reutilizables• Reutilización de grano fino: buscadores avanzados


10

Especificaciones consistentes

• El primer paso hacia la consistencia es evitar redundancia…• … y las inconsistencias provocan retrabajo• Las revisiones en grupo permiten detectar parte de estas

redundancias• Técnicas automáticas para su apoyo:

– Comparación de grafos semánticos– Detección de unidades inconsistentes


11


• Comparación de grafos semánticos:UR001: ….UR023: El sistema deberá enviar notificaciones semanales de nuestras

ofertas a todos los clientesURxxx: …UR842: La aplicación debe ser capaz de notificar periódicamente a sus

clientes sobre nuestras ofertasUR999: …


12


• Detección de unidades inconsistentes:• “NASA y ESA reconoces la pérdida de una sonda marciana por haber

diseñado dos módulos empleando diferentes sistemas de medida”• Revisiones globales de la especificación• Detección automática de unidades inconsistentes


13

Comparativa: Novela vs. Requisito

� Múltiples estilos narrativos:� Ficción

� Histórica� Científica� Cómica

� …


14


� Múltiples estilos narrativos

� Nos deben contar una historia real� Creíble por todos los interesados

� El autor no debe expresar su punto de vista, sino la situación real

� Capaz de ser diseñada, implementada, probada, implantada, mantenida…


15

� Abiertas a todo tipo de licencias poéticas y adornos:

� “Generalmente se viste de manera victoriana, incluyendo un traje, botas de montar, y una ostentosa

corbata de moño intrincadamente atada, …”



16

� Abiertas a todo tipo de licencias poéticas y adornos

� Licencias poéticas las mínimas� Textos simples y claros para facilitar su lectura y

entendimiento� Siguiendo un conjunto de gramáticas fijas y simples

� Usando la voz activa en lugar del pasivo� Evitando terminología técnica, abreviaturas …

� Utilizando un vocabulario controlado, donde los términos estén bien consensuados

� Prescindiendo de especulaciones



17

� Intentan contarnos la totalidad de la historia:� Qué ocurre

� Por qué ocurre� Cómo se desenlaza la trama



18

� Intentan contarnos la totalidad de la historia

� Sólo nos deben contar parte de la historia� Centrándose en el qué, e incluso, en el por

qué� Nunca debe tratar el cómo

� Debe evitarse terminología propia de diseño, pseudocódigo…



19

� Suelen jugar con nuestra imaginación:� “…la verdad es que Robert parecía mayor, no

aparentaba los 32 años que tenía.”� “Podía verse el fuego desde la distancia…”

� “… triangular, a veces largamente triangular, reticulado, con largos dientes en el margen y con un tejido grueso

…”



20

� Suelen jugar con nuestra imaginación

� No pueden jugar con nuestra imaginación� Todos los requisitos, además de simples, deben

ser fáciles de medir� Ambigüedad cero, para que todos los

interesados interpretemos cada requisito de una única forma



21

� A menudo, pueden hacer referencias a otros textos:� Otros tomos de la novela

� Situaciones de otras novelas del autor, o personajes de otras novelas

� Al conocimiento general que se supone a nuestros lectores� …



22

� A menudo, hacen referencias a otros textos

� No deben dar ningún conocimiento por sentado� Deben ser autocontenidos

� En el mejor de los casos, acompañados incluso de glosarios



23

� Pueden mezclar diferentes hilos de argumento



24

� Pueden mezclar diferentes hilos de argumento

� Cada requisito debe ser atómico� Una única necesidad por requisito

� Orden lógico de interpretación



25

� Se redactan con maravillosos procesadores de texto



26

� Se redactan con maravillosos procesadores de texto

� Deben escribirse con herramientas especializadas en estos fines� Con ello conseguimos:

� Identificarlos unívocamente� Atomizarlos

� Organizarlos, categorizarlos y relacionarlos� Reutilizarlos por separado o en conjunto

� Medir su calidad individual o global



27

Redacción del requisito

• Claridad y ambigüedad:– ¿Puede medirse de forma clara y no ambigua la claridad y ambigüedad

de un requisito?– “En casa del herrero… cuchillo de palo”


28


• Emplear la estructura correcta:


Usuario El operador del Call Center…

Acción … deberá ser capaz de ver…

Objeto … detalles de cada compañía contactada…

Cualificador … en menos de dos segundos.

29


• Tamaño del requisito: – El justo, ni muy breve ni muy largo

– Tamaño medido en caracteres, palabras, párrafos

• Legibilidad:– La máxima posible– Procesadores como MS Word miden la legibilidad de los textos

• Tiempo verbal:– Imperativo en lugar de condicional

• Modo verbal:– Activa en lugar de pasiva

• Sentencias opcionales y especulativas: – Evitar sentencias del estilo “quizá…” , “posiblemente…”, “usualmente…”, “casi siempre…”

• Expresiones ambiguas:– Evitar expresiones del estilo: “rápido”, “amigable”…


30


• Sentencias subjetivas:– Evitar sentencias del tipo: “yo creo…”, “en mi opinión…”

• Sentencias implícitas (empleo de pronombres):– Evitar el abuso de los pronombres– A la hora de la lectura, podríamos dudar en qué nombre sustituye cada nombre

• Conectores:– El abuso de conectores puede indicar que se está incluyendo más de una necesidad en el

mismo requisito

– También puede indicar un exceso de detalle

• Negaciones:– Más de una palabra negativa en la misma frase podría hacerla difícil de entender

• Sentencias incompletas:– Evitar sentencias del tipo “etcétera…”, “…entre otros…”, “…”

• Términos propios de diseño o de flujo:– Evitar términos que denotan diseño como por ejemplo “clave ajena”, “tabla hash”…


31


• Número de términos del dominio:– Un exceso de términos del dominio puede indicar que se están mezclando diferentes

necesidades en el mismo requisito– También puede indicar que se está dando un excesivo detalle

• Número de verbos principales (del dominio):– Un exceso de verbos del dominio puede indicar que se están mezclando diferentes

necesidades en el mismo requisito

– También puede indicar que se está dando un excesivo detalle

• Acrónimos y abreviaturas:– Sólo permitidos si están definidos en alguna sección del documento de requisitos


32

Ejemplo 1

• La información sobre los metadatos de los usuarios debería almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios


33

Ejemplo 1

• La información sobre los metadatos de los usuarios deberíaalmacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios– Evite el uso del tiempo condicional– Sustitúyalo por el imperativo

• La información sobre los metadatos de los usuarios deberáalmacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios


34

Ejemplo 1


35

Ejemplo 2

• El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Opcionalmente, deberá también ser capaz de generar un informe y enviarlo por e-mail al cliente


36

Ejemplo 2

• El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Opcionalmente, deberá también ser capaz de generar un informe y enviarlo por e-mail al cliente

– La opcionalidad debe expresarse mediante un atributo, y nunca como texto dentro del requisito


37

Ejemplo 2

• El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Opcionalmente, deberátambién ser capaz de generar un informe y enviarlo por e-mail al cliente

– La opcionalidad debe expresarse mediante un atributo, y nunca como texto dentro del requisito

– Deberá usar un requisito individual para cada necesidad. Muchos verbosconcentrados en un requisito pueden implicar la mezcla de diferentes necesidades

• El Administrador deberá ser capaz de añadir usuarios• El Administrador deberá ser capaz de borrar usuarios• El Administrador deberá ser capaz de mostrar usuarios• El Administrador deberá ser capaz de actualizar usuarios• El Administrador podrá generar un informe para enviarlo por e-mail al

clienteCómo redactar requisitos

38

Ejemplo 3

• El sistema debe ser capaz de importar ficheros ABC. El proceso debe ser amigable y rápido para el usuario


39

Ejemplo 3


– Términos como ‘amigable’ y ‘rápido’ son difíciles de medir y, por lo tanto, imposible de probar de forma correcta

– Utilice unidades físicas para medir cómo de rápido debe rendir un requisito

– Utilice otros medios (p.e. WAI AA) claramente definidos para indicar cómo de amigable o accesible debe ser un sistema


40

Ejemplo 3


– Términos como ‘amigable’ y ‘rápido’ son difíciles de medir y, por lo tanto, imposible de probar de forma correcta

– Utilice unidades físicas para medir cómo de rápido debe rendir un requisito

– Utilice otros medios (p.e. WAI AA) claramente definidos para indicar cómo de amigable o accesible debe ser un sistema

– Utilice acrónimos sólo cuando estén comúnmente aceptados por todos los interesados


41

Ejemplo 4

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagas para que puedan generar un mail y enviárselos a ellos


42

Ejemplo 4

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagas para que puedan generar un mail y enviárselos a ellos– El uso apropiado de signos de puntuación hará los requisitos más fáciles

de leer– El número de sílabas por palabra y palabras por frase es también un buen

indicador de la legibilidad del requisito

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema. Éste también deberá estar al tanto de facturas impagas para que puedan generar un mail in enviárselos a ellos


43

Ejemplo 4

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagas para que puedan generar un mail y enviárselo a ellos

– El exceso de pronombres puede hacer un requisito difícil de entender– El último ‘ellos’, ¿se refiere al administrador o al cliente?

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagas para que puedan generar un mail in enviárselo a los clientes


44

Ejemplo 4

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagas para que puedan generar un mail y enviárselos a ellos.

El proceso para localizar impagados es el siguiente:1. Iterar sobre todas las facturas2. Si Fecha_Factura + CondicionesPago es mayor que la fecha actual, entonces:

• Si la categoría del cliente es A, entonces se le deja un mes extra• SI no, mientras la factura no esté pagada no se le permite generar nuevas facturas y se

le enviará un mail cada semana

– Evite el uso de pseudocódigo en sus requisitos– Los requisitos extensos (en caracteres o párrafos) pueden indicar baja

calidad


45

Ejemplo 5

• Los clientes podrán remitir órdenes por Internet. Estas órdenes deben incluir fecha de envío y cantidad de artículos.

Una vez que se recibe la orden, el equipo de empaquetado debe recoger todos los artículos y enviar un mail al cliente.

Deben soportarse los protocolos http y https, así como los navegadores Explorer y Firefox. La resolución mínima será de 1024x768


46

Ejemplo 5

• Los clientes podrán remitir órdenes por Internet. Estas órdenesdeben incluir fecha de envío y cantidad de artículos.

Una vez que se recibe la orden, el equipo de empaquetado debe recoger todos los artículos y enviar un mail al cliente.

Deben soportarse los protocolos http y https, así como los navegadores Explorer y Firefox. La resolución mínima será de 1024x768

– Un exceso de términos diferentes en el mismo requisito puede indicar:• Que se están mezclando diferentes necesidades en un único requisito

• Que se está proporcionando demasiado detalle

– Igualmente, muchos verbos pueden involucrar diferentes necesidades mezcladas en un único requisito


47

Ejemplo 6

• En mi opinión, ningún cliente debería poder nunca enviar órdenes al equipo de empaquetado. Ya lo hicimos así en un proyecto hace tres años y el resultado fue nefasto


48

Ejemplo 6


– No haga explícita su opinión, limítese a escribir lo que el sistema debe hacer


49

Ejemplo 6



– No mezcle demasiados términos negativos, ya que a veces puede dificultar la lectura del requisito/restricción


50

Ejemplo 6



– No mezcle demasiados términos negativos, ya que a veces puede dificultar la lectura del requisito/restricción

– No divague al redactar el requisito. Limítese a indicar qué es lo que debe hacer el sistema

• Un cliente no podrá enviar órdenes directamente al equipo de empaquetado


51

Ejemplo 7

• Generalmente, el sistema debe ser capaz de terminar el proceso de rastreo sin sobrecargar excesivamente el servidor


52

Ejemplo 7


– Evite expresiones vagas como: ‘generalmente’, ‘comúnmente’


53

Ejemplo 7


– Evite expresiones vagas como: ‘generalmente’, ‘comúnmente’– Verifique si cada aserción puede ser medida de forma sencilla

• El sistema debe ser capaz de terminar el proceso de rastreo en un tiempo inferior a 2 segundos y sin que el proceso sobrepase los 250 MB de memoria



Referencias

• Writing better requirements:– Ian F. Alexander & Richard Stevens– Addison-Wesley, 2002

Como Redactar BuenosRequisitos

Documents

Transcript of Como Redactar BuenosRequisitos