Skip to content
Sunny Calculator Add-On

Quality Attributes

In addition to the functional requirements, the project has these quality attributes, essentially the non-negotiables for how the system should operate1:

[QA1] Reliability - Keeping Things Running

The Sunny Calculator AddOn needs to be available for generating customer offerings at least 99% of the time during business hours (Monday to Friday, 8 AM to 6 PM local time).

If the sales team can’t generate offers, it hits the bottom line directly. So, this isn’t just a nice-to-have; it’s crucial for day-to-day operations.

The system’s backbone needs to include solid error handling, constant monitoring, and maybe even some backup systems to ensure we hit that uptime target.

[QA2] Performance (Responsiveness) - Feeling Snappy

Loading the main offer configuration screen in the Sunny Calculator AddOn should take no longer than 3 seconds for 95% of users under normal use.

Even if lightning speed isn’t the top priority, a sluggish app makes for unhappy and unproductive users. It needs to feel quick and easy to use.

The way we fetch data, how fast the screen updates, and being mindful of any delays coming from other systems will all play a part in achieving this.

[QA3] Usability - Easy for the Sales Team

At least 80% of the sales folks should be able to create a standard customer offer (one product, standard tweaks) on their own within 10 minutes after their initial training on the Sunny Calculator AddOn.

If the sales team can’t pick it up quickly and use it efficiently, it won’t be the productivity booster we’re aiming for.

The design needs to be intuitive, user-friendly, and likely based on good UI/UX principles and feedback from the people who’ll be using it every day.

[QA4] Extensibility - Planning for the Future

The Sunny Calculator AddOn should be built with a modular design so that adding new features or connecting to other systems takes no more than about 2 person-weeks per average complexity feature (we’ll need to nail down what “average complexity” means later).

Business needs change, and the system will likely need to grow. We need to build it in a way that lets us add new stuff without tearing down the whole thing.

A modular architecture with clear boundaries between components and maybe even a plugin system would be the way to go here.

[QA5] Manageability (Implicit - Handling Changes from Elsewhere)

If another system changes something that affects what the user is currently doing in the Sunny Calculator AddOn (like a CRM update to the offer data), the AddOn needs to tell the user within 5 seconds. The notification should explain what changed and give them at least one way to deal with it (like refreshing the data or ignoring their local changes).

To keep things smooth for the user, the system needs to handle these external changes gracefully, prevent data mix-ups, and keep the user informed.

This means we’ll need ways to detect relevant external changes and a UI that can show timely, helpful messages with clear actions.

[QA6] Security (Implicit - Trusting the Azure Setup)

User login and permissions for the Sunny Calculator AddOn will be handled by our existing Azure Active Directory (or whatever the right Azure security services are). Only authorized users should be able to get in and do what they’re allowed to do, all managed centrally.

Security is non-negotiable, and using the Azure ecosystem gives us a solid and standard way to manage who can access the system.

The AddOn’s design needs to integrate cleanly with Azure AD (or the relevant services) for authentication and authorization, following the principle of giving users only the access they need.

[QA7] Testability (Implicit - Testing Even When Things Aren’t Ready)

The Sunny Calculator AddOn’s architecture should make it easy to test (unit tests, integration tests, maybe even full system tests) by letting us use fake versions (mocks) of all the external CRM APIs. This way, the developers can keep building and testing even if the real CRM APIs aren’t fully finished yet.

We can’t wait around for every single API to be perfect before we start testing. We need to be able to test as we go.

This means the architecture should use patterns like dependency injection or clear interfaces so we can swap out the real CRM API connections with these test fakes.

[QA8] Maintainability - Keeping it Tidy

The code for the Sunny Calculator AddOn needs to follow our coding standards and have enough comments so that any developer who hasn’t seen the code before can understand it and make changes without spending more than about a week on an average complexity change (again, we’ll need to define “average complexity”).

Keeping the codebase clean and understandable is key for fixing bugs and adding new stuff efficiently down the line.

This means clear coding styles, well-structured code, and good documentation throughout.

[QA9] Data Consistency (Implicit - Handling Multiple Changes)

If more than one person or system tries to change the same offer data at the same time, the Sunny Calculator AddOn needs to handle it in a way that prevents data from getting messed up or lost. The system should let the user know if there’s a potential conflict and give them ways to resolve it (like showing the different versions and letting them pick which one to keep).

We need to make sure the offer data stays accurate and reliable, even if multiple things are trying to change it at once.

The architecture will need strategies for managing concurrent access to data, maybe using techniques like locking, and a clear way for the user to deal with conflicts.

[QA10] Observability (Implicit - Keeping an Eye on Things)

The Sunny Calculator AddOn should log all the important stuff – system events, errors, how well it’s performing – in a way that the operations and support teams can easily see and understand. This will help them keep the app healthy, fix problems quickly, and spot areas where we can make things better.

Being able to monitor the system and see what’s going on under the hood is crucial for keeping it stable and performing well.

The architecture should include a good logging system and expose key metrics that can be plugged into monitoring tools.

Non-Goals (Explicitly Excluded Quality Attributes for Initial Phase)

For the first version of the Sunny Calculator AddOn, we’re not focusing heavily on:

  • Scalability: We don’t expect a huge number of users right away.
  • Failover / Disaster Recovery: Since the CRM holds all the important data, we’re not prioritizing complex failover for the AddOn itself right now.
  • Legal/Compliance/Regulatory: Specific legal or compliance rules aren’t a primary concern for this initial phase.
  • Auditability: Detailed logs of every user action aren’t a requirement at this point.
  • Performance (High Load/Complex Operations within AddOn): The initial set of features shouldn’t involve heavy processing within the AddOn itself (though we’re still mindful of how the other systems perform).

Open Questions and Future Considerations

To make sure we’re on the right track and to think about what might come next, we have a few questions:

  • External API Risk Assessment: Given how much the AddOn relies on the CRM and other external APIs, have you done a formal risk assessment on potential delays or instability with these, especially with testing planned for the end of June? Understanding this could help us plan better and maybe even offer our experience in managing these kinds of risks.
  • Performance Expectations of Other Systems: While we’re aiming for a snappy AddOn, the user experience will also depend on how fast the CRM, Pricing API, and Betterna are. Do you have specific performance targets or SLAs for these systems that the AddOn needs to work with? This would be good to know for our design and integration work.
  • Future Needs for Scalability and Availability: You mentioned that high usage and constant availability might be important down the line. Do you have any timelines or triggers in mind for when these might become bigger priorities? Knowing this early could help us build a more future-proof system.
  • Future Legal, Compliance, and Auditing: Even though it’s not a focus now, are there any upcoming legal, compliance, or internal auditing requirements that we should be aware of for the future, especially around data handling or logging? Getting a heads-up on this could save us some headaches later.
  • Overview of Other System Architectures: To make sure we integrate smoothly and avoid potential issues, could you give us a high-level picture of how the CRM, Sunny Konfigurator, and the systems hosting the Pricing API and Betterna are currently set up? Understanding their basic structure would be really helpful.

Footnotes

  1. A quality attribute or non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. [source] They must be realistic, SMART (specific, measurable, achievable, relevant and timely) and should be as precise as possible, leaving no interpretation to the reader. It is important to note that implicit quality attributes (attributes that are taken for granted) must also be listed. ↩