What's changed: Initial version
5.2Requirements definition & non-functional requirements
Covers the distinction among business requirements (what the business must achieve), functional requirements (what the system realizes), and non-functional requirements (quality and constraints such as performance, availability, and security); the judgment of agreeing with users on the tradeoff between availability level and cost using IPA's non-functional requirement grades (availability / performance-extensibility / operability-maintainability / migratability / security / system-environment-ecology); and securing stakeholder requirements, requirements analysis, and traceability.
In requirements definition, "what the business wants to achieve," "what the system does for it," and "at what quality and constraints to realize it" are clarified while agreeing with stakeholders. These are distinguished as business requirements, functional requirements, and non-functional requirements; confusing them leaves "what a feature is for" and "how much quality is needed" vague downstream. Non-functional requirements in particular involve tradeoffs—raising availability raises cost—so it is important to show levels in stages using a framework like IPA's non-functional requirement grades and agree with users. This section covers the strategist's viewpoint of separating requirement types, judging non-functional tradeoffs, and bundling stakeholder requirements while preserving traceability.
5.2.1Distinguishing business, functional, and non-functional requirements
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.