TI-6502

Especificación de Software

Lic. Pedro I. Leiva Chinchilla

TI-6502
Ingeniería de Requerimientos

Lic. Pedro I. Leiva Chinchilla

❏ Requerimientos funcionales y no funcionales
❏ El documento de especificación de requerimientos de software (SRS)
❏ Especificación de requerimientos
❏ Procesos de ingeniería de requerimientos
❏ Obtención y análisis de requerimientos
❏ Validación de requerimientos
❏ Gestión de requerimientos
❏ Requerimientos funcionales y no funcionales
❏ El documento de especificación de requerimientos de software (SRS)
❏ Especificación de requerimientos
❏ Procesos de ingeniería de requerimientos
❏ Obtención y análisis de requerimientos
❏ Validación de requerimientos
❏ Gestión de requerimientos
❏ El proceso de establecer los servicios que el cliente requiere de un
sistema y las restricciones bajo las cuales opera y se desarrolla.
❏ Los requisitos en sí mismos son las descripciones de los servicios del
sistema y las restricciones que se generan durante el proceso de
ingeniería de requisitos.
 🙋
❏ Puede variar desde una declaración abstracta de alto nivel de un servicio
o de una restricción del sistema hasta una especificación funcional
matemática detallada.
❏ Esto es inevitable ya que los requisitos pueden cumplir una doble
función:
❏ Puede ser la base de una oferta para un contrato; por lo tanto, debe
estar abierto a interpretación;
❏ Puede ser la base del contrato en sí mismo; por lo tanto, debe
definirse en detalle;
Requerimientos del usuario
❏ Declaraciones en lenguaje natural más diagramas de los servicios que
proporciona el sistema y sus limitaciones operativas. Escrito para
clientes.
Requisitos del sistema
❏ Un documento estructurado que establece descripciones detalladas de
las funciones, servicios y restricciones operativas del sistema. Define lo
que se debe implementar para que pueda ser parte de un contrato entre
el cliente y el contratista.
Requisitos funcionales

❏ Declaraciones de servicios que el sistema debe proporcionar, cómo debe

reaccionar el sistema a entradas particulares y cómo debe comportarse el sistema
en situaciones particulares.

❏ Puede indicar lo que el sistema no debe hacer.

Requisitos no funcionales

❏ Restricciones en los servicios o funciones que ofrece el sistema, como

restricciones de tiempo, restricciones en el proceso de desarrollo, estándares, etc.

❏ A menudo se aplica al sistema como un todo en lugar de características o

servicios individuales.
❏ Describen la funcionalidad o los servicios del sistema.

❏ Depende del tipo de software, los usuarios esperados y el tipo de sistema donde
se usará el software.

❏ Los requerimientos funcionales del usuario pueden ser declaraciones de alto nivel
de lo que debería hacer el sistema.

❏ Los requerimientos funcionales del sistema deben describir los servicios del
sistema en detalle.
❏ Un usuario podrá buscar en las listas de citas de todas las clínicas.

❏ El sistema generará cada día, para cada clínica, una lista de pacientes que se
espera que asistan a las citas ese día.

❏ Cada miembro del personal que use el sistema se identificará de manera única
por su número de empleado de 8 dígitos.
❏ Los problemas surgen cuando los requisitos no se establecen con precisión.

❏ Los requisitos ambiguos pueden ser interpretados de diferentes maneras por los
desarrolladores y usuarios.

❏ Considere el término "búsqueda" en el requisito 1

❏ Intención del usuario: busque el nombre de un paciente en todos citas en

todas las clínicas;

❏ Interpretación del desarrollador: busque el nombre de un paciente en una

clínica individual. El usuario elige la clínica y luego busca.
❏ En principio, los requerimientos deben ser completos y consistentes

❏ Completos:

❏ Deben incluir descripciones de todas las funcionalidades y flujos alternos

requeridos

❏ Consistente

❏ No debe haber conflictos ni contradicciones en las descripciones de las

funcionalidades del sistema

En la práctica, es imposible producir un documento de requisitos completo y

consistente
❏ Estos definen las propiedades y restricciones del sistema, p. ej. fiabilidad, tiempo
de respuesta y requisitos de almacenamiento.

❏ Los requisitos del proceso también pueden especificarse exigiendo un IDE

particular, lenguaje de programación o método de desarrollo.

❏ Los requisitos no funcionales pueden ser más críticos que los requisitos
funcionales. Si no se cumplen, el sistema puede ser inútil.
❏ Los requerimientos no funcionales pueden afectar la arquitectura general de un
sistema en lugar de los componentes individuales.

❏ Por ejemplo, para garantizar que se cumplan los requisitos de rendimiento,

es posible que deba organizar el sistema para minimizar las comunicaciones
entre los componentes.

❏ Un único requisito no funcional, como un requisito de seguridad, puede generar

una serie de requisitos funcionales relacionados que definen los servicios del
sistema que se requieren.

❏ También puede generar requisitos que restrinjan los requisitos existentes.

❏ Requisitos del producto

❏ Requisitos que especifican que el producto entregado debe comportarse de

una manera particular, p. velocidad de ejecución, fiabilidad, etc.

❏ Requerimientos organizacionales

❏ Requisitos que son consecuencia de políticas y procedimientos

organizacionales, p. estándares de proceso utilizados, requisitos de
implementación, etc.

❏ Requisitos externos

❏ Requisitos que surgen de factores externos al sistema y su proceso de

desarrollo, p. requisitos de interoperabilidad, requisitos legislativos, etc.
Requerimiento de producto

❏ The MHC-PMS shall be available to all clinics during normal working hours
(Mon–Fri, 0830–17.30). Downtime within normal working hours shall not
exceed five seconds in any one day.

Requerimiento organizacional

❏ Users of the MHC-PMS system shall authenticate themselves using their

health authority identity card.

Requerimiento externo

❏ The system shall implement patient privacy provisions as set out in

HStan-03-2006-priv.
❏ Los requerimientos no funcionales pueden ser muy difíciles de establecer con
precisión y los requisitos imprecisos pueden ser difíciles de verificar.

❏ Objetivo

❏ Una intención general del usuario, como la facilidad de uso.

❏ Requisito no funcional verificable

❏ Una declaración que utiliza alguna medida que se puede probar

objetivamente.

❏ Los objetivos son útiles para los desarrolladores, ya que transmiten las intenciones
de los usuarios del sistema.
❏ The system should be easy to use by medical staff and should be organized in
such a way that user errors are minimized. (Objetivo)

❏ Medical staff shall be able to use all the system functions after four hours of
training. After this training, the average number of errors made by experienced
users shall not exceed two per hour of system use. (Requerimiento no funcional
testeable)
❏ Requerimientos funcionales y no funcionales
❏ El documento de especificación de requerimientos de software
(SRS)
❏ Especificación de requerimientos
❏ Procesos de ingeniería de requerimientos
❏ Obtención y análisis de requerimientos
❏ Validación de requerimientos
❏ Gestión de requerimientos
❏ El documento de requerimientos de software es la declaración oficial de lo que se
requiere de los desarrolladores del sistema.

❏ Puede incluir tanto una definición de los requisitos del usuario como una
especificación de los requisitos del sistema.

❏ NO es un documento de diseño. En la medida de lo posible, debe establecer QUÉ

debe hacer el sistema en lugar de CÓMO debe hacerlo.
❏ Requerimientos funcionales y no funcionales
❏ El documento de especificación de requerimientos de software (SRS)
❏ Especificación de requerimientos
❏ Procesos de ingeniería de requerimientos
❏ Obtención y análisis de requerimientos
❏ Validación de requerimientos
❏ Gestión de requerimientos
❏ El proceso de escribir los requerimientos del usuario y del sistema en un
documento formal

❏ Los requerimientos del usuario deben ser entendibles por los usuarios finales y los
clientes que no tienen experiencia técnica

❏ Los requerimientos del sistema son más detallados y pueden incluir más
información técnica

❏ Los requerimientos pueden ser parte de un contrato para el desarrollo del

sistema.

❏ Es importante que estos sean lo más completos posible

Notación Descripción

Lenguaje natural Los requerimientos se escriben usando oraciones numeradas en

lenguaje natural. Cada oración debe expresar un requerimiento.

Lenguaje natural Los requerimientos están escritos en lenguaje natural en un

estructurado formulario o plantilla estándar. Cada campo proporciona
información sobre un aspecto del requisito.

Lenguajes de descripción Este enfoque utiliza un lenguaje como un lenguaje de

de diseño programación, pero con características más abstractas para
especificar los requisitos definiendo un modelo operativo del
sistema. Este enfoque ahora se usa raramente, aunque puede ser
útil para las especificaciones de la interfaz.
Notación Descripción

Notaciones gráficas Los modelos gráficos, complementados con anotaciones de

texto, se utilizan para definir los requisitos funcionales del
sistema; Los diagramas de caso de uso y secuencia de UML se
usan comúnmente.

Especificaciones Estas anotaciones se basan en conceptos matemáticos como

matemáticas máquinas o conjuntos de estados finitos. Aunque estas
especificaciones inequívocas pueden reducir la ambigüedad en
un documento de requisitos, la mayoría de los clientes no
entienden una especificación formal. No pueden verificar que
representa lo que quieren y son reacios a aceptarlo como un
contrato del sistema
❏ En principio, los req’s deben indicar qué debe hacer el sistema y el diseño debe
describir cómo lo hace.

❏ En la práctica, los requisitos y el diseño son inseparables.

❏ Se puede diseñar una arquitectura del sistema para estructurar el requisitos;

❏ El sistema puede interactuar con otros sistemas que generan requisitos de

diseño;

❏ El uso de una arquitectura específica para satisfacer requisitos no funcionales

puede ser un requisito del sistema.

❏ Esto puede ser la consecuencia de un requisito reglamentario.

❏ Los requerimientos se escriben como oraciones en lenguaje natural
complementadas con diagramas y tablas.

❏ Se usa para escribir requerimientos porque es expresivo, intuitivo y universal.

Esto significa que pueden ser entendidos por los usuarios y clientes.
❏ Cree un formato estándar y úselo para todos los requerimientos.

❏ Usa el lenguaje de manera consistente, tanto para requerimientos obligatorios,

como para requisitos deseables.

❏ Utilice el resaltado de texto para identificar partes clave del requisito.

❏ Evite el uso de la jerga informática.

❏ Incluya una explicación (justificación) de por qué es necesario un requisito.

❏ Falta de claridad

❏ La precisión es difícil sin hacer que el documento sea difícil de leer.

❏ Confusión de requerimientos

❏ Los requerimientos funcionales y no funcionales tienden a ser confusos.

❏ Amalgama de requisitos

❏ Varios requerimientos diferentes pueden expresarse juntos.

3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10
minutes. (Changes in blood sugar are relatively slow so more frequent measurement is
unnecessary; less frequent measurement could lead to unnecessarily high sugar
levels.)
❏ Un enfoque para escribir requerimientos donde la libertad del escritor de
requisitos es limitada y se deben escribir de manera estándar.

❏ Esto funciona bien para algunos tipos de requisitos, p. requisitos para el sistema
de control integrado, pero a veces es demasiado rígido para escribir los requisitos
del sistema empresarial.
❏ Requerimientos funcionales y no funcionales
❏ El documento de especificación de requerimientos de software (SRS)
❏ Especificación de requerimientos
❏ Procesos de ingeniería de requerimientos
❏ Obtención y análisis de requerimientos
❏ Validación de requerimientos
❏ Gestión de requerimientos
❏ Los procesos utilizados para IR (Ing. de Req’s) varían ampliamente según el
dominio de la aplicación, las personas involucradas y la organización que
desarrolla los requisitos.

❏ Sin embargo, hay una serie de actividades genéricas comunes a todos los
procesos.

❏ Obtención de requisitos;
❏ Análisis de requerimientos;
❏ Validación de requisitos;
❏ Gestión de requerimientos.

❏ En la práctica, IR es una actividad iterativa en la que estos procesos se intercalan.

❏ Requerimientos funcionales y no funcionales
❏ El documento de especificación de requerimientos de software (SRS)
❏ Especificación de requerimientos
❏ Procesos de ingeniería de requerimientos
❏ Obtención y análisis de requerimientos
❏ Validación de requerimientos
❏ Gestión de requerimientos
❏ También se conoce como descubrimiento de requisitos.

❏ Involucra al personal técnico que trabaja con los clientes para conocer el dominio
de la aplicación, los servicios que el sistema debe proporcionar y las restricciones
operativas del sistema.

❏ Puede involucrar a usuarios finales, gerentes, ingenieros involucrados en

mantenimiento, expertos en dominios, sindicatos, etc (cualquier stakeholder del
sistema).
❏ Las partes interesadas no saben lo que realmente quieren.

❏ Las partes interesadas expresan los reqs en sus propios términos.

❏ Diferentes partes interesadas pueden tener requisitos en conflicto.

❏ Los factores organizativos y políticos pueden influir en los requisitos del sistema.

❏ Los requisitos cambian durante el proceso de análisis. Pueden surgir nuevos

stakeholders y el entorno empresarial puede cambiar.
❏ El equipo de desarrollo trabaja con una variedad de partes interesadas del sistema
para conocer el dominio de la aplicación, los servicios que el sistema debe
proporcionar, el rendimiento del sistema requerido, las restricciones de hardware,
otros sistemas, etc.

❏ Las etapas incluyen:

❏ Descubrimiento de requisitos,

❏ Clasificación y organización de requisitos,

❏ Priorización y negociación de requisitos,

❏ Especificación de requisitos.
TI-6502
Ingeniería de Requerimientos

Lic. Pedro I. Leiva Chinchilla