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