Cómo escribir buenos requisitos

Transcripción

Procesos del Desarrollo de Software – 3º Grado en Ingeniería Informática
Cómo redactar requisitos
Curso 2010-2011
José Miguel Fuentes
1
Í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
2
La importancia del requisito
3
Current situation in sw. development
Factores de éxito
% de respuestas
1. User Involvement
15.9%
15.9%
2. Executive Management Support
13.9%
3. Clear Statement of Requirements
13.0%
13.0%
4. Proper Planning
9.6%
5. Realistic Expectations
8.2%
8.2 %
6. Smaller Project Milestones
7.7%
7. Competent Staff
7.2%
8. Ownership
5.3%
9. Clear Vision & Objectives
2.9 %
2.9%
10. Hard-Working, Focused Staff
2.4%
Other
13.9%
Basados en requisitos
40% relacionados
con requisitos
4
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
5
• 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, 1998
6
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"
7
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
8
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
9
• 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
10
• Comparación de grafos semánticos:
UR001: ….
UR023: El sistema deberá enviar notificaciones semanales de nuestras
ofertas a todos los clientes
URxxx: …
UR842: La aplicación debe ser capaz de notificar periódicamente a sus
clientes sobre nuestras ofertas
UR999: …
11
• 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
12
Comparativa: Novela vs. Requisito
Múltiples estilos narrativos:
Ficción
Histórica
Científica
Cómica
…
13
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…
14
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, …”
15
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
16
Intentan contarnos la totalidad de la historia:
Qué ocurre
Por qué ocurre
Cómo se desenlaza la trama
17
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…
18
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
…”
19
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
20
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
…
21
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
22
Pueden mezclar diferentes hilos de argumento
23
Pueden mezclar diferentes hilos de argumento
Cada requisito debe ser atómico
Una única necesidad por requisito
Orden lógico de interpretación
24
Se redactan con maravillosos procesadores de
texto
25
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
26
• 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”
27
• 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.
28
•
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:
•
Modo verbal:
– Imperativo en lugar de condicional
– Activa en lugar de pasiva
•
Sentencias opcionales y especulativas:
•
Expresiones ambiguas:
– Evitar sentencias del estilo “quizá…” , “posiblemente…”, “usualmente…”, “casi siempre…”
– Evitar expresiones del estilo: “rápido”, “amigable”…
29
•
Sentencias subjetivas:
•
Sentencias implícitas (empleo de pronombres):
– Evitar sentencias del tipo: “yo creo…”, “en mi opinión…”
– 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:
•
Términos propios de diseño o de flujo:
– Evitar sentencias del tipo “etcétera…”, “…entre otros…”, “…”
– Evitar términos que denotan diseño como por ejemplo “clave ajena”, “tabla hash”…
30
•
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
31
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
32
Ejemplo 1
• La información sobre los metadatos de los usuarios debería
Usuarios
– Evite el uso del tiempo condicional
– Sustitúyalo por el imperativo
• La información sobre los metadatos de los usuarios deberá
Usuarios
33
Ejemplo 1
34
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
35
Ejemplo 2
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
36
Ejemplo 2
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 verbos
concentrados 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
cliente
37
Ejemplo 3
• El sistema debe ser capaz de importar ficheros ABC. El proceso
debe ser amigable y rápido para el usuario
38
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
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
– Utilice acrónimos sólo cuando estén comúnmente aceptados por todos los
interesados
40
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
41
Ejemplo 4
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
sistema. Éste también deberá estar al tanto de facturas impagas
para que puedan generar un mail in enviárselos a ellos
42
Ejemplo 4
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?
impagas para que puedan generar un mail in enviárselo a los
clientes
43
Ejemplo 4
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 facturas
2. 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
44
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
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
– 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
46
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
47
Ejemplo 6
– No haga explícita su opinión, limítese a escribir lo que el sistema debe
hacer
48
Ejemplo 6
hacer
– No mezcle demasiados términos negativos, ya que a veces puede
dificultar la lectura del requisito/restricción
49
Ejemplo 6
hacer
– 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
50
Ejemplo 7
• Generalmente, el sistema debe ser capaz de terminar el proceso
de rastreo sin sobrecargar excesivamente el servidor
51
Ejemplo 7
– Evite expresiones vagas como: ‘generalmente’, ‘comúnmente’
52
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
53
Referencias
• Writing better requirements:
– Ian F. Alexander & Richard Stevens
– Addison-Wesley, 2002
54

Cómo escribir buenos requisitos

Transcripción

Documentos relacionados

CURSO DE ESPANHOL JURÍDICO Objetivo: • Familiarizar al