Software requirements

list of actions or event steps typically defining the interactions between a user role and a system to achieve a goal

UML use case diagram

system design process focusing on analysing, documenting, validating and managing system requirements

functional and non-functional requirements that a designed software needs to fulfil, may include a set of use cases

environment needed to run software

In engineering, a requirement is a condition that must be satisfied for the output of a work effort to be acceptable. It is an explicit, objective, clear and often quantitative description of a condition to be satisfied by a material, design, product, or service.

requirement that defines the behavior (output) of a system or component based on inputs

informal, natural language description of one or more features of a software system, often written from the perspective of either an end user or system user

criteria that can be used to judge the operation characteristics of a system, rather than specific behaviors

subdiscipline of software engineering concerned with eliciting, specifying, validating, and managing the requirements of a system; increasingly focused on intent capture and meaning preservation in AI-mediated development

description of what the system should do, the service or services that it provides and the constraints on its operation

process of documenting, analyzing, tracing, prioritizing and agreeing on

FURPS (Functionality, usability, reliability, performance, supportability) is a model for classifying software quality attributes (functional and non-functional requirements):

conceptual model of the domain in software engineering that incorporates both behaviour and data

comparison of actual performance with potential or desired performance, in order to optimize organization and business processes, or product characteristics

document containing all the requirements for a certain product, typically used for software projects

profession in IT

excessive ongoing expansion or addition of new precluded features in a product, especially in computer software, video games and consumer and business electronics

process of collection of business requirements to develop a new information system

a sub-discipline of requirements management within software development and systems engineering

DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the primary document by which the certification authorities such as FAA, EASA and Transport Canada approve all commercial software-based aerospace systems. The document is published by RTCA, Incorporated, in a joint effort with EUROCAE and replaces DO-178B. The new document is called DO-178C/ED-12C and was completed in November 2011 and approved by the RTCA in December 2011. It became available for sale and use in January 2012.

practice of collecting the requirements of a system from users, customers and other stakeholders

document comparing detailed requirements of the product to the matching parts of high-level design, detailed design, test plan, and test cases

IBM Engineering Requirements Management DOORS (Dynamic Object Oriented Requirements System) (formerly Telelogic DOORS, then Rational DOORS) is a requirements management tool. It is a client–server application, with a Windows-only client and servers for Linux, Windows, and Solaris. There is also a web client, DOORS Web Access.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RTCA SC-167 of the Radio Technical Commission for Aeronautics (RTCA) and WG-12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was

MoReq2 is short for “Model Requirements for the Management of Electronic Records”, second version. It consists of a formal requirements specification for a generic electronic records management system, accompanied by testing documentation and related information. Published in 2008 by the European Commission, it is intended for use across the European Union, but can be used elsewhere. MoReq2 is generally considered a de facto standard in Europe but it does not have any formal status as a standard.