1. Analisis De Requisitos
1.1. Criterios de Clasificacion de requisitos
1.1.1. Si es funcional o NO lo es
1.1.2. Si esta derivado de uno o mas requsitos de alto nivel
1.1.3. Si el requsito esta en producto o en el proceso
1.1.4. La prioridad del requisito
1.1.5. El alcance del requsito
1.1.6. volatilidad del requsito
1.2. Modelo Conceptual
1.2.1. Naturaleza del problema
1.2.2. La maestria del ingeniero de software
1.2.3. Los Requisitos de proceso del cliente
1.2.4. Disponibilidad de Tecnicas y herramientas
1.2.5. Para tener en cuenta
1.2.5.1. en casi todos los casos, es útil comenzar construyendo un modelo del contexto del sofiware
1.2.5.2. El contexto del sofiware proporciona una conexion entre el software previsto y su ambiente externo
1.2.5.2.1. es crucial para entender el contexto del sostware en su ambiente operacional e identificar sus interfaces con el ambiente
1.2.5.3. La aplicacion de modelado se junta firmemente con la de los métodos. Para los propósitos practicos, un método es una notación (o sistema de notaciones) apoyado por un proceso que dirige el uso de las notaciones
1.2.5.4. el modelado formal usando notaciones basadas en matematica discreta, y que son detectables al razonamiento logico, han tenido impacto en algunos dominios especializandola.
1.2.5.5. Dos estandares que pueden ser utiles que pueden ser utiles en el desarrollo conceptual realizando el modelado IEEE conceptual std 132001, IDEF0 para funcional. IEEE std 1320.2 IDEFI X97 para modelado de informacion
1.3. Asignacion arquitectonica del diseño y de los requisitos
1.3.1. El diseño arquitectónico es el punto en el cual el proceso de los requisitos se junta con software o diseño de sistemas e ilustra cómo de imposible es desemparejar ambas tareas
1.3.2. el ingeniero del software actúa como arquitecto del software porque el proceso de analizar y de elaborar los requisitos exige que los componentes que seran responsables de satisfacer los requisitos estén identificados.
1.3.3. La asignación es importante para permitir analisis detallado de requisitos
1.3.4. En proyectos grandes, la asignación estimula un nuevo analisis para cada subsistema
1.3.5. El diseño arquitectónico se identifica de cerca con el modelado conceptual.
1.3.6. Los requisitos de notaciones y los métodos son ampliamente iguales para modelado conceptual y diseño arquitectónico.
1.3.7. IEEE Std 1471-2000, práctica recomendada para ladescripción arquitectónica de sistemas orientados al sofiware, sugiere un acercamiento del múltiple punto de vista para describir la arquitectura de sistemas y de sus artículos del sofiware. (IEEEl47l-00)
1.4. Negociacion de los Requisitos
1.4.1. Esto se refiere a problemas de resolución de los requisitos donde los conflictos ocurren entre dos stakeholders que requieren caracteristicas mutuamente incompatibles, entre los requisitos y los recursos, o en entre requisitos funcionales y no funcionales
1.4.2. en la mayoría de los casos, es imprudente para el ingeniero del software tomar una decisión unilateral, y hace necesario consultar con los stakeholders para alcanzar un consenso en una compensación apropiada
1.4.3. se ha clasificado esto como asunto del analisis de requisitos del software porque los problemas emergen como resultado el análisis. Sin embargo, un caso fuerte se puede también hacer para considerar los requisitos como asunto de la validación.
2. Proceso de los requisitos
2.1. Modelo de Proceso
2.1.1. Es un proceso iniciado en el principio de proyecto y acontinuacion refinado durante del ciclo vital
2.1.2. Identifica los requisitos del software como elementos de configuracion y los gerencia de la configuracion del software
2.1.3. Necesita ser adaptado a la organizacion y al contexto del proyecto
2.2. Agentes de Proceso
2.2.1. Usuarios
2.2.2. clientes
2.2.3. Analistas de mercado
2.2.4. Reguladores
2.2.5. Ingenieros de Software
2.3. Calidad y mejora del proceso
2.3.1. cobertura de proceso de los requisitos mediante estandares y modelos de la mejora
2.3.2. Medidas de procesos de requisitos de los requisitos y benchmarking
2.3.3. Plan de mejora y puesta en practica
3. No siempre es posible satisfacer de los stakeholders y es trabajo de los ingenieros negociar las compensaciones dentro de un presuspuesto regulado
4. Captura de Requisitos
4.1. Fuentes de Requisitos
4.1.1. Metas
4.1.2. Conocimiento del Dominio
4.1.3. StakeHolder
4.1.4. Entorno Operacional
4.1.5. Entorno Organizacional
4.2. Técnicas de Captura
4.2.1. Entrevistas
4.2.2. Escenarios valiosos
4.2.3. Prototipos
4.2.4. Reuniones
4.2.5. Observacion
5. ejemplo: requisitos para el funcionamiento de los frenos de un coche (distancia que frena, seguridad en condiciones que conducen, suavidad del uso, la presión del pedal requerida, y asi sucesivamente) se puede asignar un hardware que frena (montajes mecánicos e hidráulicos) y un sistema de frenos antibloqueo (ABS). Solamente cuando un requisito para un sistema de frenos antibloqueo ha sido identificado, y los requisitos asignados a él, pueden usarse las capacidades del ABS, el hardware de frenado identificado, y las caracteristicas indefinidas (tales como el peso del coche) para identificar los requisitos detallados del sofiware del ABS.
6. Especificacion de requisitos
6.1. se refiere a la asignación de valores o límites numéricos para metas del diseño del producto.
6.1.1. Para los sistemas complejos, particularmente ésos que implican componentes no- sofiware, se elaboran tres tipos de documentos
6.1.1.1. definición de sistema,
6.1.1.2. sistema requisitos,
6.1.1.3. requisitos del software.
6.2. El documento de la definición de sistema
6.2.1. Define los requisitos del sistema de alto nivel desde la perspectiva del dominio
6.2.2. documento enumera los requisitos del sistema junto con información de fondo sobre los objetivos totales para el sistema, su ambiente de misión y una declaración de apremios, asunciones, y requisitos no funcionales
6.2.3. IEEE Std 1362, concepto del documento de las operaciones, proporciona consejo sobre la preparación y contenido de tal documento.
6.3. Especificación de requisitos del sistema
6.3.1. separa a menudo la descripción de los requisitos del sistema de la descripción de los requisitos del sofiware
6.3.2. En esto se especifica la visión, requisitos del sistema, los requisitos sofiware se derivan de los requisitos del sistema, y entonces los requisitos para los componentes de software se especifican.
6.4. Especificación de requisitos del software
6.4.1. la especificación de requisitos del software establece la base para el acuerdo entre los clientes y los contratistas o los proveedores en los que hay que hacer el producto de sofiware, asi corno lo que no se espera que haga.
6.4.2. Para los lectores no tecnicos, el documento de la especificación de los requisitos es acompañado a menudo por un documento de la definición de los requisitos del soflware.
6.4.3. la especificación de requisitos del software permite un riguroso gravamen de requisitos antes de que el diseño pueda reducir un reajuste final.
6.4.4. la especificación de requisitos software proporciona una base informada para transferir un producto de software a los nuevos usuarios o a las maquinas nuevas Finalmente, puede proporcionar una base para el realce de software.
6.4.5. Los requisitos del sotware se escriben a menudo en lenguaje natural, pero, en la especificación de requisitos del software, ésta se puede suplir por fomal o semiformal
6.4.6. La regla general es que las notaciones deben ser utilizadas para que permitan a los requisitos ser descritos tan exactamente como sea posible
6.4.7. la opción de la notación es obligada a menudo por el entrenamiento, las habilidades y las preferencias de los autores y de los lectores del documento.
6.4.8. Se han desarrollado un número de indicadores de la calidad para relacionar la calidad de la especificación de requisitos del software a otras variables del proyecto
6.4.9. IEEE tiene un estándar, IEEE Std 830 [lEEE830-98], para producción y contenido de la especificación de los requisitos del software. También, IEEE 1465 (similar a ISO/IEC 12119) es un estándar que trata requisitos decalidad en paquetes de software. (lEEEl465-98)
7. Se refiere al analisis,especificacion y validacion de los requsitos de software
7.1. Producto y requsitos del proceso
7.1.1. Parametros del producto
7.1.2. Parametrso del proceso
7.2. Requsitos de Software
7.2.1. Caracteristica que debe exhibir para solucionar un problema de la vida real
7.2.2. Presentan Una serie de Caracteristicas
7.2.2.1. Ser comprobable
7.2.2.2. Poseer una tasa de proridad
7.2.2.3. Poseen un valor de Estado
7.2.3. Se pueden Clasificar
7.2.3.1. Requisitos funcionales
7.2.3.2. Requisitos No funcionales
7.2.4. Requisitos Cuantificables
7.2.4.1. Los Requsitos deben indicarse clara e inequivocamente, y cuantitativamente
7.2.5. Caracteristicas Inesperadas
8. Validación de los requisitos
8.1. Los requisitos pueden ser validados para asegurarse de que el ingeniero del software entiende los requisitos, y es también importante para verificar que un documento de requisitos se conforma con la compañia de los estándares, y este es comprensible, constante, y finito.
8.1.1. Diversos stakeholders, incluyendo los representantes del cliente y del revelador, deben también repasar los documentos. Los documentos de los requisitos son conformes a las mismas practicas de gerencia de la configuración del software como los otros puntosrelevantes de los procesos del ciclo de vida del software.
8.2. Revisiones de los requisitos
8.2.1. los medios mas comunes de la validación estan cerca de inspección o revisiones de los documentos de los requisitos
8.2.2. Asignan un grupo de revisores en un escrito para buscar errores, asunciones confiindidas, la carencia de la claridad, y la desviación de la costumbre.
8.2.2.1. La composición del grupo que conduce la revisión es importante (por lo menos un representante del cliente debe ser incluido para un proyecto cliente-conducido, por ejemplo), y puede ayudar a proporcionar la dirección en que' buscar bajo listas de comprobación
8.2.2.2. Las revisiones se pueden constituir en el final del documento de definición del sistema, el documento de la especificación de sistema, el documento de la especificación de requisitos del software, especificación de la linea de fondo para un nuevo lanzamiento, o en cualquier otro paso en el proceso
8.2.3. IEEE Std 1028 proporciona la dirección para conducir tales revisiones. (IEEE1028-97)
8.3. Prototipado
8.3.1. Prototipar es comúnmente el medio para validar la interpretación del ingeniero del software de los requisitos del sofiware, así como para sacar nuevos requisitos.
8.3.2. La ventaja de usar prototipos es que pueden hacer mas facil la interpretación de las asunciones del ingeniero del software y, donde lo necesite, dan la explicación útil de porqué son incorrectas.
8.3.3. Hay también desventajas, sin embargo. Éstos incluyen el peligro de la atención de los usuarios que es distraída de la base de la funcionalidad subyacente por las ediciones o los problemas cosméticos de la calidad con el prototipo.
8.3.4. Los prototipos pueden ser costosos. Sin embargo,si evitan el despilfarro de los recursos causados intentando satisfacer requisitos erróneos, su coste puede ser justificado
8.4. Pruebas de aceptacion
8.4.1. Una característica esencial de un requisito del software es que debe ser posible validar que el producto final lo satisface
8.4.2. Una tarea importante es por lo tanto planear cómo verificar cada requisito
8.5. Validacion del modelo
8.5.1. Es típicamente necesario validar la calidad de los modelos desarrollados durante el análisis. Por ejemplo, en modelos de objeto, es útil para realizar un análisis estático para verificar que las trayectorias de comunicación existen entre los objetos que, en dominio de los stakeholders, intercambian datos
8.5.2. Si las notaciones de especificación formal se utilizan, es posible utilizar el razonamiento formal para probar caracteristicas de la especificación.
9. Consideraciones practicas
9.1. Los requisitos procesan palmos de todo el ciclo de vida del software
9.1.1. Cambiar la gerencia y el mantenimiento de los requisitos en un estado que refleja exactamente el software que se construirá, o se ha construido, es clave para el éxito del proceso ingenieria del sofiware
9.1.2. No toda organización tiene una cultura de documentación y manejo de requisitos. Es frecuente en las compañías de start-up dinámicas, conducidas por una “visión fuerte del producto” y recursos limitados, para ver la documentación de los requisitos como gastos indirectos innecesarios
9.2. Naturaleza iterativa del proceso de los requisitos
9.2.1. Hay presión general en la industria del software para ciclos de desarrollo más cortos, y esto está particularmente pronunciado en sectores del mercado altamente competitivos
9.2.1.1. la mayoría de los proyectos son obligados de cierta manera por suambiente, y muchas son mejoras, o revisiones, del sofiware existente donde está la arquitectura
9.2.2. es casi siempre impractico poner el proceso de los requisitos en ejecución como proceso lineal, determinista en el cual los requisitos del sofiware se saquen de los stakeholders, asignado, y entregado al equipo de desarrollo del software.
9.2.3. los requisitos iteran típicamente hacia un nivel de calidad y detallan que es suficiente permitir las decisiones del diseño y de la consecución que se haran.
9.2.4. los ingenieros del software son obligados necesariamente por planes de la gerencia de proyecto y deben por lo tanto tomar medidas para asegurarse de que la “calidad” de los requisitos es tan alta como sea posible dado los recursos disponibles. Deben, por ejemplo, hacer explícita cualquier asunción que sostengan los requisitos, asi como cualesquiera problemas sabidos.
9.2.5. Los requsitos varian de mayor a menor frecuencia de acuerdo a diversos factores como el ambiente donde se ejcutan etc
9.3. Cambiar a gestion
9.3.1. La gestión del cambio es central en el analisis de requisitos. Este asunto describe el papel de la gestión del cambio, los procedimientos que necesitan estar preparados, y el análisis que se debe aplicar a los cambios propuestos. Tiene acoplamientos fuertes a la configuración del software KA de la gestión.
9.4. Cualidades de los requsitos
9.4.1. Los requisitos deben consistir no sólo una especificación de que se requiere, sino también de la información ancilar que las ayudas manejan e interpretan los requisitos. Esto debe incluir varias dimensiones de la clasificación del requisito
9.4.2. Los requisitos más importantes atribuyen, sin embargo, un identificador que permite requisitos identificados inequívocamente.
9.5. El remontar de los requisitos
9.5.1. El remontar de los requisitos se refiere a la fuente recuperación de requisitos y de predecir los efectos de esos requisitos
9.5.2. Los requisitos que remontan para un proyecto tipico formarán un gráfico acíclico dirigido complejo (DAG) de requisitos.
9.6. Requisitos que miden
9.6.1. Como cuestión práctica, es típicamente útil tener cierto concepto del “volumen” de los requisitos para un producto de software particular
9.6.2. Este punto es útil evaluando el “tamaño” de un cambio en requisitos, en estimar el coste de una tarea del desarrollo o del mantenimiento, o simplemente para el uso como el denominador en otra medida
9.6.3. La medida funcional del tamaño (FSM) es una tecnica para evaluar el tamaño de un cuerpo de requisitos funcionales. IEEE Std 14143.1 define el concepto de FSM. [IEEEl4l43.l-00] Estándares de ISO/IEC y otras fiientes describen