FRET (software)

Last updated
FRET
Developer(s)
  • Andreas Katis
  • Anastasia Mavridou
  • Tom Pressburger
  • Johann Schumann
  • Khanh Trinh
[1]
Stable release
3.1 / December 15, 2023;4 months ago (2023-12-15) [2]
Written in JavaScript
Operating system Windows, Linux, OS X
Type Formalizing
License NASA Open Source Agreement version 1.3
Website https://github.com/NASA-SW-VnV/fret

Formal Requirements Elicitation Tool (FRET) is a requirements engineering tool. It was developed by the NASA Ames Research Center to specify complex safety-critical systems whose failure could result in loss of life, significant property damage, or environmental harm. [3] FRET is open-source software released under the NASA Open Source Agreement. [4]

Contents

Background

The behavior and features of a system are specified by its requirements. Most requirements are written in natural languages such as English, which is easy for analysts and stakeholders to understand but cannot be checked for errors and omissions using formal methods. On the other hand, formal notations such as VDM and Z, which are precise and unambiguous, tend to be difficult for analysts and stakeholders to understand. [4] [5]

As a compromise, FRET requirements are created in a controlled natural language called FRETish and converted into temporal logic. [4] [5]

Uses

FRETish requirements can correspond to variables in external code or models. FRET generates and verifies formal equivalents for each statement, allowing requirements to be imported or exported in a variety of formats including JSON. [4] [6]

In FRET, processes are simulated and analyzed by interfacing with external modeling and analysis tools. The supported external tools include COCO simulator, Simulink Design, Verifier, NuSMV, and Copilot. [4] [6]

See also

Related Research Articles

In computer science, static program analysis is the analysis of computer programs performed without executing them, in contrast with dynamic program analysis, which is performed on programs during their execution in the integrated environment.

A modeling language is any artificial language that can be used to express data, information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure of a programing language.

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

<span class="mw-page-title-main">Business analyst</span> Person who analyses and documents a business

A business analyst (BA) is a person who processes, interprets and documents business processes, products, services and software through analysis of data. The role of a business analyst is to ensure business efficiency increases through their knowledge of both IT and business function.

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome should conform.

Business analysis is a professional discipline focused on identifying business needs and determining solutions to business problems. Solutions may include a software-systems development component, process improvements, or organizational changes, and may involve extensive analysis, strategic planning and policy development. A person dedicated to carrying out these tasks within an organization is called a business analyst or BA.

In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a summary of behavior between inputs and outputs.

Software assurance (SwA) is a critical process in software development that ensures the reliability, safety, and security of software products. It involves a variety of activities, including requirements analysis, design reviews, code inspections, testing, and formal verification. One crucial component of software assurance is secure coding practices, which follow industry-accepted standards and best practices, such as those outlined by the Software Engineering Institute (SEI) in their CERT Secure Coding Standards (SCS).

Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another; (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy; (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.

<span class="mw-page-title-main">Misuse case</span>

Misuse case is a business process modeling tool used in the software development industry. The term Misuse Case or mis-use case is derived from and is the inverse of use case. The term was first used in the 1990s by Guttorm Sindre of the Norwegian University of Science and Technology, and Andreas L. Opdahl of the University of Bergen, Norway. It describes the process of executing a malicious act against a system, while use case can be used to describe any action taken by the system.

Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:

  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  3. A documented representation of a condition or capability as in 1 or 2

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

<span class="mw-page-title-main">Arcadia (engineering)</span>

ARCADIA is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities.

Infer, sometimes referred to as "Facebook Infer", is a static code analysis tool developed by an engineering team at Facebook along with open-source contributors. It provides support for Java, C, C++, and Objective-C, and is deployed at Facebook in the analysis of its Android and iOS apps.

Z3, also known as the Z3 Theorem Prover, is a satisfiability modulo theories (SMT) solver developed by Microsoft.

References

  1. "fret/CONTRIBUTORS.md at master · NASA-SW-VnV/fret". GitHub. Retrieved 26 November 2023.
  2. "FRET: Formal Requirements Elicitation Tool". GitHub. Retrieved 2023-12-29.
  3. Katis, Andreas; Mavridou, Anastasia; Giannakopoulou, Dimitra; Pressburger, Thomas; Schumann, Johann (2022). Capture, Analyze, Diagnose: Realizability Checking Of Requirements in FRET. Lecture Notes in Computer Science. Vol. 13372. Springer International Publishing. pp. 490–504. doi:10.1007/978-3-031-13188-2_24. ISBN   978-3-031-13187-5 . Retrieved 7 December 2023 via Springer.
  4. 1 2 3 4 5 Giannakopoulou, Dimitra; Pressburger, Thomas; Mavridou, Anastasia; Rhein, Julian; Schumann, Johann; Shi, Nija (2020). Formal Requirements Elicitation with FRET (PDF). REFSQ Workshops. S2CID   214708107. Archived (PDF) from the original on 2023-10-03. Retrieved 2023-11-29.
  5. 1 2 "Formal Requirements-Driven Verification". VALU3S Repository. VALU3S.
  6. 1 2 "fret/fret-electron/docs/_media/userManual.md at master · NASA-SW-VnV/fret". GitHub. Retrieved 2023-12-30.