text:
Stakeholder Requirements Definition
System requirements are all of the requirements at the system level that describe the functions which the system as a whole should fulfill to satisfy the stakeholder needs and requirements, and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary.
System requirements play major roles in systems engineering, as they:
- Form the basis of system architecture and design activities.
- Form the basis of system integration and verification activities.
- Act as reference for validation and stakeholder acceptance.
- Provide a means of communication between the various technical staff that interact throughout the project.
Elicitation of stakeholder requirements starts in Concept Definition, and will be initially developed though interview and mission analysis. System requirements are considered in detail during System Definition. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.
Definition and Purpose of Requirements
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO 2007).
To avoid confusion in the multitude of terms pertaining to requirements, consider the following classifications:
- Process Role or State: The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled).
- Level of Abstraction: The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.
- Type of Requirement: The nature of the requirement itself; for instance, functional, performance, constraint, etc.
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to (Martin 1997, Chapter 2).
Principles Governing System Requirements
Relationship to Stakeholder Requirements and Logical Architecture
A set of stakeholder requirements are clarified and translated from statements of need into engineering-oriented language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis.
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment of candidate solutions and verification of the completed system. The system requirements are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for system realization.
The logical architecture defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see Synthesizing Possible Solutions). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems life cycle model.
Traceability and the Assignment of System Requirements during Architecture and Design
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see Applying Life Cycle Processes). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.
During architecture definition and design, the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.
Assignment Type for a System Requirement | Description |
Direct Assignment | The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product). |
Indirect Assignment (Simply Decomposed) | The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained. |
Indirect Assignment (Modeled and Decomposed) | The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed. |
Derived Requirement (from Design) | Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint. |
Classification of System Requirements
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).
Types of System Requirement | Description |
Functional Requirements | Describe qualitatively the system functions or tasks to be performed in operation. |
Performance Requirements | Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task. |
Usability Requirements | Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria). |
Interface Requirements | Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges. |
Operational Requirements | Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security. |
Modes and/or States Requirements | Define the various operational modes of the system in use and events conducting to transitions of modes. |
Adaptability Requirements | Define potential extension, growth, or scalability during the life of the system. |
Physical Constraints | Define constraints on weight, volume, and dimension applicable to the system elements that compose the system. |
Design Constraints | Define the limits on the options that are available to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository). |
Environmental Conditions | Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.). |
Logistical Requirements | Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation. |
Policies and Regulations | Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.). |
Cost and Schedule Constraints | Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc. |
Requirements Management
Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes providing an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule.
There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to configuration management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.
Process Approach
Purpose and Principle of the Approach
The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier's perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements (ISO 2015).
Activities of the Process
Major activities and tasks during this process include:
- Analyzing the stakeholder requirements to check completeness of expected services and operational scenarios, conditions, operational modes, and constraints.
- Defining the system requirements and their rationale.
- Classifying the system requirements using suggested classifications (see examples above).
- Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.
- Establishing the upward traceability with the stakeholder needs and requirements.
- Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy.
- Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.
- Validating the content and relevance of each system requirement against the set of stakeholder requirements.
- Identifying potential risks (or threats and hazards) that could be generated by the system requirements.
- Synthesizing, recording, and managing the system requirements and potential associated risks.
- Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.
Checking Correctness of System Requirements
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).
Methods and Modeling Techniques
Requirements Elicitation and Prototyping
Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.
QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included to ensure that all aspects of user needs are accounted for and prioritized.
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.
Capturing Requirements Rationale
One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database (Hull, Jackson, and Dick 2010).
Some of the benefits of this approach include:
- Reducing the total number of requirements - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.
- Early exposure of bad assumptions
- Removes design implementation - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation.
- Improves communication with the stakeholder community - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).
Modeling Techniques
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:
- State-charts models (ISO 2011, Section 8.4)
- Scenarios modeling (ISO 2011, Section 22.214.171.124)
- Simulations, prototyping (ISO 2011, Section 126.96.36.199)
- Quality Function Deployment (INCOSE 2011, p. 83)
- Systems Modeling Language (SysML) sequence diagrams, activity diagrams, use cases, state machine diagrams, requirements diagrams (OMG 2010)
- Functional Flow Block Diagram for operational scenarios (Oliver, Kelliher, and Keegan 1997)
Presentation and Quality of Requirements
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to (INCOSE 2011, Section 18.104.22.168) and (ISO 2011).
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from (ISO 2011, Sections 5.2.5 and 5.2.6).
Characteristic | Description |
Necessary | The requirement defines an essential capability, characteristic, constraint, and/or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements |
Appropriate | The specific intent and amount of detail of the requirement is appropriate to the level of the entity to which it refers (level of abstraction). This includes avoiding unnecessary constraints on the architecture or design to help ensure implementation independence to the extent possible |
Unambiguous | The requirement is stated in such a way so that it can be interpreted in only one way. |
Complete | The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement |
Singular | The requirement should state a single capability, characteristic, constraint, or quality factor. |
Feasible | The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk |
Verifiable | The requirement is structured and worded such that its realization can be proven (verified) to the customer's satisfaction at the level the requirements exists. |
Correct | The requirement must be an accurate representation of the entity need from which it was transformed. |
Conforming | The individual requirements should conform to an approved standard template and style for writing requirements, when applicable. |
Note: Traceability is considered by some sources as a characteristic (ISO 2011). However, a recent viewpoint is that Traceability is actually an attribute of a requirement; that is, something that is appended to the requirement, not an intrinsic characteristic of a requirement (INCOSE 2011). The traceability characteristic or attribute is defined as: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.
Characteristic | Description |
Complete | The requirement set stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints, and/or quality factors to meet the entity needs without needing other information. In addition, the set does not contain any to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. |
Consistent | The set of requirements contains individual requirements that are unique, do not conflict with or overlap with other requirements in the set, and the units and measurement systems they use are homogeneous. The language used within the set of requirements is consistent, i.e., the same word is used throughout the set to mean the same thing. |
Feasible | The requirement set can be realized within entity constraints (e.g., cost, schedule, technical, legal, regulatory) with acceptable risk. (Note: Feasible includes the concept of "affordable".) |
Comprehensible | The set of requirements must be written such that it is clear as to what is expected by the entity and its relation to the system of which it is a part. |
Able to be validated | It must be able to be proven the requirement set will lead to the achievement of the entity needs within the constraints (such as cost, schedule, technical, legal and regulatory compliance). |
Requirements in Tables
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply:
- Invoke each requirements table in the requirements set that clearly points to the table.
- Identify each table with a unique title and table number.
- Include the word "requirements" in the table title.
- Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.
- For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.
- Each cell should contain, at most, a single requirement.
Requirements in Flow Charts
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:
- Invoke flow charts in the requirements set that clearly points to the flow chart.
- Identify each flow chart with a unique title and figure number.
- Include the word "requirements" in the title of the flow chart.
- Clearly indicate and explain unique symbols that represent requirements in the flow chart.
Requirements in Drawings
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:
- Drawings are used when they can aid in the description of the following:
- Spatial Requirements
- Interface Requirements
- Layout Requirements
- Invoke drawings in the requirements set that clearly point to the drawing.
This process may create several artifacts, such as:
- System Requirements Document
- System Requirements Justification Document (for traceability purpose)
- System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.
- System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.
Practical Considerations about System Requirements
There are several pitfalls that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.
Pitfall | Description |
Insufficient Analysis of Stakeholder Requirements | If the receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time. |
Insufficient Analysis of Operational Modes and Scenarios | The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces. |
Incomplete Set of System Requirements | If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed. |
Lack of Verification Method | Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself. |
Missing traceability | Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element. |
The proven practices in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.
Practice | Description |
Involve Stakeholders | Involve the stakeholders as early as possible in the system requirements development process. |
Presence of Rationale | Capture the rationale for each system requirement. |
Always Complete before Starting | Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements. |
Peer Reviews | Organize peer reviews of system requirements with applicable subject matter experts. |
Modeling Techniques | Use modeling techniques as indicated in sections above. |
Requirements Management Tool | Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle. |
Measures for Requirement Engineering | Use typical measures for requirement engineering; for further information, refer to the Systems Engineering Leading Indicators Guide (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:
Works Cited
Hauser, J. and D. Clausing. 1988. "The House of Quality." Harvard Business Review. (May - June 1988).
Hooks, I.F. and K.A. Farry. 2000. Customer-centered products: Creating successful products through smart requirements management. New York, NY, USA: American Management Association.
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. Systems Engineering, 3rd ed. London, UK: Springer.
INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
ISO/IEC. 2007. Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.
ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.
ISO/IEC/IEEE. 2015.Systems and Software Engineering - System Life Cycle Processes.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
Martin, J.N. 1997. Systems Engineering Guidebook: A Process for Developing Systems and Products, 1st ed. Boca Raton, FL, USA: CRC Press.
Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering complex systems with models and objects. New York, NY, USA: McGraw-Hill.
OMG. 2010. OMG Systems Modeling Language specification, version 1.2. Needham, MA: Object Management Group. July 2010.
Primary References
ISO/IEC/IEEE. 2011. Systems and Software Engineering - Requirements Engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.
ISO/IEC/IEEE. 2015.Systems and Software Engineering - System Life Cycle Processes.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC/IEEE 15288:2015.
INCOSE. 2015. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0
Lamsweerde, A. van. 2009. Requirements Engineering: From System Goals to UML Models to Software Specifications. New York, NY, USA: Wiley.
Additional References
Faisandier, A. 2012. Systems Opportunities and Requirements. Belberaud, France: Sinergy'Com.
Hooks, I.F. and K.A. Farry. 2000. Customer-Centered Products: Creating Successful Products through Smart Requirements Management. New York, NY, USA: American Management Association.
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. Systems Engineering, 3rd ed. London, UK: Springer.
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. Systems Engineering Leading Indicators Guide, version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area." in Capability Maturity Model Integrated (CMMI) for Development, version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).


text:
Wolf Den Podcast listeners: Your simple business financing starts here.
To speak with one of our OnDeck Loan Advisors, call 888-269-4246.
Or, if you're ready to apply for a business loan, click below to get started.
Applying will not impact your personal credit score.
A+ Rating
with the Better Business Bureau
$13 Billion
delivered to businesses globally
customer ratings on TrustPilot
Two flexible financing options
Decision in minutes - applying will not impact your personal credit score
Step 1
Apply online in just a few minutes or call us directly at (888) 269-4246 (M-F 8AM - 9PM)
Step 2
Our system evaluates your business and typically provides a decision in minutes
Step 3
Sign your contract and receive money in as fast as 24 hours
[adviser title="Highly skilled advisors, dedicated to serving you" body="Yes, we provide fast, efficient funding. But more than that, you also benefit from ongoing support from a knowledgeable advisor. Give us a call at (888) 269-4246 (M-F 8AM – 9PM ET, SAT 9AM – 5PM ET) or email email@example.com anytime." image="233″ name="Max M" job-title="Loan Specialist" location="Denver, CO" background="green" column="two" /]
Expertly Trained
Our intensive training equips your advisor with the knowledge they need to assess your unique business.
We're Here for You
Here and happy to serve you, your advisor swiftly responds to calls and emails, so you never have to wait long.
Ready for Anything
Your advisor is prepared to work with over 700 different industries. No company is too niche for OnDeck.
"I remember the process being smooth and straightforward, it can be incredibly stressful; fortunately, OnDeck had quick questions and quick responses. I could see how much financing I was approved for and what that meant [regarding payback]. I had the opportunity to review everything before I took the loan. The speed and efficiency of the process were incredible. I was able to introduce my RecoveryWear line and increase sales 4X over."Dana Donofree
Ana Ono Intimates
Philadelphia, PA
Our simple, secure web platform and mobile app make it easy for you to access your OnDeck account anywhere, anytime.
OnDeck's privacy policy and practices have been reviewed by TRUSTe® for compliance with its standards on transparency, accountability, and choice regarding the collection and use of personal information.

subset: commoncrawl


text:
Anything you blog can be held against you...
What is it with job seekers who also write blogs? Our recent faculty search at Quaint Old College resulted in a number of bloggers among our semifinalists. Those candidates looked good enough on paper to merit a phone interview, after which they were still being seriously considered for an on-campus interview.
That's when the committee took a look at their online activity.
In some cases, a Google search of the candidate's name turned up his or her blog. Other candidates told us about their Web site, even making sure we had the URL so we wouldn't fail to find it. In one case, a candidate had mentioned it in the cover letter. We felt compelled to follow up in each of those instances, and it turned out to be every bit as eye-opening as a train wreck.
Don't get me wrong: Our initial thoughts about blogs were, if anything, positive. It was easy to imagine creative academics carrying their scholarly activity outside the classroom and the narrow audience of print publications into a new venue, one more widely available to the public and a tech-savvy student audience.
We wanted to hire somebody in our stack of finalists, so we gave the same -- or more -- benefit of the doubt to the bloggers as to the others in the pool.
A candidate's blog is more accessible to the search committee than most forms of scholarly output. It can be hard to lay your hands on an obscure journal or book chapter, but the applicant's blog comes up on any computer. Several members of our search committee found the sheer volume of blog entries daunting enough to quit after reading a few. Others persisted into what turned out, in some cases, to be the dank, dark depths of the blogger's tormented soul; in other cases, the far limits of techno-geekdom; and in one case, a cat better off left in the bag.
The pertinent question for bloggers is simply, Why? What is the purpose of broadcasting one's unfiltered thoughts to the whole wired world? It's not hard to imagine legitimate, constructive applications for such a forum. But it's also not hard to find examples of the worst kinds of uses.
A blog easily becomes a therapeutic outlet, a place to vent petty gripes and frustrations stemming from congested traffic, rude sales clerks, or unpleasant national news. It becomes an open diary or confessional booth, where inward thoughts are publicly aired.
Worst of all, for professional academics, it's a publishing medium with no vetting process, no review board, and no editor. The author is the sole judge of what constitutes publishable material, and the medium allows for instantaneous distribution. After wrapping up a juicy rant at 3 a.m., it only takes a few clicks to put it into global circulation.
We've all done it -- expressed that way-out-there opinion in a lecture we're giving, in cocktail party conversation, or in an e-mail message to a friend. There is a slight risk that the opinion might find its way to the wrong person's attention and embarrass us. Words said and e-mail messages sent cannot be retracted, but usually have a limited range. When placed on prominent display in a blog, however, all bets are off.
So, to the job seekers.
Professor Turbo Geek's blog had a presumptuous title that was easy to overlook, as we see plenty of cyberbravado these days in the online aliases and e-mail addresses of students and colleagues.
But the site quickly revealed that the true passion of said blogger's life was not academe at all, but the minutiae of software systems, server hardware, and other tech exotica. It's one thing to be proficient in Microsoft Office applications or HTML, but we can't afford to have our new hire ditching us to hang out in computer science after a few weeks on the job.
Professor Shrill ran a strictly personal blog, which, to the author's credit, scrupulously avoided comment about the writer's current job, coworkers, or place of employment. But it's best for job seekers to leave their personal lives mostly out of the interview process.
It would never occur to the committee to ask what a candidate thinks about certain people's choice of fashion or body adornment, which countries we should invade, what should be done to drivers who refuse to get out of the passing lane, what constitutes a real man, or how the recovery process from one's childhood traumas is going. But since the applicant elaborated on many topics like those, we were all ears. And we were a little concerned. It's not our place to make the recommendation, but we agreed a little therapy (of the offline variety) might be in order.
Finally we come to Professor Bagged Cat. He was among the finalists we brought to campus for an interview, which he royally bombed, so we were leaning against him anyway. But we were irritated to find out, late in the process, that he had misrepresented his research, ostensibly to make it seem more relevant to a hot issue in the news lately. For privacy reasons, I'm not going to go into the details, but we were dismayed to find a blog that made clear that the candidate's research was not as independent or relevant as he had made it seem.
We felt deceived by his overstatement of his academic expertise. In this case, it was not the candidate's own blog, but that of a boasting friend, that revealed the truth. The lesson? Be careful what you let a close associate's blog say about you. What that associate sees as complimentary may cast you in an unflattering light in the eyes of a search committee.
Job seekers who are also bloggers may have a tough road ahead, if our committee's experience is any indication.
You may think your blog is a harmless outlet. You may use the faulty logic of the blogger, "Oh, no one will see it anyway." Don't count on it. Even if you take your blog offline while job applications are active, Google and other search engines store cached data of their prior contents. So that cranky rant might still turn up.
The content of the blog may be less worrisome than the fact of the blog itself. Several committee members expressed concern that a blogger who joined our staff might air departmental dirty laundry (real or imagined) on the cyber clothesline for the world to see. Past good behavior is no guarantee against future lapses of professional decorum.
A colleague from a different university provides this cautionary tale: After graduation, a student goes to the far side of the world to teach English. Student sends delightful travelogue home via e-mail messages, and recipients encourage student to record rare experiences in a blog. A year passes and the blog turns into a detailed personal gripe session about the job, students, coworkers, and place of employment. It is discovered and devoured by students, coworkers, and place of employment. Shamed student turns for support to alma-mater faculty members, who read the blog and chastise student for lack of professionalism and for tainting alma mater's reputation. Student now seeks other job -- without letters of recommendation from current employer or alma mater.


text:
The CAPI provides a wide range of built-in panes, but it is still fairly common to need to create panes of your own. In order to do this, you need to specify both the input behavior of the pane (how it reacts to keyboard and mouse events) and its output behavior (how it displays itself). The class
is provided for this purpose.
is a fully functional graphics port. This allows it to use all of the graphics ports functionality to create graphics, and it also has a powerful input model which allows it to receive mouse and keyboard input.


text:
Aruba Network Security Basics | Free ,Aruba Certification course
Aruba Network Security Basics | Free ,Aruba Certification course |
In Aruba Network Security Basics Course, you will explore what threats pose a risk to a basic computer network and what security technologies are available to harden your devices against these attacks.
How do messages get encrypted? What exactly is Malware? What technologies can we deploy that will allow networks to defend themselves? Our lives and business rely on having trusted secure access to our networks, but what does it take to ensure that security?
The Aruba Network Security Basics course is a starting point for individuals interested in a career as a security professional, and for anyone to who wants to get familiar with Aruba's security technologies. To get deeper technical knowledge with Aruba network security, see the Aruba Certified Network Security Associate (ACNSA) course.


text:
Measuring compressed air flows precisely in all conditions with a high-pressure air flow meter is the key to improving the energy efficiency of compressed air systems while reducing costs.
Using state-of-the-art technology, the non-invasive FLUXUS CA ultrasonic air flowmeter series, provides the best measurement solution.
FLUXUS CA permanent or portable compressed air flowmeters are ideally suited for carrying out energy audits, metering the consumption of compressed air, checking existing meters, detecting potential leaks, balancing plant networks as well as monitoring compressor efficiency.
By measuring from the pipe wall outside, FLUXUS CA flow meter for compressed air systems is completely free of wear and tear and requires zero maintenance. Moreover, due to its measurement principle, there is no risk of secondary contamination of the compressed air, neither can the compressed air flow measurement devices themselves be a risk of potential leaks.
FLUXUS CA CFM meter for compressed air measures reliably at metal pipes down to 3bar (plastic pipes without limitation), is extremely sensitive to low flows down to 0,01 m/s and can be applied at pipes sizes from DN15 to DN250.
Both the permanent or portable compressed air flowmeters are also available as ATEX / IECEx Zone 2 or FM Class I, Div. 2 approved variants.


text:
Dave Barry and Ridley Pearson have created a wonderful tale as a prequel to legend of Peter Pan. Peter and The Starcatchers, Peter and the Shadow Thieves, and Peter and the Secret of Rundoon explain many of the hows and whys to the Peter Pan. How does he fly? How did the alligator get the clock in his stomach? Why does Peter never grow old? These questions and more are answered.
Peter Pan, the Lost Boys, and Captain Hook have been reinvented so well that a generation from now no one might remember where J. M. Barrie's original creation ended and Barry's and Pearson's begins. So far, the two have written three incredibly fat and action-packed volumes of Peter's adventures with the "starstuff " – the magical fallen stars that gave him his power and – in effect – rendered him immortal, though as a boy doomed never to grow up.
If you haven't read this trilogy, you can't wander through them; the books have to be read in order. Peter's powers grow, as does the villainy of his foes. And readers are gently nudged out of the world that existed then and slid right into Neverland. If you like juvenile fantasy novels, you'll be hard-pressed to find many better, more quick to read, or more inventive than these. The world is at once familiar and wondrous.
If you are going on a long trip, with or without children, this is a great book-on-CD set to listen to as Jim Dale (narrator for the Harry Potter series) takes you to the magical world of Peter Pan with his many voices.


text:
Category Main Page Articles & Reviews
Main Nibbles
Main Page Articles & Reviews Of Foods From A To Z
Product Reviews
Main Page Food, Beverages, Books, News & More
March 2005 Last updated March 2010
Here you'll find terms including semisweet chocolate, single origin chocolate and Swiss chocolate. If you think we should consider chocolate terms and definitions other than those we have provided click on the Contact Us link on this page. Also enjoy our other 60 food glossaries.
Use this index bar to visit other pages.
a b c d e f g h i j k l m n o p q r s t u v w x y z
This glossary is protected by copyright and cannot be reproduced in whole or part.
An island republic in the Gulf of Guinea off the west coast of Africa, that is a prime growing area for the Amelonado subspecies of high quality Forastero. São Tomé cacao can be bitter with flavors of pure cocoa, sharp red fruits, cinnamon, and vanilla. It is a good base for blended chocolate.
The grooves, or channels, that separate a chocolate bar into segments are called score marks. Here, microbatch chocolate producer Askinosie shows how score marks become art.
Another word for the cacao bean; also called grain.
Semisweet chocolate is dark, sweetened eating chocolate made with at least 35% chocolate liquor plus cocoa butter. It is available in bars which may include added flavorings; and is also sold as morsels or chips. It may be used in recipes that call for bittersweet chocolate. In theory, there is more sugar in semisweet chocolate than in bittersweet, and a higher percentage of cacao in bittersweet, but the terms are sometimes used interchangeably.
See storage.
See molding.
Chocolate created with beans from one particular estate, plantation or hacienda (these terms are interchangeable). Single estate does not necessarily mean only a single variety of beans is used in the chocolate: It can be a blend (e.g. Criollo and Forastero) or a single variety of beans, as long as the beans come from the same estate.
Beans grown in one particular area or region,or the chocolate made from these beans (which can be called called single origin chocolate). This can either be a blend (e.g. Criollo and Forastero) or a single variety of beans. In fact, the origin of the bean can be a more important flavor determinant than the species of the bean (Criollo, Forastero or Trinitario). Seek to identify flavors of chocolate by the origin of its beans (Costa Rica, Madagascar or Venezuela, e.g.) rather than by whether it is Criollo- or Forastero-based. See also grand cru and premier cru.
See above.
The clear, crisp sound made from breaking a piece of chocolate from a bar. A good, clean snap is indicative of high cacao content and well-tempered chocolate. Milk chocolate which has lower levels of cocoa solids, and white chocolate which has no cocoa solids and is softer, don't have the same clean snap (the higher the cacao content, the harder the chocolate). The opposite of snap is crumbly.
Lecithin extracted from soybeans. Soy, not egg lecithin, is used in the manufacture of chocolate. It increases the pliability of the chocolate. See lecithin.
Top chocolatiers are concerned about the freshness of their product, and recommend that chocolate bars be consumed within three to six months after production. However, while they will not be as perfect as if consumed within six months, dark chocolate bars can be kept for two years or more if stored properly—well wrapped in foil in a cool, dark, dry place. A wine cellar is the ideal location because of its temperature and humidity. Milk and white chocolate have a more limited storage time, but will stay fresh for a year or more under these conditions. Filled chocolates, chocolates with nuts and other additives (including bars) have less of a shelf life because the additives will break down or go rancid. Commercial companies will use preservatives to extend the shelf-life, but most fine chocolates are made preservative-free. A box of fine filled chocolates or truffles should be consumed within two weeks, the sooner the better. The fillings, creams, and purées with which they are made deteriorate quickly: To enjoy them, they should be eaten soon after they are made. If you have a question about the shelf-life, call the chocolatier.
Sugar bloom is generally the result of a temperature shock—most often, storing chocolate in the refrigerator (which should not be done) and removing it to serve. When the chocolate is taken out of the refrigerator and condensation collects, a rough irregular texture forms on top of the chocolate. This is the sugar bloom. The condensation dissolves the sugar in the chocolate; when the water evaporates, the sugar recrystallizes into rough, irregular crystals on the surface which gives the chocolate an unattractive appearance. If chocolate has been stored in a cold place, allow it to come to room temperature slowly before opening the package, thus minimizing the condensation. Bars with sugar bloom can be re-melted and re-tempered, or used in baking or in sauces where the texture is not a factor. Bonbons with sugar bloom cannot be restored.
Sur Del Lago is one of the two distinct cacao growing regions of Venezuela (the other is Andean). It produces beans called Sur Del Lago Clasificado, a mixture of Criollo and Trinitario. This cacao is hearty and robust, and bears an extreme dark tone with flavors of butter, hazelnuts, and red fruits plus floral tones.
Surfin is a dark chocolate bar made by Lindt. It is supposedly an original recipe by the company founder, Rodolphe Lindt. After Rodolphe Lindt invented the conch, smooth, non-gritty chocolate was available for the first time. He called the chocolate fondant and, in 1845, labeled his candy bars Lindt Surfin. Surfin is the French word for "superior quality." Today, Lindt Surfin refers to its large-format Gold Bars (10.59 ounces/300g) and the smaller silver-label bars, made with this original recipe.
Sweet chocolate is a cooking and baking chocolate. It is made by mixing chocolate liquor with sugar and extra cocoa butter.
Fine chocolate is sweetened with cane sugar. Mass-produced chocolate can substitute high-fructose corn syrup. Fine chocolates labeled "sugar free" generally use maltitol, where mass-distributed chocolates can use saccharine, sorbitol or other less expensive sweeteners. See our article on sweeteners.
Of the three styles of bonbons—Belgian, French and Swiss—Swiss chocolates are the most creamy, smooth, soft and velvety and have a greater focus on milk chocolate. This is based on the heritage of the Swiss chocolate. In 1879, Daniel Peter, a Swiss chocolate manufacturer, successfully created milk chocolate by substituting powdered milk for the whole milk or cream that had been unsuccessfully used previously. In that same year, another chocolate manufacturer, Rodolphe Lindt, invented conching, the process that makes chocolate smoother and more velvety. And, the quality of the milk used in Swiss chocolate, which comes from alpine cows, contributes its own creaminess.
Continue To Next Page: Terms With T
Go To Article Index Above
Lifestyle Direct, Inc. All rights reserved. Images are the copyright of their respective owners.
© Copyright 2005-2024 Lifestyle Direct, Inc. All rights reserved. All images are copyrighted to their respective owners.


text:
§ 416.1111. How we count earned income.
(a) Wages. We count wages at the earliest of the following points: when you receive them or when they are credited to your account or set aside for your use. We determine wages for each month. We count wages for services performed as a member of a uniformed service (as defined in § 404.1330 of this chapter) as received in the month in which they are earned.
(b) Net earnings from self-employment. We count net earnings from self-employment on a taxable year basis. However, we divide the total of these earnings equally among the months in the taxable year to get your earnings for each month. For example, if your net earnings for a taxable year are $2,400, we consider that you received $200 in each month. If you have net losses from self-employment, we divide them over the taxable year in the same way, and we deduct them only from your other earned income.
(c) Payments for services in a sheltered workshop or activities center. We count payments you receive for services performed in a sheltered workshop or work activities center when you receive them or when they are set aside for your use. We determine the amount of the payments for each calendar quarter.
(d) In-kind earned income. We use the current market value of in-kind earned income for SSI purposes. (See § 416.1101 for a definition of current market value.) If you receive an item that is not fully paid for and are responsible for the unpaid balance, only the paid-up value is income to you. (See the example in § 416.1123(c)).
(e) Royalties and honoraria. We count payments of royalties to you in connection with any publication of your work, and honoraria, to the extent received for services rendered, at the earliest of the following points: when you receive them, when they are credited to your account, or when they are set aside for your use. (See § 416.1111(b) if you receive royalties as part of your trade or business.)
[45 FR 65547, Oct. 3, 1980, as amended at 48 FR 23179, May 24, 1983; 48 FR 30357, July 1, 1983; 50 FR 48574, Nov. 26, 1985; 58 FR 63889, Dec. 3, 1993; 59 FR 43471, Aug. 24, 1994; 71 FR 45378, Aug. 9, 2006]


text:
In 542 AD the late Roman (early Byzantine?) Emperor Justinian I wrote to his Praetorian Prefect concerning the army — trained and equipped and paid for by the Roman State to control the barbarians and to "increase the state." Justinian was, Peter Sarris reports in his Economy and Society in the Age of Justinian, upset that:
certain individuals had been daring to draw away soldiers and foederati from their duties, occupying such troops entirely with their own private business…. The emperor… prohibit[ed] such individuals from drawing to themselves or diverting troops… having them in their household… on their property or estates…. [A]ny individual who, after thirty days, continues to employ soldiers to meet his private needs and does not return them to their units will face confiscation of property… "and those soldiers and foederati who remain in paramonar attendance upon them… will not only be deprived of their rank, but also undergo punishments up to and including capital punishment.
Justinian is worried because what is going on in the country he rules is not legible to him. Soldiers — soldiers whom he has trained, equipped, and paid for — have been hired away from their frontier duties by the great landlords of the Empire and employed on their estates and in the areas they dominate as bully-boys. One such great landlord was Justinian's own sometime Praefectus Praetorio per Orientem Flavius Apion, to whom one of Flavius's tenants and debtors, one Anoup, wrote:
No injustice or wickedness has ever attached to the glorious household of my kind lord, but it is ever full of mercy and overflowing to supply the needs of others. On account of this I, the wretched slave of my good lord, wish to bring it to your lordship's knowledge by this present entreaty for mercy that I serve my kind lord as my fathers and forefathers did before me and pay the taxes every year. And by the will of God… my cattle died, and I borrowed the not inconsiderable amount of 15 solidi…. Yet when I approached my kind lord and asked for pity in my straits, those belonging to my lord refused to do my lord's bidding. For unless your pity extends to me, my lord, I cannot stay on my ktema and fulfill my services with regard to the properties of the estate. But I beseech and urge your lordship to command that mercy be shown to me because of the disaster that has overtaken me…
The late Roman Empire as Justinian wished it to be would consist of (a) slaves, (b) free Roman citizens (some of whom owned a lot of land), (c) soldiers, (d) bureaucrats, and (e) an emperor. The slaves would work for their masters. Slaves along with their citizen masters and non-slaveholding citizens would farm the empire (some of the citizens owning their land, some renting it). All would be prosperous and pay their taxes. And the emperor would use the taxes to pay the soldiers who dealt with the Persians, the Huns, the Goths, and the Vandals; to fund the building of Hagia Sophia and other works of architecture in Constantinople; and to promote the true faith and extirpate heresy. If the countryside were legible to him, that is how things would be–slaves and citizens in their places, landlords and tenants in their mutually beneficial contractual relationships, all prosperous and all paying their taxes to support the empire.
But Justinian knows very well that the countryside is not legible to him. The contracts that Flavius Apion makes with his tenants are made under the shadow of the threat that if Flavius Apion does not like the way things are going he will send a bucellarius to beat you up. Anoup is not pointing out to Flavius Apion that their landlord-tenant relationship is a good thing and that keeping him as a tenant rather than throwing him off the land for failure to pay the rent is in both their interests. Instead, Anoup is calling himself a slave (which he is not). Anoup is calling Flavius Apion a lord (which he is not supposed to be). Anoup is appealing to a long family history of dependence of himself and his ancestors on the various Flavii Apionoi and Flavii Strategioi of past generations. Justinian thinks that things would be better served if the countryside were properly legible to him and he could force reality to correspond to the legal order of slaves and citizens, tenants and landlords interacting through contract, and taxpayers. Flavius Apion would prefer that the order be one of proto-feudalism: that all the Anoups know and understand that they are at his mercy, and that the emperor is far, far away. And we don't know what Anoup thinks. We do know that it does not sound as though he experiences the lack of legibility of the countryside to the emperor and his state as a full and complete liberation. And we do know that the Emperor Justinian was gravely concerned about the transformation of his soldiers into bucellarii, into the dependent bully-boys of the landlords–both because it meant that they were not on the borders where they belonged and because it disturbed what he saw as the proper balance of power in the countryside and what he saw as the emperor's justice.
Justinian's big (and to him insoluble) problem was that the Flavius Apion whose bully-boys beat up his tenants when they displeased was the same Flavius Apion who headed Justinian's own bureaucracy.
Thus when James C. Scott speaks of how local knowledge and local arrangements having the ability to protect the people of civil society from an overmighty, blundering state, I say "perhaps" and I say "sometimes."
It is certainly the case that the fact that Sherwood Forest is illegible to the Sheriff of Nottingham allows Robin of Locksley and Maid Marian to survive. But that is just a stopgap. In the final reel of Ivanhoe the fair Rebecca must be rescued from the unworthy rogue Templar Sir Brian de Bois-Guilbert (and packed offstage to marry some young banker or rabbi), the Sheriff of Nottingham and Sir Guy of Gisborne must receive their comeuppance, the proper property order of Nottinghamshire must be restored, and Wilfred must marry the fair Rowena–and all this is accomplished by making Sherwood Forest and Nottinghamshire legible to the true king, Richard I "Lionheart" Plantagenet, and then through his justice and good lordship.
A state that makes civil society legible to itself cannot protect us from its own fits of ideological terror, or even clumsy thumb-fingeredness. A state to which civil society is illegible cannot help curb roving bandits or local notables. And neither type of state has proved terribly effective at constraining its own functionaries.
In some ways, the "night watchman" state — the state that enables civil society to develop and function without distortions imposed by roving bandits, local notables, and its own functionaries, but that also is content to simply sit back and watch civil society — is the most powerful and unlikely state of all.


text:
Show All Answers
When a residential property in Bristol has been condemned upon inspection by a governmental agency, such as the Health Department or Building Department, the residents residing lawfully in the property may be eligible for cash assistance. The assistance covers only the cost of the differential between the rent or mortgage that was being paid and the new rent. The new residence must meet building and health codes and pass an inspection. An application for assistance is to be completed at the Community Services office. There is a time limit and a financial cap on the assistance.
According to state mandate, the City of Bristol is to store the household goods left behind after the eviction occurs. A fee is charged daily for the storage of the items. Items that are not claimed by the evicted person within 15 days may be sold by the city at a public auction to recover any costs the city may have incurred.