Illspecified

Illspecified is a term used in design, engineering, and information systems to describe problems, requirements, or descriptions that lack explicit boundaries, constraints, or measurable criteria. When a statement is illspecified, stakeholders may interpret it differently, leading to inconsistent implementations. The term functions as a diagnostic label, signaling the need for clarification rather than a resolved design choice.

Origin and usage: The word combines ill- with specified and has appeared in project-management and software-engineering literature to describe ambiguous requirements. It is less a formal theory than a practical descriptor used by practitioners. Some analysts contrast ill-specified requirements with well-specified ones that include testable acceptance criteria, constraints, and verifiable performance metrics.

Causes and examples: Ill-specified statements arise from vague language, missing scope, conflicting priorities, or reliance on tacit knowledge. For instance, a user need that says "the system should load quickly" is ill-specified without a target latency, environmental conditions, or measurable thresholds. Similarly, a design constraint like "the product should be affordable" is ill-specified without a price range or justification.

Consequences: Projects may suffer from scope creep, rework, or disputes due to differing interpretations. Tests designed against ill-specified requirements may pass or fail inconsistently, undermining validation and stakeholder confidence.

Mitigation: Techniques include requirements elicitation, use cases, user stories with acceptance criteria, measurable targets, and formal specifications where appropriate. Prototyping, iterative development, and clear traceability between needs, requirements, and tests help reduce ill-specified aspects.

Related concepts include ambiguity, vagueness, underspecification, and requirements engineering.