Pepelen
← Business and Systems Analysis from Scratch

Lesson

Requirement levels: from business need to system function

The learner can sort requirements into levels: business requirements → stakeholder requirements → solution requirements (functional + non-functional) → transition requirements.

1 / 8

Four types of requirements

From 'why' to 'how' — and the bridge to go-live

The running example follows one goal down through the types. Transition requirements sit to the side: they are needed only to get there.
Three stacked boxes connected by downward arrows: 'Business — why? Reduce churn by 15% in a year' → 'Stakeholder — what does each group need? Support agent sees full order history on one screen' → 'Solution', split into two side-by-side boxes 'Functional — what the system does: show last 12 months of orders' and 'Non-functional — how well: page loads in 2 s for 95% of requests'. To the right, a dashed box 'Transition — temporary: migrate old orders, train agents' with a clock icon.
Functional and non-functional are both solution requirements; transition requirements are temporary.
Generated diagram (Course Image Studio)
Lesson notes
From 'why' to 'how': the BABOK requirement hierarchy
Requirements don't all live on the same floor. BABOK (the Business Analysis Body of Knowledge) sorts them into four types, each answering a different question. Business, stakeholder and solution requirements go from abstract to concrete; transition requirements stand beside them, because they are temporary. Business requirements answer 'Why are we doing this?' They capture the organization's goal or problem — for example, 'Reduce customer churn by 15% within one year.' No technology is mentioned here. Stakeholder requirements answer 'What does each stakeholder or group need?' (users, but also managers, support staff, regulators). They sit one level down and describe what a person or role must be able to do to help the business reach its goal — for example, 'A customer support agent must be able to view a customer's full order history on one screen.' Solution requirements answer 'What must the system do, and how well must it do it?' They split into two sub-types. Functional requirements (FR) describe a specific behavior the system must perform — 'The system shall display the last 12 months of orders, sorted by date.' Non-functional requirements (NFR) set quality constraints — performance, security, usability, reliability — for example, 'The order history page shall load within 2 seconds for 95% of requests.' Both FR and NFR are sub-types of solution requirements.
Requirements that live only until go-live
Transition requirements answer 'What do we need only to get from the current state to the future state?' They cover things like data migration scripts and staff training materials. Once the transition is complete they are retired (closed and kept only for the record). A transition requirement may look functional ('import all historical invoices') or non-functional ('migrate within one weekend') — what makes it a transition requirement is that it is temporary.