Software requirementsSoftware 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: A condition or capability needed by a user to solve a problem or achieve an objective. 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.
Conception de produitLa conception de produit est le processus permettant de matérialiser des concepts, de concrétiser des objets, des biens, des équipements, ou de créer des services, des techniques, voire des systèmes complexes, différents de ceux existants, et qui proposent des réponses en adéquation avec des besoins collectifs ou particuliers, afin d'apporter un bénéfice aux usagers.
Modeling and simulationModeling and simulation (M&S) is the use of models (e.g., physical, mathematical, behavioral, or logical representation of a system, entity, phenomenon, or process) as a basis for simulations to develop data utilized for managerial or technical decision making. In the computer application of modeling and simulation a computer is used to build a mathematical model which contains key parameters of the physical model. The mathematical model represents the physical model in virtual form, and conditions are applied that set up the experiment of interest.
Business analysisBusiness 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. Business analysts are not found solely within projects for developing software systems.
Spécification fonctionnelleLa spécification fonctionnelle est la description des fonctions d'un logiciel en vue de sa réalisation. La spécification fonctionnelle décrit dans le détail la façon dont les exigences seront prises en compte. Un exemple d'exigence est l'adaptation d'un progiciel à l'utilisateur en ce qui concerne la langue (le français dans les pays francophones). Une spécification fonctionnelle est indépendante de la façon dont sera réalisé le logiciel en question. Elle doit être exprimée en termes de fonctions et non pas en termes de solutions.
Produit minimum viableDans le cadre de la conception de produit, le produit minimum viable (ou MVP, de l'minimum viable product) est la version d'un produit qui permet d'obtenir un maximum de retours client avec un minimum d'effort. Par extension, il désigne aussi la stratégie utilisée pour fabriquer, tester et mettre sur le marché ce produit. L'intérêt du produit minimum viable est d'évaluer la viabilité d'un nouveau modèle d'entreprise. Des méthodologies comme le lean startup ou les méthodes agiles accordent une place importante au produit minimum viable.
Cas d'utilisationUn cas d'utilisation, bloc fonctionnel ou cas d'usage (« use-case » en anglais), définit en génie logiciel et en ingénierie des systèmes une manière d'utiliser un système qui a une valeur ou une utilité pour les acteurs impliqués. Le cas d'utilisation correspond à un ensemble d'actions réalisées par le système en interaction avec les acteurs en vue d'une finalité. L'ensemble des cas d'utilisation permet ainsi de décrire les exigences fonctionnelles d'un système en adoptant le point de vue et le langage de l'utilisateur final.
Non-functional requirementIn systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.
Business requirementsBusiness 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. Three main reasons for such discussions: A common practice is to refer to objectives, or expected benefits, as 'business requirements.
MaintenabilitéLa maintenabilité est, dans le domaine informatique, la capacité pour des composants ou des applications à être maintenus, de manière cohérente et à moindre coût, en état de fonctionnement. Plus généralement, dans l'industrie le terme exprime la capacité d'un système à être simplement et rapidement réparé et ainsi à diminuer les temps et les coûts d'intervention. La maintenabilité d'un système est souvent caractérisée lors de sa conception. Elle se calcule suivant les temps moyen d'intervention et suit une loi log-normale.
