Glossary

From EITBOK
Revision as of 00:39, 29 August 2015 by Invicta (Talk | contribs)

Jump to: navigation, search
TermMeaning
acceptablemeeting stakeholder expectations that can be shown to be reasonable or merited (Source: ISO/IEC Std. 38500:2008, Corporate governance of information technology, ISO/IEC, 2008)
acceptance criteria(1) the criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity (Source: ISO/IEC/IEEE Std. 24765:2010, Systems and software engineering — Vocabulary, ISO/IEC/IEEE, 2010)
(2) those criteria, including performance requirements and essential conditions, which must be met before project deliverables are accepted (Source: A Guide to the Project Management Body of Knowledge [PMBOK[R] Guide] — Fourth Edition)
acquisition(1) The process of obtaining a system, product, or service and ensuring its successful implementation. Acquisition also includes ensuring that proper mechanisms are in place to monitor the supplier’s/vendors’ performance in providing support and fulfilling other contractual obligations. Original to ITBOK.
(2) The process of obtaining a system or software product (Source: IEEE Std. 1062-1998, IEEE Recommended Practice for Software Acquisition, IEEE, 1998)
(3) the process of obtaining a system, software product or software service (Source: ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes, 4.2)
(4) the process of obtaining a system product or service (Source: ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes, 4.2)
acquisition strategyspecific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, contract or agreement types, and related acquisition risks (Source: ISO/IEC 24765:2009, Systems and software engineering vocabulary)
AOAanalysis of alternatives
BCAbusiness case analysis
CBAcost benefit analysis
CMMICapability Maturity Model Integration
COBITControl Objectives for Information and Related Technology
conceptual designdescribes the proposed solution in a functional manner that could be easily understood by a future user, including what the solution will look like and how it will behave
constraint(1) an externally imposed limitation on system requirements, design, or implementation or on the process used to develop or modify a system (IEEE Std. 29148-2011, Systems and software engineering — Life cycle processes — Requirements engineering, IEEE, 2011)
(2) a statement that expresses measurable bounds for an element or function of the system (IEEE Std. 29148-2011, Systems and software engineering — Life cycle processes — Requirements engineering, IEEE, 2011)
contractbinding agreement between two parties, especially enforceable by law, or a similar internal agreement wholly within an organization (Source: ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes, ISO/IEC, 2008)
CSPcost schedule performance
DoDAFDepartment of Defense Architecture Framework, an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views
domainA specific sphere of activity or knowledge. A domain can correspond to the boundaries of an organization, a job function, or even a particular task.
domain elicitationcollecting the right information from SMEs, stakeholders, or consumers about how the solution should function
GSCglobal standards collaboration
HITSRHealthcare Information Technology Standards Panel
ICTinformation and communications technology
IEEEInstitute of Electrical and Electronics Engineers
INCITSInternational Committee for Information Technology Standards
ISOInternational Organization for Standardization
ITILIT infrastructure library
ITSCinformation technology support center
LCCElife cycle cost estimate
logical designdefines objects, entities, their attributes, and their relationships. It also describes the business rules associated with these entities
MOEmeasures of effectiveness
NISTNational Institute of Standards and Technology
physical designAlso called the technical design. Where the conceptual and logic designs are converted to a definition of how the solution will be implemented in hardware, software, and potentially other media. The physical design is developed by the construction team not by the requirements team.
resource managementthe identification, estimation, allocation, and monitoring of the means used to develop a product or perform a service (Source: ISO/IEC/IEEE Std. 24765:2010, Systems and software engineering — Vocabulary, ISO/IEC/IEEE, 2010)
RFI request for information
RFP request for proposal
RFQrequest for quotation
RFTrequest for tender
riska function of the probability of occurrence of a given threat and the potential adverse consequences of that threat’s occurrence (Source: ISO/IEC Std. 15026-3:2011, Systems and software engineering — Systems and software assurance — Part 3: System integrity levels, ISO/IEC, 2011)
SaaSSoftware as a Service
SFIASkills Framework for the Information Age
SMEsubject matter expert
solutiona set of changes to the current state of an enterprise that will enable the enterprise to meet a need, solve a problem, or take advantage of an opportunity
SWOTstrengths, weaknesses, opportunities. and threats involved in a project or in a business venture (Source: A Guide to the Project Management Body of Knowledge [PMBOK[R] Guide], Fourth Edition)
TOGAFThe Open Group Architecture Framework