SPRG Logs
A requirement is (1) a condition or capability a user needs to solve a problem, (2) a condition or capability a system must possess to satisfy a contract or standard, or (3) a documented representation of (1) or (2).
The three-part definition is deliberately layered, because the...
Q When choosing how to represent a requirement, what are the four "degrees of freedom" you can dial?
You can choose the instrument (natural language → structured models → interaction models → formal model), the structure, the precision, and the depth (deepness) of the representation.
* Four dials you set independently; turning any of them up costs more effort, so each is scaled...
Q What is the difference between a functional requirement and a quality (non-functional) requirement?
A functional requirement says what the system does — a result or behaviour a function must provide; a quality requirement says how well it does it (performance, availability, security…) and is defined as everything not covered by the functional ones.
This is the most fundamental...
Q What are the four core activities of requirements engineering, and over what span are they carried o...
Elicit the stakeholders' requirements, document them suitably, validate and verify them, and manage them — and you do all four across the entire life cycle of the system, not just once at the start.
* Management is drawn as the band around the other three, not as a fourth step i...
Q What is the difference between System Boundary and Context Boundary in requirements engineering?
The system boundary draws the line between the system and its environment; the context boundary draws a second, outer line between the environment that matters and the environment you can ignore.
* The system boundary separates the system from its environment; the context bounda...
Q What is the goal of requirements engineering, and why does it put so much weight on achieving consen...
The goal is to know the relevant requirements, reach a consensus among stakeholders about them, document them to standards, and manage them systematically — all to minimise the risk of delivering a system that does not meet the stakeholders' real needs.
Requirements engineering i...
Q What is the correct mindset for Requirements Engineering regarding specification completeness?
Don't ask "is the spec complete?" — ask "how much must we invest to shrink the risk to a size we can accept?" Completeness is never the goal; managed risk is.
* The stopping point is set by the risk this project can accept — the same curve, two different answers. *
The naive fra...
Q Once requirements are elicited, which models are used to document them, and what does each one captu...
Three modelling views — a system component diagram (components + interfaces), a use case diagram (actors + functions) and a business object model (business objects + relationships) — plus screen flows, the screens themselves and the outputs, with anything left over listed and ref...
Q What is a Requirement Specification, and what are the key types of Non-Functional Requirement?
A requirement specification is a systematically organised collection of requirements for a system or component that satisfies given criteria; non-functional requirements are the "how well" qualities — performance, scalability, portability, usability, compatibility, localization,...
Q When eliciting requirements, what are the three sources you draw from, and the three types of requir...
Sources: stakeholders, documents, and existing systems. Types: functional (e.g. "login"), quality / non-functional (e.g. "secure storage of log data"), and general conditions or regulations (e.g. "must be live by summer", "PCI-DSS compliant").
* Any source can yield any of the t...