My main takeaway from this chapter is that I'd really like to read chapter 5. As mentioned in my previous post, real-world, practical examples are important to me. I've seen plenty of checklists of quality/non-functional requirements before and grids showing which quality attributes must be sacrificed when another needs to be emphasized. What really interests me is *how* do I make my system more modifiable.
That said, I do find the "Portion of Scenario/Possible Values" tables associated with each quality attribute to be useful. I feel that the authors did a good job of breaking the scenario into steps and providing possible values in a way that is practical, not overly academic. I often get frustrated with literature that feels too academic & disconnected from real-world software development projects. (My subscription to IEEE's Transactions on Software Engineering was a waste of money, whereas IEEE Software is filled with useful nuggets usually based off of case studies.)
I also liked how the authors gave examples of how usability often is an architectural concern & not just something that the front-end designers have to prototype & tinker with. I likely wouldn't have put cancel & undo functionality in this bucket and may have skipped over functionality like that in future planning discussions.
I'd like to give another shout out to Fredrik Kjolstad for his explanation of the difference in connotation of quality vs. non-functional requirements. As he said, "...one would be less inclined to write programs that are without quality attributes than programs without non-functionality." [http://fredrikbk.blogspot.com/2009/08/software-architecture-in-practice.html]
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment