FACTOID # 21: 15% of Army recruits from South Dakota are Native American, which is roughly the same percentage for female Army recruits in the state.
 
 Home   Encyclopedia   Statistics   States A-Z   Flags   Maps   FAQ   About 
   
 
WHAT'S NEW
RELATED ARTICLES
People who viewed "Requirement" also viewed:
 

SEARCH ALL

FACTS & STATISTICS    Advanced view

Search encyclopedia, statistics and forums:

 

 

(* = Graphable)

 

 


Encyclopedia > Requirement

In engineering, a is a singular documented need of what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineering or software engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user.[1] Image File history File links Emblem-important. ... Image File history File links Broom_icon. ... A need is the psychological feature that arouses an organism to action toward a goal and the reason for the action, giving purpose and direction to behavior. ... Engineering is the discipline of acquiring and applying knowledge of design, analysis, and/or construction of works for practical purposes. ... Systems engineering techniques are used in complex projects: from spacecrafts to chip design, from robotics to creating large software products to building bridges, Systems engineering uses a host of tools that include modeling & simulation, requirements analysis, and scheduling to manage complexity Systems Engineering (SE) is an interdisciplinary approach and means... Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. ...


In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development. In business and engineering, new product development (NPD) is the term used to describe the complete process of bringing a new product or service to market. ...


The requirements development phase may have been preceded by a feasibility study, or a conceptual analysis phase of the project. The requirements phase may be broken down into requirements elicitation (gathering the requirements from stakeholders), analysis (checking for consistency and completeness), definition (writing down descriptive requirements for developers), and specification (creating an initial bridge between requirements and design). A feasibility study is a preliminary study undertaken to determine and document a projects viability. ... A corporate stakeholder is a party who affects, or can be affected by, the companys actions. ...

Contents

Product versus process requirements

Projects are subject to three sorts of requirements. Business Requirements describe in business terms what must be delivered or accomplished to provide value. Product Requirements describe the system or product which is one of several possible ways to accomplish the business requirements. Process Requirements describe the processes the developing organization must follow and the constraints that they must obey.


The Product and Process requirements are closely linked. Process requirements are often imposed as a way of achieving some higher-level Product requirement. For example, a maximum development cost requirement (a Process requirement) may be imposed to help achieve a maximum sales price requirement (a Product requirement); a requirement for the product to be maintainable (a Product requirement) often is traced to by requirements to follow particular development styles (e.g., object-oriented programming), style-guides, or a review/inspection process (Process requirements). Both user along with system requirements are vital for every system to develop(Surafel) Object-oriented programming (OOP) is a programming paradigm that uses objects and their interactions to design applications and computer programs. ...


Requirements show what elements and function are necessary for the particular project.


Requirements in systems and software engineering

In systems engineering, a requirement can be a description of what a system must do, referred to as a Functional Requirement. This type of requirement specifies something that the delivered system must be able to do. Another type of requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called 'non-functional requirements', or 'performance requirements' or 'quality of service requirements.' Examples of such requirements include availability, testability, maintainability, and ease-of-use.


A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements generally avoids saying how the system should implement the requirements, leaving such decisions to the system designer. Describing how the system should be implemented is known as implementation bias.


In software engineering, the same meaning of requirements apply, except that the focus of interest is the software itself.


Some factors in developing requirements

Classification

Requirements are typically placed into these categories:

  1. Functional requirements describe the functions that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.
  2. Non-functional requirements requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.

They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability requirements, or one of many other types of requirements. Functional requirements define the internal workings of the software: that is, the calculations, technical details, data manipulation and processing and other specific functionality that show how the use cases are to be satisfied. ... In systems engineering and requirements engineering, non-functional requirements are requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. ...


Good requirements

The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to his general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged[2][3][4][5].

Characteristic Explanation
Cohesive The requirement addresses one and only one thing.
Complete The requirement is fully stated in one place with no missing information.
Consistent The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
Correct The requirement meets all or part of a business need as authoritatively stated by stakeholders.
Current The requirement has not been made obsolete by the passage of time.
Externally Observable The requirement specifies a characteristic of the product that is externally observable or experienced by the user. "Requirements" that specify internal architecture, design, implementation, or testing decisions are properly constraints, and should be clearly articulated in the Constraints section of the Requirements document.
Feasible The requirement can be implemented within the constraints of the project.
Unambiguous The requirement is concisely stated without recourse to techincal jargon, acronyms (unless defined elsewhere in the Requirements docuement), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided.
Mandatory The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated.
Verifiable The implementation of the requirement can be determined through one of four possible methods: inspection, analysis, demonstration, or test.

Testability

Most requirements should be testable. If this is not the case, another verification method should be used instead (e.g. analysis, inspection or review of design). Testable requirements are an important component of validation. The word validation has several uses: In general, validation is the process of checking if something satisfies a certain criterion. ...


Certain requirements, by their very structure, are not testable. These include requirements that say the system shall never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements are often rewritten to state a more practical time period.


Un-testable non-functional requirements may still be kept as a documentation of customer intent; however they are usually traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming. Avionics software with its complicated safety requirements must follow the DO-178B development process. A backdoor in a computer system (or cryptosystem or algorithm) is a method of bypassing normal authentication or securing remote access to a computer, while attempting to remain hidden from casual inspection. ... Pair programming requires two software engineers to participate in a combined development effort at one workstation. ... Avionics software is embedded software with legally-mandated safety and reliability concerns used in avionics. ... DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a standard for software development published by RTCA, Incorporated. ...


Testability is essentially a form of clarity, which indeed is necessary but can divert attention from other important issues. A requirement can be testable yet incorrect; and assessing testability often will not detect incorrect requirements. Moreover, testability is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized. There are more than 21 more powerful ways to test or evaluate requirements adequacy and more than 15 ways to strengthen testing or evaluation of design adequacy[citation needed].


Requirements analysis

Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous inspection have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues. Inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process. ... In sytems and software engineering, requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users. ...


There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they

  1. take a long time to produce
  2. begin to limit the implementation options available
  3. are costly to produce

Writing Requirements

Requirements are written in such a way that they direct the creation/modification of a system according to the business rules appropriate to the domain in which the system will be used. Systems should normally conform to the business domain of operation. The general form of a requirement looks like.. "who shall what". Example: "The contractor shall deliver the product no later than xyz date." Business rules describe the operations, definitions and constraints that apply to an organization in achieving its goals. ...


Changes in requirements

With time, requirements may change.


In this case, once defined and approved, requirements should fall under change control. For many projects, some requirements are altered before the system is complete. This characteristic of requirements has led to requirements management studies and practices. This does not cite any references or sources. ... This article does not cite its references or sources. ...


Disputes regarding the necessity of rigour in software requirements

Some modern software engineering methodologies like extreme programming question the need for rigorously describing software requirements, which they consider a moving target. Instead, they describe requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and compose a series of acceptance test cases for this user story. Extreme Programming (or XP) is a software engineering methodology, the most prominent of several agile software development methodologies, prescribing a set of daily stakeholder practices that embody and encourage particular XP values (below). ... A user story is a software system requirement formulated as one or two sentences in the everyday language of the user. ...


See also

In sytems and software engineering, requirements analysis encompasses those tasks that go into determining the requirements of a new or altered system, taking account of the possibly conflicting requirements of the various stakeholders, such as users. ... A use case is a technique used in software and systems engineering to capture the functional requirements of a system. ... This article does not cite its references or sources. ... acronym FURPS is a mnemonic for several kinds of software requirements: Functionality Usability Reliability Performance Supportability A common variation on this mnemonic is FURPSS. This adds Security as another key non-functional requirement category. ...

References

  1. ^ Young, Ralph R. Effective Requirements Practices. Boston: Addison-Wesley, 2001. See also RalphYoung.net, a website devoted to requirements-related topics.
  2. ^ Boehm, B.W. and Papaccio, P.N., 1988, Understanding and controlling software costs, IEEE Trans of Software Engineering, 14(10), 1462-1477
  3. ^ Bridges, W., 1995, Managing Transitions, Making the most of change, Nicholas Brealey Publishing, UK.
  4. ^ Brinkkemper, S., 1996, Method engineering: engineering of information systems development methods and tools, Inf. Software Technol., 38(4), 275-280.
  5. ^ Davis, A.M., 1993, Software Requirements: Analysis and Specification, Prentice Hall, second Edition, 1993.

External links

Look up Requirement in
Wiktionary, the free dictionary.
  • Requirements Engineering: A Roadmap (PDF)
  • Discovering System Requirements

  Results from FactBites:
 
Requirement (Conquistadors) - Wikipedia, the free encyclopedia (343 words)
The Requirement was originally intended as a response to complaints by Spanish clerics that the wars against the Native American peoples were unjust.
The Requirement was intended as a legal loophole to place the native population in the position of having rejected Christianity.
Many critics of the conquistadors' policies were appalled by the flippant nature of the Requirement, and Bartolomeo de Las Casas said in response to it that he did not know whether to laugh or to cry.
requirement: Definition, Synonyms and Much More from Answers.com (1261 words)
The requirements phase may be broken down into requirements elicitation (gathering the requirements from stakeholders), analysis (checking for consistency and completeness), definition (writing down descriptive requirements for developers), and specification (creating an initial bridge between requirements and design).
For example, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming.
Requirements are written in such a way that they direct the creation/modification of a system according to the business rules appropriate to the domain in which the system will be used.
  More results at FactBites »

 
 

COMMENTARY     


Share your thoughts, questions and commentary here
Your name
Your comments

Want to know more?
Search encyclopedia, statistics and forums:

 


Press Releases |  Feeds | Contact
The Wikipedia article included on this page is licensed under the GFDL.
Images may be subject to relevant owners' copyright.
All other elements are (c) copyright NationMaster.com 2003-5. All Rights Reserved.
Usage implies agreement with terms, 1022, m