ABSTRACT
DeMarco (1996) observed that “ill-specied systems are as common today as they were when we rst began to talk about requirements Engineering.” One major problem child at the threshold from business to software development is the form of requirements and the manner of how well they are formulated by business for software engineering. Subsequently, ambiguous descriptions foster software failures. Throughout the various stages of software development, different stakeholders want different levels of abstraction and views, which, altogether, a software development approach and its models need to reect. The very essence is the problem statement (PS) that is echoed within multifarious layers of software engineering, encapsulates notions at variform degrees of granularity, and is thus central to business and engineering layers. The PS is a textual description in the form of a narrative like a well-crafted, well-focused, nonverbose, and grammatically correct essay written in well-structured language to capture the subtlety of the problem in detail. Contrary to the existing practice in the real world, engineering processes necessitate meaningful and undisguised descriptions. The almost forgotten PS as known since the 1970s (cf. Nunamaker et al. 1976) and especially when coupled with today’s object-oriented (OO) software development concept reproduces a systemic rather than the conventionally known functional paradigm. As a result, such a dyadic approach at the outset of software development will contribute to truly effective and desired reactive, goal-oriented, and user-centered systems. Therefore, the PS needs to be revivied in software engineering.
