Yuriy Guts

R&D Engineer, Software Architect @ ELEKS

1. How fast should the system perform?

2. How available should the system be?

3. How about security?

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!

• 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

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?

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,000 to implement.As an alternative, we can build a simpler system for $500,000 in 8 months but it will require manual maintenance in 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.

…and how to quantify NFRs

Response time

Latency

(!) Avoid 100% guarantees, measure it per operation type

Current expectation

Growth forecast

Average usage vs. Peak usage

Usually: “# of some-business-operations” per “unit-of-time”

Usually expressed in “nines”

E.g., 99.9% per year

Remember about hardware failure, system upgrade and rollback!

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

Recovery Time Objective (RTO)

Recovery Point Objective (RPO)

Globalization = Internationalization + Localization

As with security, you can’t just put it “on top” of existing system

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?

Accessibility

Documentation

Emotional Factors

Extensibility

Maintainability

Reliability

Testability

Usability

• Interoperability with existing systems

• Approved technology, IT policies

• Target platform, vendor relationships

• Technology maturity

• Open source technology

• Licensing

• Pricing

• Initial team ramp-up

• Team scalability

• Skills of people involved in the team

• On-demand education and consulting

• Delivery vs. Maintenance personnel skills

yuriy.guts @ eleks.com

1. Len Bass, Paul Clements, Rick Kazman.

“Software Architecture in Practice, 3rd Edition”.

2. Simon Brown “Software Architecture For Developers”.