When eliciting requirements, what are the three sources you draw from, and the three types of requirement you gather?

Sources: stakeholders, documents, and existing systems. Types: functional (e.g. "login"), quality/non-functional (e.g. "secure storage of log data"), and general conditions/regulations (e.g. "must be live by summer", "PCI-DSS compliant").

Eliciting requirements starts with a stakeholder analysis — getting to know all the involved parties — because people are the richest source. But requirements don't only come from people:

Three sources:

• Stakeholders — what the involved parties say they need (interviews, workshops).
• Documents — existing specs, policies, regulations, contracts.
• Systems — existing or neighbouring systems whose behaviour constrains the new one.

Three types you collect:

• Functional — a behaviour the system provides, e.g. login.
• Quality / non-functional — how well it behaves, e.g. secure storage of log data.
• General regulations or conditions — constraints framing the whole project, e.g. the system should be live in summer, or it must be PCI-DSS compliant.

Tip: Beginners only interview stakeholders and only capture features (functional). Mature elicitation also mines documents and systems, and deliberately hunts for the quality requirements and general conditions that nobody volunteers — security almost always hides in those last two buckets.