Evaluations of Nonfunctional Requirements of Stock Trading App
Explore how to evaluate key nonfunctional requirements of a stock trading mobile app, including performance latency budgets, security measures like certificate pinning and idempotency keys, reliability under network volatility, usability across device tiers, and managing trade-offs. Understand how these quality attributes ensure a trustworthy and responsive user experience on mobile platforms.
In the previous lesson, we defined the system architecture, API contracts, and backend microservices integration for the stock trading app. We established the BFF aggregation layer, the WebSocket streaming pipeline, idempotency keys, and dual-path confirmation. Now we shift focus from what the system does to how well it does it.
Nonfunctional requirements (NFRs) are the quality attributes that determine whether a technically correct system delivers a trustworthy, responsive trading experience on resource-constrained mobile devices. This lesson evaluates five interconnected NFR categories for our trading app: performance, security, reliability, usability, and the trade-offs that bind them together under real device constraints.
Performance requirements and latency budgets
A mobile stock trading app operates under strict time constraints where even small delays erode user trust and can cost real money. Three performance NFRs anchor the system’s responsiveness.
End-to-end order placement latency: The total time from the user’s tap to server acknowledgment must remain under 500ms, with each segment of the flow allocated a specific budget.
Real-time price tick rendering: Price updates must appear on screen within 100ms of WebSocket delivery, ensuring traders see actionable data before it becomes stale.
Cold start time: The app must render first meaningful content within two seconds, so users opening the app during volatile markets can act immediately.
The streaming pipeline from our architecture lesson directly supports the rendering latency budget. The WebSocket tick batcher diffs incoming data against the current TradingState and propagates only changed fields to the UI layer. This means the rendering system never wastes cycles redrawing unchanged prices.
Rendering and network-layer performance
Watchlist screens during active trading sessions can display dozens of rapidly updating symbols. The frame rate target is 60fps, and achieving this requires
On the network layer, REST calls to the BFF use HTTP/2 multiplexing to avoid head-of-line blocking across concurrent requests. WebSocket payloads are serialized using Protocol Buffers rather than JSON, reducing both payload size and parsing overhead on the client. Static assets ...