Siguiendo con los apuntes de la materia de Ingeniería de Software (UTM 2170) están las notas de Análisis de Requerimientos.

1. 3.ANÁLISIS DE REQUERIMIENTOS
Ingeniería de Software
UTM 2017
Mayo 2015

2. 3.1TÉCNICAS DE RECOLECCIÓN DE
INFORMACIÓN
¿Cuáles son las técnicas que utilizamos
para obtener información de nuestros
clientes (usuarios) para conocer y
entender qué es lo que tendremos que
desarrollar?
2

3. PRIMERO, ¿A QUIÉN ENTREVISTAR?
1.Clientes
2.Usuarios
3.Administradores
4.Socios
5.Expertos
6.Analistas de industria
7.Competencia
3

4. TÉCNICAS UTILIZADAS
Entrevistas uno a uno
Entrevistas grupales
Focus Group
Cuestionarios
Prototipos
Casos de Uso
Shadowing (seguir usuarios)
Request for Proposal (RFPs)
Lluvia de ideas
4

5. ¿CUÁLTÉCNICA APLICAR?
Disponibilidad y localidad de los stakeholders
Conocimiento del equipo de desarrollo sobre el problema
Conocimiento de los clientes y usuarios sobre el problema
Conocimiento de los clientes y usuarios sobre el proceso de desarrollo y métodos
Gathering Techniques
http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/
req_gathering_techniques_8CB8E44C.html
5

6. 3.2 IDENTIFICACIÓN DE REQUERIMIENTOS
Existe una gran cantidad de requerimientos que pudiéramos encontrar, por lo que se hace necesario
organizarlos en categorías. Las categorías más comunes son:
Requerimientos del Cliente
Requerimientos de la Arquitectura
Requerimientos de la Estructura del Sistema
Requerimientos de Comportamiento
Requerimientos Funcionales
Requerimientos No Funcionales
Funcionalidad Básica (Core)
Requerimientos de Ejecución
Requerimientos de Diseño
Etc. 6

7. REQUERIMIENTOS DEL CLIENTE
Distribución operacional: ¿Dónde se utilizará el sistema?
Misión o escenario: ¿Cómo cumplirá el sistema su misión objetivo?
Performance y sus parámetros: ¿Cuáles son los parámetros críticos para cumplir su misión?
Ambientes de utilización: ¿Cómo son los diferentes componentes a ser usados por el sistema?
Requerimiento de efectividad: ¿Qué tan efectivo y eficiente debe ser el sistema para cumplir con su misión?
Ciclo de vida operacional: ¿Por cuánto tiempo deberá hacer uso el usuario el sistema?
Environment: ¿En qué ambientes deberá ser utilizado el sistema de manera efectiva?
7

8. REQUERIMIENTOS FUNCIONALES
Los requerimientos funcionales explican qué es lo que se debe
hacer, identificando las tareas necesarias, acciones o actividad a
desarrollar. El análisis de los requerimientos funcionales deben ser
consideradas funciones de alto nivel para el análisis funcional.
8

9. REQUERMIENTOS NO FUNCIONALES
Requerimientos no funcionales son requerimientos que especifican el criterio que deberá
ser usado para juzgar la operación de un sistema basado en requisitos no funcionales (eg. de
comportamiento).
Factores comunes son: usabilidad, accesibilidad, emoción, documentación, etc.
9

10. ANÁLISIS DE REQUISITOS BASADOS EN EL
ESTÁNDAR IEEE 830-1993 (1998)
Un SRS (Software
Requirements Specification)
es una descripción de un
sistema a desarrollar
indicando los
requerimientos
funcionales y no
funcionales, así como
puede incluir también
casos de uso que
describe las interacciones
del usuario con el
software.
10

11. EJEMPLO DE CONTENIDOS DE UN SRS
Introduction
Purpose
Definitions
System overview
References
Overall description
Product perspective
System Interfaces
User Interfaces
Hardware interfaces
Software interfaces
Communication Interfaces
Memory Constraints
Operations
Site Adaptation Requirements
11

12. EJEMPLO DE CONTENIDOS DE UN SRS
Product functions
User characteristics
Constraints, assumptions and dependencies
Specific requirements
External interface requirements
Functional requirements
Performance requirements
Design constraints
Standards Compliance 12

13. EJEMPLO DE CONTENIDOS DE UN SRS
Logical database requirement
Software System attributes
Reliability
Availability
Security
Maintainability
Portability
Other requirements 13

14. 3.4 INTRODUCCIÓNY APLICACIÓN A LOS
MÉTODOS ESTRUCTURADOS
El proceso del análisis de requerimientos incluye las siguientes etapas:
Análisis
Documentación
Validación
Administración
14

15. HABILIDADES NECESARIAS
Obtención de requerimientos: la documentación de los procesos de negocios, entrevistas
con los stakeholders. Esto se llama recopilación de requerimientos (Se requieren habilidades
tanto diplomáticas como gerenciales)
Análisis de requerimientos: determinar si los requerimientos son claros, completos,
consistentes y no tienen ambigüedad. Estos requerimientos deberán resolver el (los)
problemas descritos. (Se esperan habilidades de organización, abstracción y análisis de datos)
Registro de requerimientos: los requerimientos serán registrados de varias formas,
normalmente por escrito y en listas numeradas, así como también relatos en lenguaje natural,
casos de uso, historias de usuario, definición de procesos, etc.
15

16. JRDSVS MARCO CONTRACTUAL
Joint Requirements Development (JRDs)
Es la obtención de los requerimientos a través de sesiones moderadas con los stakeholders y
dirigida por alguien de nuestro equipo de trabajo.
Marco Contractual
Es la descripción de los requerimientos de manera completa (y compleja) siguendo la
metáfora de la lista de mandado, todos los requisitos se van anotando en un solo documento.
- desarrollo Ágil?
16

17. Stakeholder issues
Steve McConnell, in his book Rapid Development, details a number of ways users can inhibit requirements gathering:
• Users do not understand what they want or users don't have a clear idea of their requirements
• Users will not commit to a set of written requirements
• Users insist on new requirements after the cost and schedule have been fixed
• Communication with users is slow
• Users often do not participate in reviews or are incapable of doing so
• Users are technically unsophisticated
• Users do not understand the development process
• Users do not know about present technology
This may lead to the situation where user requirements keep changing even when system or product development
has been started.
17