This document discusses considerations for defining and quantifying non-functional requirements (NFRs) such as performance, availability, and security for a software system. It recommends speaking to stakeholders to understand priorities, explaining tradeoffs in cost and schedule to agree on specific, measurable NFRs. It also provides examples of how to quantify NFRs related to response time, availability, security, and other quality attributes.

1. Yuriy Guts
R&D Engineer, Software Architect @ ELEKS

2. 1.How fast should the system perform?
2.How available should the system be?
3.How about security?

3. 1.How fast should the system perform?
2.How available should the system be?
3.How about security?
—As fast as possible!
—24 x 7 x 365!
—Everything should be secure!

4. •Data loss is not acceptable
•Every page should load within 500 ms
•The system should be extensible
•Changes to all sensitive data should be audited
•All code should be transparent and properly commented
•100% unit test coverage

5. 1.Speak to stakeholders in their own language.
2.Explain the tradeoffs in terms of cost, schedule, and realism.
3.Together, try to come up with specific, measurable NFRs.
4.Prioritize: the domain matters a lot!
Wouldn’t you?

6. Customer: —We want to have 100% system uptime.
Architect:—OK, that might be doable, but requires all components to be redundant and eligible for automatic failover. That would take a year and $1,000,000to implement. As an alternative, we can build a simpler system for $500,000 in 8 months but it will require manual maintenancein case of failure. Which one would be more suitable for you at this point?
Customer: —Let’s build the second option, it’s much cheaper and faster. We’re a startup and time-to-market is our top priority.

7. …and how to quantify NFRs

8. Response timeLatency
(!) Avoid 100% guarantees, measure it per operation type

9. Current expectation
Growth forecast
Average usage vs. Peak usage
Usually: “# of some-business-operations” per “unit-of-time”

10. Usually expressed in “nines”
E.g., 99.9% per year
Remember about hardware failure, system upgrade and rollback!

11. Should start with a threat model!
i.e., what we actually want to protect AGAINST
Is an integral part of the design, can’t just put it “on top” of existing system

12. Recovery Time Objective (RTO)
Recovery Point Objective (RPO)

13. Globalization = Internationalization + Localization
As with security, you can’t just put it “on top” of existing system

14. What data must be retained for a particular period of time?
What data must never leave the system or the premises?
What data must never be persisted to durable storage?

15. Accessibility
Documentation
Emotional Factors
Extensibility
Maintainability
Reliability
Testability
Usability

17. •Interoperability with existing systems
•Approved technology, IT policies
•Target platform, vendor relationships
•Technology maturity
•Open source technology
•Licensing
•Pricing

18. •Initial team ramp-up
•Team scalability
•Skills of people involved in the team
•On-demand education and consulting
•Delivery vs. Maintenance personnel skills

19. yuriy.guts@ eleks.com

20. 1.Len Bass, Paul Clements, Rick Kazman. “Software Architecture in Practice, 3rdEdition”.
2.Simon Brown “Software Architecture For Developers”.