Premium
3 Panel: How Do Requirements Relate to Objects?
Author(s) -
Kaindl Hermann,
Glinz Martin,
Kasser Joseph E.,
Kasser Joseph E.
Publication year - 2004
Publication title -
incose international symposium
Language(s) - English
Resource type - Journals
ISSN - 2334-5837
DOI - 10.1002/j.2334-5837.2004.tb00540.x
Subject(s) - requirements management , non functional requirement , computer science , requirements engineering , systems engineering , non functional testing , schedule , software engineering , requirements elicitation , system requirements , requirement , requirements analysis , process (computing) , business requirements , system requirements specification , functional requirement , object (grammar) , software system , software , engineering , business process , work in process , artificial intelligence , operations management , software construction , programming language , operating system
This position paper discusses arguments in favor and against regarding requirements as objects. As there are good arguments for both standpoints, a partial synthesis is developed. The synthesis is based on the idea of not treating requirements as objects, but using objects for organizing and understanding requirements. Object‐oriented systems engineering contains a broad chasm. On one side is object‐oriented systems engineering and on the other are the systems and sub‐systems that are objects by definition. The chasm is the domain of requirements. Whiles conventional systems and software requirements engineering have ignored the chasm, Total Quality Management (TQM) can be used to bridge the chasm and reduce cost and schedule overruns. This approach is based on a starting assumption that since requirements drive the work of implementing the system, object‐oriented requirements have both the traditional properties describing the product but also have properties than can assist in ensuring a cost‐effective production process. Several candidate properties that have been identified and their usefulness are discussed. Some concept demonstration tools that have been developed are summarised, and the presentation concludes by pointing out that the object‐oriented properties can be used to provide views of a proposed system at the System Requirements Review that would be difficult to observe in the current paradigm.