System testing: implications of requirements specifications

Davis, AM

doi:10.1016/0950-5849(90)90127-d

Cited by 6 publications

(2 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…У идеалном случају, захтеви су независни од дизајна и представљају шта се од система очекује да треба да ради, а не како да ради. Ипак, ово није увек могуће у пракси, посебно ако се узме у обзир да значење речи шта и како може да зависи и од особе која интерпретира [63]. Ово управо води ка робусној подели и дефиницији корисничких и техничких захтева.…”

Section: агрегација вредности нефункционалних карактеристика сервисаunclassified

“…customer requirements, user requirements, IT requirements, system requirements, and security requirements Прва нит [64] се фокусира на функцију: функционални захтев дефинише функцију коју систем мора бити у могућности да обезбеди [62], шта производ мора да ради [65] и шта би систем требао да ради [66]. Друга нит се фокусира на понашање: функционални захтеви описују аспекте понашања система [67], акције које систем мора бити у могућности да изврши без обзира на физичке захтеве и 48 условљености, као и захтев који дефинише улазно/излазно понашање система [63][68].…”

Section: Business Requirements Versus Technical Requirementsunclassified

See 1 more Smart Citation

Configuration of service oriented architectures with semantic technologies based on non-functional requirements

Ognjanović¹

View full text Add to dashboard Cite

Section: агрегација вредности нефункционалних карактеристика сервисаunclassified

Section: Business Requirements Versus Technical Requirementsunclassified

Configuration of service oriented architectures with semantic technologies based on non-functional requirements

Ognjanović¹

View full text Add to dashboard Cite

Requirements for Development of Software Requirements

Mar

1994

INCOSE International Symp

View full text Add to dashboard Cite

This paper (1) describes what the current literature identifies as qualities of good software requirements, (2) identifies and examines different categories of software requirement methods, and (3) concludes that methods used to develop software requirements, though not perfect, have advantages that can improve the development of requirements for any type of system. Twelve requirement qualities were identified from the literature and these were used to establish evaluation criteria for software requirement development methods. Three methods selected for evaluation were the Hatley‐Pirbhai method (1988), the CoRE (Consortium Requirements Engineering, SPC, 1992), and Requirements State Machine Language (RSML) develop by Leveson (1990). None of these method stands out as being superior and each have strengths and weaknesses depending upon the application, but each offers improvements over the text based methods used in traditional systems engineering efforts to create function/requirement sets.

show abstract

Requirements Engineering: Setting the Context

Aurum¹,

Wohlin²

Engineering and Managing Software Requirements

View full text Add to dashboard Cite

System testing: implications of requirements specifications

Cited by 6 publications

References 19 publications

Configuration of service oriented architectures with semantic technologies based on non-functional requirements

Configuration of service oriented architectures with semantic technologies based on non-functional requirements

Requirements for Development of Software Requirements

Requirements Engineering: Setting the Context

Contact Info

Product

Resources

About