Functional documents for computer systems

Parnas, David Lorge; Madey, Jan

doi:10.1016/0167-6423(95)96871-j

Cited by 338 publications

(200 citation statements)

References 16 publications

Supporting

Mentioning

190

Contrasting

Unclassified

Order By: Relevance

“…Although these recent results helped further understanding of the general concept of quality requirements and opened new paths for future research, other issues need further advance as well, such as the integration of NFRs into other requirements models, such as the reference model [29] and the four variable model [61] which have had significant influences in the area of requirements engineering. Although these models address performance or accuracy concerns, they are essentially functional models and without the notion of goals.…”

Section: Future Directionsmentioning

confidence: 99%

On Non-Functional Requirements in Software Engineering

Chung

Leite

2009

Lecture Notes in Computer Science

957

578

View full text Add to dashboard Cite

Abstract. Essentially a software system's utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.

show abstract

Section: Future Directionsmentioning

confidence: 99%

On Non-Functional Requirements in Software Engineering

Chung

Leite

2009

Lecture Notes in Computer Science

957

578

View full text Add to dashboard Cite

show abstract

“…If the composition of the system with its environment is intended to achieve emergent properties E, then the requirements engineer should look for assumptions A about the environment and properties S of the system such that A and S jointly entail E. This approach puts NYAM in the same class of requirements methods as KAOS [15,16], the requirements reference approach of the Gunters, Jackson and Zave [17,18] and, to some extent, SCR [19][20][21]. We call the argument that the environment and the system jointly assure the emergent properties the systems engineering argument.…”

Section: Not Yet Another Methods (Nyam)mentioning

confidence: 99%

Requirements-Level Semantics and Model Checking of Object-Oriented Statecharts

Eshuis

Jansen

Wieringa

2002

Requirements Engineering

View full text Add to dashboard Cite

In this paper we define a requirements-level execution semantics for object-oriented statecharts and show how properties of a system specified by these statecharts can be model checked using tool support for model checkers. Our execution semantics is requirements-level because it uses the perfect technology assumption, which abstracts from limitations imposed by an implementation. Statecharts describe object life cycles. Our semantics includes synchronous and asynchronous communication between objects and creation and deletion of objects. Our tool support presents a graphical front-end to model checkers, making these tools usable to people who are not specialists in model checking. The model-checking approach presented in this paper is embedded in an informal but precise method for software requirements and design. We discuss some of our experiences with model checking.

show abstract

“…There also exist tool support [20,65] for Goal-Oriented Requirements Engineering (GORE), see, e.g., I* [80] or Knowledge Acquisition in Automated Specification (KAOS) [46] or [34,47] for literature reviews, where [46,80] draw on ideas presented in [39,40,58]. While such tool support is indeed similar to the support proposed in the present paper, one main difference lies in the flexibility of how requirements can be hierarchically structured.…”

Section: Related Workmentioning

confidence: 99%

Providing tool support for specifying safety-critical systems by enforcing syntactic contract conditions

Westman

Nyberg

2017

Requirements Eng

View full text Add to dashboard Cite

Functional safety standards such as IEC 61508 and ISO 26262 advocate a particularly stringent requirements engineering where safety requirements must be structured in a hierarchical manner and specified in accordance with the system architecture. In contrast to the stringent requirements engineering in functional safety standards, according to previous studies, requirements engineering in industry is in general of poor quality. Contracts theory has been previously shown to be suitable for supporting such a stringent requirements engineering effort; this support has also been implemented in tools. However, to use these contract-based tools, requirements must be formalized, which is a major challenge in industry. Therefore, to support current industrial requirements engineering practice and the stringent requirements engineering in functional safety standards, it is shown how tool support can be provided even when requirements, and also architectures, are not formalized. This is achieved by enforcing syntactic, yet formal, conditions in contracts theory. Despite the need for further validation, initial findings in an industrial case study indicate high potential in realizing the proposed support in an industrial setting.

show abstract

Functional documents for computer systems

Cited by 338 publications

References 16 publications

On Non-Functional Requirements in Software Engineering

On Non-Functional Requirements in Software Engineering

Requirements-Level Semantics and Model Checking of Object-Oriented Statecharts

Providing tool support for specifying safety-critical systems by enforcing syntactic contract conditions

Contact Info

Product

Resources

About