The Requirements Engineering Handbook
En relación con el Debate iniciado en LinkedIn: Del ‘Requerimiento’ al ‘Caso de Prueba’, se hizo referencia a este libro y me pareció interesante acceder al link y conocer el contenido del mismo para compartirlo con Uds.
Antes que nada, y como opinión personal, pienso que cada uno de nosotros, mas allá de la actividad que tengamos, accedemos y utilizamos sistemas de información.
Como ‘usuarios’ de estos sistemas queremos que nos ofrezcan una cierta funcionalidad en base a la necesidad que tenemos, que sean sencillos de manejar, que automaticen algunas tareas, que nos brinden información útil y a tiempo, que sean seguros, estables, … sigo?
Ahora bien, dentro de un proyecto de desarrollo de software, sea que estemos como Líderes de proyecto, Analistas, Programadores o Testers, nos interesa siempre construir sistemas de información útiles, que permitan cubrir las expectativas de los usuarios que nos han solicitado el desarrollo del sistema, para resolver ciertos problemas que están teniendo y ofrecerles ventaja competitiva.
Los ‘usuarios’, …, que tema, ¿no?
Por lo general, los usuarios no son especialistas en sistemas (aunque cada día este aspecto se va revirtiendo) y como tal, no comunican sus necesidades en forma adecuada, muchas veces no saben lo que quieren o hasta incluso, no identifican sus verdaderos problemas o necesidades (para nosotros, ‘causa-raiz’).
Por otra parte, el equipo de desarrolladores (programadores para algunos) no es experto en procesos de negocio de usuarios, sí en dar una solución tecnológica.
Aquí es donde debe intervenir, a mi criterio, el Analista Funcional junto con el Analista de Calidad y/o Analista de Pruebas, ya que el ‘requerimiento’ es lo más importante en el desarrollo de sistemas.
Bien, vayamos al punto entonces, el contenido del libro es el siguiente:
1. The Importance of Requirements
-
What are Requirements and Why are they important?
-
Why Plan?
-
A suggested strategy
-
Requirements activities in the system life cycle
-
Investment in the requirements process
-
A process approach
-
The requirements plan
-
Factors affecting your career decisions
-
A comment concerning small projects
-
Summary
-
Case study
2. The roles of the RA
-
Suggested Roles of the RA
-
Summary
-
Case Study
3. Skills and characteristics of an effective RA
-
Skills of the RA
-
Characteristics of an Effective RA
-
Summary
-
Case study
4. Types of Requirements
-
Views of Requirements types
-
Definitions and Descriptions of Requirements types
-
Business Requirements
-
Stated Requirements versus Real Requirements
-
User Requirements
-
High-Level or System-Level Requirements
-
Business Rules
-
Functional Requirements
-
Nonfunctional Requirements
-
Derived Requirements
-
Design Requirements and Design Constrains
-
Performance Requirements
-
Interface Requirements
-
Verified Requirements
-
Validated Requirements
-
Qualification Requirements
-
The “Ilities” and Specialty Engineering Requirements
-
Unknowable Requirements
-
Product Requirements
-
Process Requirements
-
Logistics Support Requirements
-
Environmental Requirements
-
System, Subsystem, and Component Requirements
Terminologies to Avoid
-
Source or Customer Requirements
-
Nonnegotiable Versus Negotiable Requirements
-
Key Requirements
-
Originating Requirements
-
Other Guidelines
5. Gathering Requirements
-
Plan the Approach
-
Summary
-
Case Study
6. Best Practices for Requirements Development and Management
-
Summary
-
Case Study
7. The RA’s Speciality Skills
-
Summary
-
Case Study
8. An Integrated Quality Approach
-
Business Drivers for Quality
-
Management’s Role
-
GUiding Principles
-
Priority Management
-
The Components of an Integrated Quality Approach
-
Quality Improvement Techniques
-
The PDCA Cycle
-
How to Design a Process
-
Teamwork
-
Summary
-
Case Study: An example of Quality Improvement Sidetracked
9. A Vision for Requirements Engineering
-
How Should we support PMs?
-
How should we support Developers?
-
Summary
-
Case Study
10. Moving Forward: Knowable Requirements, Manageable Risks
-
Where to go from here
-
Moving Forward
-
A requirement Mandala
-
Summary
-
Case Study
Los invito a que se unan al grupo y puedan debatir en esta discusión asi como en todas las que están abiertas y que están relacionadas con nuestra actividad.
Gracias
Como estaba buscando artículos vinculados con la Estimación dentro del Software Testing, creí importante para todo aquel que se encuentre en la misma situación, poder ahorrarle algo de trabajo.
Les dejo un link a un blog donde Ingenieros de Sistemas graduados en la Universidad Nacional de Ingeniería (Lima – Perú), exponen diversas ideas sobre el enfoque de sistemas suaves y su relación con la ingeniería de sistemas, diversos enfoques orientados a la resolución de problemas o situaciones suaves (blandas), entre los cuales presentamos la Metodología de Sistemas Suaves (Checkland) y el Método Suave Riguroso (Hitchins).