Following on in my series on software quality, I want to delve into one of the characteristics of software quality that I feel is often overlooked—or rather, the importance of which is not always fully understood. What may surprise you is that it’s not really about how the software is built, but rather about why it’s built at all! This post will explore the quality characteristic of functional suitability—especially the why of software.

Functional Suitability

First off, for quick reference, here is the definition of functional suitability according to the ISO 25010 Software Product Quality Model:

This definition is a bit abstract and can be difficult to understand when applied to an actual piece of software. In fact, this characteristic was one of the hardest for me to grasp when I first explored this quality model. However, I’ve come to understand it as simply asking: Are we building the right thing?

I’ve come to understand it as simply asking: Are we building the right thing?

Let’s dive a bit deeper into the sub-characteristics. First up—functional completeness. To me, this means understanding whether the features and functionality we design and build actually solve the user’s problems. In other words, if a user sets out to use your software for a particular reason, can they actually accomplish that goal? It’s less about how well it solves the problem or how good the experience is (those aspects are covered in other characteristics) and more about the fundamental question of whether the software simply does what the user needs.

Next—functional correctness. I won’t dwell on this too much in this post, as it could be a topic of its own. Essentially, this boils down to testing your software. Does it do what it was designed to do, accurately and as intended? Regardless of how it’s tested (manual, automated, etc.), the goal is to verify that the system’s functionality works as expected.

Lastly, we have functional appropriateness. This one is a bit harder to explain, but I ultimately see it as understanding how easy it is for users to do what they need to do with your software. Are they able to find and use the specific functionality they need efficiently, or do they have to navigate through unnecessary features just to complete their tasks?

Functional Completeness and the Quality of Requirements

Digging deeper into the sub-characteristic of functional completeness, we see that it ultimately comes down to the system’s requirements. Depending on your context, gathering these requirements can be quite a challenge. They may come from subject matter experts in an organization, individual customers in a target market, or even the customers of the company for which the software is being built. In that last scenario, getting face time with indirect customers can be particularly difficult—companies often guard their customer base closely and may not allow direct or unrestricted interaction.

I’m no expert in requirements elicitation or requirements engineering techniques, but over the years, I’ve encountered a lot of software requirements—some good, some bad, and many in between. During that time, I’ve compiled a checklist that can help assess the quality of requirements-you should be able to answer or provide information for each point in this checklist. Feel free to use it to evaluate your own requirements.

## Requirements checklist

### The Why

- [ ] What value does business or users get out of this feature/story?
- [ ] Does it align to a business strategy or initiative?
- [ ] Who are the stakeholders for this feature/story?

### The What

- [ ] What's out of scope?
- [ ] What's in scope?
  - [ ] User journeys / stories and use cases
  - [ ] Functionality
  - [ ] Priority
  - [ ] Expected outcomes
- [ ] What is expected - Acceptance Criteria
  - [ ] Is it validated (what the customer wants) - 'signed off' by requesting customer
  - [ ] Is it verifiable (it does what requirement says) - sufficient to make test cases
- [ ] Assumptions and Constraints

### The Who

- [ ] Which persona / roles are applicable to this feature/story
- [ ] What is the key task they are aiming to perform with this feature/story

### The How

- [ ] How does it currently work
  - [ ] Process
  - [ ] Pain points
  - [ ] Inefficiencies
- [ ] How is it proposed to work (to be)
  - [ ] What are the improvements on current
- [ ] How will the user experience this feature/story
  - [ ] Designs/Wireframes
  - [ ] Journey/Transitions
  - [ ] Error states

### The When

- [ ] Can we work on this now?
  - [ ] Internal dependencies - other features/stories
  - [ ] External dependencies - other teams/systems
    - [ ] Existing?
    - [ ] New?

### Data

- [ ] Types of data needed
  - [ ] Formats
  - [ ] Protocols
- [ ] Where does the required data come from?
- [ ] Where does the data need to be sent to / stored?
- [ ] How long does it need to be kept (retention)?

### Non-functional Considerations

- [ ] Performance: Expected response times, throughput, peak usage
- [ ] Security: RBAC, Compliance, Regulations
- [ ] Scalability: # of users, load (current and predicted)
- [ ] Usability: accessibility, ui guidelines
- [ ] Auditability: what needs to be audited

On Completeness vs. Appropriateness

When evaluating functional appropriateness, the best way to assess quality is by talking to your users. Whether through user interviews, user acceptance testing, direct observation, or feedback, user insights are invaluable in determining whether the software is appropriately built—not just functionally complete. Ideally, users should be involved throughout the design and development process. The earlier you can gather this feedback, the better.

Typically, you define what is functionally complete (or complete enough for a minimum viable product) early in a software project, while evaluating appropriateness tends to lag behind. You may prototype the software, create a proof of concept (PoC), or build out a portion of the actual software to assess appropriateness. However, these approaches take time. Identifying what’s most crucial for users and getting that into their hands as soon as possible can save you a lot of effort down the line.

That said, business context matters! If you’re re-engineering an existing product on a modern tech stack or redesigning the user experience, you already have a production user base. That alone provides a wealth of information without the need to revalidate all requirements from scratch. This is particularly relevant when developing software for larger companies with established customer bases—they often already know what they need. In such cases, the focus shifts from redefining functionality to improving and advancing the software and user experience.

Build the Right Thing Over Building It Right

This might be a controversial take in some circles, but I prioritize building the right thing over building it right. By “building it right,” I mean following best practices, writing scalable and maintainable code, and ensuring architectural soundness. To be clear, I’m not advocating for disregarding best practices. Rather, I believe that building the right thing should take precedence—especially early in the process.

After all, if you don’t build the right thing, you won’t have any users. And without users—what’s the point of your software?