• Skip to main content
  • Skip to header right navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Engineering Books
  • Lessons in Software
  • Archives
  • JD Meier.com

Quality Attribute List

Jun 1, 2008 by JD

When thinking about quality, I tend to draw from the following quality attributes:

  • Availability
  • Buildability
  • Conceptual Integrity
  • Evolvability
  • Extensibility
  • Functionality
  • Implementation Transparency
  • Integrability
  • Interoperability
  • Maintainability
  • Performance
  • Portability
  • Reliability
  • Reusability
  • Scalability
  • Security
  • Serviceability
  • Subsetability
  • Supportability
  • Testability
  • Usability
Category: Architecture, Performance, Requirements, SecurityTag: Performance, Qualities, Security

About JD

Previous Post:App Types, Verticals, and Scenarios
Next Post:Quality Attributes Frame

Reader Interactions

Comments

  1. Seth Morris

    Aug 18, 2008 at 11:19 am

    These qualities–criteria, really–are applicable at every level where we desire quality (and are how we can define and measure quality).

    As an example, when I work with dev teams I get them in a room and start a list like this on the whiteboard, asking each developer what 2 or 3 things they most value in their code, in a design, etc. I do the usual NLP hierarchy or criteria process (“what would be so important that it caused you to choose a less-reliable solution over a more-reliable one?” etc.) if I need to elicit more.

    Then, I have the tech lead(s) define the shared team hierarchy. The top 5+-2 get put up on the wall in the dev pit, included in emails about code, and are written on the whiteboard at every code review.

    “I think this is better” is great to hear (and encouraged); “this supports a higher criteria for this project” is a) behavioral as opposed to personal, b) cuts down on philosophizing when it’s not appropriate, c) teaches more-junior developers not only what to prefer and why to prefer it, but what process to use to make that decision, and d) gets the team using *shared* criteria.

    Teams with shared criteria are routinely more successful, have better cohesion, have a lower “bus number”, and produce fewer surprises for S&M, support, and customers. It’s also nice that explicit criteria like these, whether for QA of the product or making decisions in the implementation, helps people keep their personal preference for criteria separate from the project’s preference and still be committed to the project. (i.e., it helps avoid the “I can write LISP in any language!” and “I can shave a couple of clock cycles off this once-a-week process, no matter how many tricks I need to use!” syndromes, plus it makes it easier to address as behavior rather than intention).

    In all cases, of course, criteria are heterarchies rather than hierarchies. That’s where the artistry of the more senior engineers comes in. And sometimes the politics between stakeholders 🙂

    Great list!

  2. JD

    Aug 20, 2008 at 6:29 am

    Great rundown and details Seth!

    I like your focus on shared values and your approach to team mentoring. I really like your distinction between personal preferences and project preferences.

Trackbacks

  1. Quality Attributes Frame says:
    Jun 1, 2008 at 4:02 am

    […] Quality Attribute List No Comments, Comment or Ping […]

Sidebar

Recent Posts

  • Best Software Books of All Time According to a Microsoft Exec
  • How To Effectively Pitch a Business Idea (Customer, Problem, Competition, and Success)
  • Customer-Connected Engineering at patterns & practices
  • Lessons in Software Development from Eric Brechner
  • Best Practices at patterns & practices

Popular Posts

Best Software Engineering Books
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future