Post on 20-Jul-2015
3. ANÁLISIS DE REQUERIMIENTOSIngeniería de SoftwareUTM 2017Mayo 2015
3.1 TÉ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
PRIMERO, ¿A QUIÉN ENTREVISTAR?
1.Clientes
2.Usuarios
3.Administradores
4.Socios
5.Expertos
6.Analistas de industria
7.Competencia
3
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
¿CUÁL TÉ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
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
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
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
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
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
EJEMPLO DE CONTENIDOS DE UN SRSIntroduction
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
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
EJEMPLO DE CONTENIDOS DE UN SRS
Logical database requirement
Software System attributes
Reliability
Availability
Security
Maintainability
Portability
Other requirements 13
3.4 INTRODUCCIÓN Y 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
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
JRDS VS 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
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