A-C | D-L | M-Q | R | S | T-Z

reader -- In an inspection (not a walkthrough), the individual that leads the inspection team through the software product in a comprehensive and logical fashion, interpreting sections of the work (for example, generally paraphrasing groups of 1–3 lines), and highlighting important aspects.  [IEEE Std 1028-1997] 

recorder -- In an inspection (not a walkthrough), the individual that documents anomalies, action items, decisions, recommendations made by the inspection team, and record inspection data required for process analysis.  The moderator can also be the recorder.  [IEEE Std 1028-1997]

re-engineering — Pulling the software apart and reassembling it in a more robust way to do the same application

regression test -- Retesting to detect faults introduced by modification.  [IEEE Stds Glossary]

regression testing -- The name given to functional testing that follows modification and maintenance.  Regression testing is undertaken to determine whether the modification has altered the software functions that were to remain unchanged.

relationship -- A semantic connection between model elements.  Examples include associations, dependencies, and generalizations.  Relationships to use cases include.  [geri@wyyzzk.com]

release -- The formal notification and distribution of an approved version of a hardware/software system.  [IEEE Std 828-1998]

repository -- (A) A collection of all software-related artifacts (e.g., the software engineering environment) belonging to a system, or (B) The location/format in which such a collection is stored.  [IEEE Stds Glossary]

required inputs -- The set of items necessary to perform the minimum V&V tasks mandated within any life cycle activity.  [IEEE Stds Glossary]

required outputs -- The set of items produced because of performing the minimum V&V tasks mandated within any life cycle activity.  [IEEE Stds Glossary]

requirements allocation -- The assignment or budgeting of top-level functional or nonfunctional requirements among the lower-level partitioned functions for accomplishment.  In this manner, the elements of a system that perform all, or part of, specific requirements are identified.  

requirements derivation -- (1).  In a hierarchical structure, the next lower level that is associated with a given element.  The lower element is said to be derived from the higher element.  (2). In system engineering, the changing or translation of a requirement through analysis into a form that is suitable for low-level analysis or design.  

requirements engineering -- The science and discipline concerned with analyzing and documenting requirements.  It comprises needs analysis, requirements analysis, and requirements specifications.

requirements flow down -- The systematic decomposition of system requirements into allocated and derived requirements, appropriately assigned to low-level functional components.  

requirements partitioning -- The separation or decomposing of a top-level requirement or design into successively low-level detailed requirements or design.  Synonymous with decomposition. 

requirements review -- See software specification review (SSR), system requirements review (SRR). 

requirements specification --  In system/software engineering, a document that states the functions that software must perform, required level of performance (speed, accuracy, etc.), the nature of the required interfaces between the software product and its environment, the type and severity of constraints on design, and the quality of the final product.  Synonymous with external specification.  See also software requirements specification.

requirements traceability — The identification and documentation of the derivation path (upward) and allocation/flow down path (downward) of requirements in the requirements hierarchy.  See also traceability

requirements traceability tool -- A software development tool that establishes traceability between itemized software requirements specifications, design elements, code elements, and test cases.  It also supports various associated query, analysis, and report generation capabilities.

responsibility -- An obligation to perform assigned and implied duties to the best of the individual's ability

return on investment -- As a general concept, it refers to getting more value out of a financial venture than was put in.  Unfortunately, sometimes it refers to internal rate of return, sometimes to a benefit-cost ratio, and sometimes to other formulas that are not generally recognized.  [steve.tockey@construx.com]

reuse — Building a software system from pieces to be used to perform a new application

reverse engineering -- A software engineering approach that derives a system’s design or requirements from its code.  The design might be represented by a program design language (PDL) or a formal language.  By creating a logical view from a physical system, reverse engineering helps maintain and enhance existing systems.

review -- A review is a process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.  Types include joint acquirer-supplier reviews (sometime called milestone reviews), management reviews, technical reviews, peer reviews (includes inspections and walkthroughs), and audits.  [IEEE Std 1028-1997]   

RFP -- Acronyms for request for proposal (-tender).  [IEEE Stds Glossary]

risk --(1) The likelihood of an event, hazard, threat, or situation occurring along with its undesirable consequences; (2) A potential problem; (3) The probability of incurring a loss or enduring a negative impact.  [d.fairley@computer.org]

risk acceptance -- Acknowledgment of a risk factor’s existence along with a decision to accept the consequences if the corresponding problem occurs.  Also called risk assumption.[d.fairley@computer.org]

risk analysis -- The process of examining identified risk factors for probability of occurrence, potential loss, and potential risk-handling strategies.[d.fairley@computer.org]

risk analysis -- The systematic use of available information to identify hazards and to estimate the risk to individuals or populations, property or the environment.  [IEEE Stds Glossary]

risk avoidance -- A course of action that removes a risk factor from further consideration (for example, by changing the requirements, extending the schedule, or transferring the risk factor to another domain).  [d.fairley@computer.org]

risk exposure -- The product of probability times potential loss for a risk factor; usually expressed in monetary units or utility.[d.fairley@computer.org]

risk factor -- A potential problem that would be detrimental to a planned activity, project, or program, characterized by the probability of problem occurrence (0 _ p _ 1) and a potential loss (of life, money, property, reputation, and so on) should the problem occur.  Both probability and potential loss might change over time.  [d.fairley@computer.org]

risk handling -- A course of action taken in response to a risk factor; includes risk acceptance, risk avoidance, risk transfer, and risk mitigation.  [d.fairley@computer.org]

risk identification -- An organized, systematic approach to determining the risk factors associated with a planned activity, project, or program.[d.fairley@computer.org]

risk leverage factor (rlf) – A relationship: rlf = (reb - rea)/rmc, where reb is risk exposure before risk mitigation, rea is risk exposure after risk mitigation, and rmc is the risk mitigation activity’s cost.  Larger rlfs indicate better mitigation strategies.[d.fairley@computer.org]

risk management -- An organized process for identifying and handling risk factors; includes initial identification and handling of risk factors as well as continuous risk management.  [d.fairley@computer.org]

risk metric -- An objective measure associated with a risk factor to be mitigated.[d.fairley@computer.org]

risk mitigation -- A course of action taken to reduce the probability of and/or potential loss from a risk factor; includes executing contingency plans when a risk metric crosses a predetermined threshold (when a risk factor becomes a problem).  [d.fairley@computer.org]

risk reduction -- Reducing the probability and/or potential impact of a risk factor.  Risk reduction might involve research, prototyping, and other means of exploration.  [d.fairley@computer.org]

risk transfer -- Transferring responsibility for managing a risk factor to another organization or functional entity better able to mitigate the risk factor.  [d.fairley@computer.org]

risk trigger -- The predetermined threshold value of a risk metric that triggers invocation of a contingency plan when the risk metric crosses the threshold.  [d.fairley@computer.org]

rolling wave --A "just-in-time" method for analyzing the work to be done.  For example, first, plan at the staff-week level for the next month, second, plan at the one month level for the following three quarters (9 months), and finally, plan to the quarter year (3 months) for the remainder of the project.  Each month the "planning wave" is rolled forward.  [Fairley 1993].  A project plan that provides more detail for the immediate future and less detail for the more distance future.

root-cause analysis -- Determination of a potential problem’s (a risk factor’s) underlying cause or causes.  [d.fairley@computer.org]