Capítulo 9. Arquitecturadel producto
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
En el ámbito del software, rara vez tenemos requisitos significativos. Incluso si los tenemos, la única medida de éxito que importa es si nuestra solución resuelve la idea cambiante que tiene el cliente de cuál es su problema.
Jeff Atwood
Los requisitos funcionales son el conjunto de objetivos para las posibilidades de nuestro producto que hacen lo que los usuarios quieren. El capítulo 8 trataba sobre el cumplimiento de los requisitos funcionales, aunque en ese momento no los llamábamos así.
Si eso es todo en lo que pensamos, acabamos con el equivalente en software de un pueblo Potemkin: una interfaz bonita que no funciona. Por eso, cuando pensamos en los requisitos no funcionales (NFR), tenemos en cuenta los atributos clave para los que diseñan los ingenieros, como el coste, la escalabilidad, la latencia, el rendimiento, la coherencia de los datos, la elasticidad y la disponibilidad. Y no hay que olvidar la privacidad y la seguridad, aunque no se traten aquí.
Los NFR son un medio para alcanzar un fin, más que un fin en sí mismos, y a veces representan cosas que los usuarios solo notan cuando no funcionan.
Me encanta este tema porque es el más técnico del libro y, sin embargo, se beneficia del pensamiento de producto. Diseñar una arquitectura de sistema para estos factores es una síntesis pura de un pensamiento e e centrado ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access