Inproceedings647: Unterschied zwischen den Versionen
K (Added from ontology) |
K (Added from ontology) |
||
| Zeile 17: | Zeile 17: | ||
|Abstract=We argue that non-functional requirements are the driving force behind the design decisions in the MIKE approach to the development of knowledge-based systems. We outline the model adopted in MIKE to record the rationale of design decisions by explicitly linking them to non-functional requirements and indicate how the evaluation of the design wrt. the posed requirements can be integrated into the development process. | |Abstract=We argue that non-functional requirements are the driving force behind the design decisions in the MIKE approach to the development of knowledge-based systems. We outline the model adopted in MIKE to record the rationale of design decisions by explicitly linking them to non-functional requirements and indicate how the evaluation of the design wrt. the posed requirements can be integrated into the development process. | ||
|VG Wort-Seiten= | |VG Wort-Seiten= | ||
| − | |Download= | + | |Download=1994_647_Landes_Addressing_Non-_1.ps.gz |
|Projekt= | |Projekt= | ||
|Forschungsgruppe= | |Forschungsgruppe= | ||
}} | }} | ||
Version vom 15. August 2009, 18:52 Uhr
Addressing Non-Functional Requirements in the Development of Knowledge-Based Systems
Addressing Non-Functional Requirements in the Development of Knowledge-Based Systems
Published: 1994
Herausgeber: K. Pohl, G. Starke und P. Peters
Buchtitel: Proceedings of the 1st International Workshop on Requirements Engineering: Foundation of Software Quality REFSQ'94 (Utrecht, Netherlands, June 6-7)
Ausgabe: 6
Reihe: Aachener Beiträge zur Informatik
Seiten: 64-70
Verlag: Verlag der Augustinus Buchhandlung, Aachen
Referierte Veröffentlichung
BibTeX
Kurzfassung
We argue that non-functional requirements are the driving force behind the design decisions in the MIKE approach to the development of knowledge-based systems. We outline the model adopted in MIKE to record the rationale of design decisions by explicitly linking them to non-functional requirements and indicate how the evaluation of the design wrt. the posed requirements can be integrated into the development process.
Download: Media:1994_647_Landes_Addressing_Non-_1.ps.gz