text:
Talk:Making sense of quantum mechanics/observational properties

Observed/observational/observable property
Here we have a key issue in quantum mechanics. In my idea, observable = observational property. However the value of the observable is not necessarily the observed value (through a measurement). There are at least two reasons that could make them differ:
 * 1) experimental error in measurement
 * 2) intrinsic indeterminacy

The first reason is a common source of error. The second reason is peculiar to the nature of quantum objects and quantum measurements. If we visualize quantum objects as little needles and a quantum measurement as an interaction between two needles, we may get some insight: even if the position of a needle (say the geometrical center) is definite at a particular time, if the value were measured at that time, it could give a different position, because what is measured is the location of the point of interaction (=collision), which is generally not the geometrical center.

So we have an indeterminacy in position that is proportional to the length of the needle. For a velocity measurement, we have an indeterminacy proportional to the difference in translational velocity at both ends (due to the spinning motion). Arjen Dijksman 22:54, 18 September 2007 (UTC)

 * In the language of linear algebra, a quantum observable is a linear operator( ie a linear map, or if you like, a matrix), on a possibly infinite-dimensional vector space, and an observed value is an eigenvalue of this linear operator. -Hillgentleman|Talk 23:20, 19 September 2007 (UTC)
 * Yes. However we could notice some difference between an observable (a physical property) and its linear operator. The way Dirac introduces the linear operator in The Principles of Quantum Mechanics (1930) illustrates this. The chain between linear operator and observable is made of correspondences:
 * at §7, the linear operators correspond to the dynamical variables,
 * at §10: When we make an observation we measure some dynamical variable, and further:  We call a real dynamical variable whose eigenstates form a complete set an observable.
 * So, we have a correspondence between an operator (something that performs an operation on a state vector, which may be assimilated to an act of measurement) and an observable (a dynamical variable or property that is undetermined as long as the act of measurement has not given one of its possible outcomes).
 * I personally have the impression that there is a flaw when we say that an observed value is an eigenvalue of the linear operator. Eigenvalues are well determined values of measurement outcomes, while observed values are subject to experimental error and intrinsic indeterminacy. For example, the measurement of the energy of system in a state with discrete energy levels (say a particle in a box) will nearly never yield exactly one of its eigenvalues. In this light, I feel uncomfortable when I read Dirac (§10): We can infer that, with the dynamical system in any state, any result of a measurement of a real dynamical variable is one of its eigenvalues [hmmm...]. Conversely, every eigenvalue is a possible result of a measurement of the dynamical variable for some state of the system [yes, no problem with that], since it is certainly the result if the state is an eigenstate belonging to this eigenvalue [No! it maybe the theoretical result, but not the ascertained result of the act of measurement]. Arjen Dijksman 09:50, 23 September 2007 (UTC)


text:
User talk:TimBits

Hello TimBits, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) SB_Johnny | talk 23:11, 18 September 2007 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: User talk:TimBits


text:
User:Loiseaulybre

Retrouvez mon profil sur Wikipédia: Find out my profil on Wikipedia:

English Wikipedia ou French Wikipédia

fr:Utilisateur:Martial75

title: User:Loiseaulybre


text:
User:Twirpo75

My name is Crystal and I am 32 years old. I have no idea how to do any of this so it is going to look like total crap until I figure it all out.

Thanks.

title: User:Twirpo75


text:
User talk:Twirpo75

Hello Twirpo75, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) --Hillgentleman|Talk 00:42, 19 September 2007 (UTC)

P.S. Your crap looks fine to me. Hillgentleman|Talk 00:42, 19 September 2007 (UTC)

Spanish course refreshed
Hi, if you are still interested in studying Spanish language, let me invite you to this refreshed course Spanish One. It uses Wikibookian textbook "Spanish" and includes an oportunity of live discussio with teacher via Skype. The course understood the importance of live speech and understanding, when letter is understood like a code of explanations.--Juan 14:19, 5 January 2008 (UTC)

title: User talk:Twirpo75


text:
User talk:Kyarorin

Hello Kyarorin, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) --JWSchmidt 00:54, 19 September 2007 (UTC)

title: User talk:Kyarorin


text:
User talk:Jtrud703

Hello Jtrud703, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) --JWSchmidt 01:39, 19 September 2007 (UTC)

title: User talk:Jtrud703


text:
BCP/Ailanthus altissima/Logs

2008 Logs

 * (no archived logs yet)

Recent Logs

 * --SB_Johnny | talk 17:26, 3 July 2007 (UTC)
 * --SB_Johnny | talk 11:07, 4 July 2007 (UTC)
 * --SB_Johnny | talk 08:47, 13 June 2008 (UTC)
 * --SB_Johnny | talk 08:22, 24 June 2008 (UTC)

title: BCP/Ailanthus altissima/Logs


text: Category:BCP/Family/Simaroubaceae

title: Category:BCP/Family/Simaroubaceae


text: Category:BCP/Family/Caprifoliaceae

title: Category:BCP/Family/Caprifoliaceae


text:
BCP/Salvia leucantha

Salvia leucantha

title: BCP/Salvia leucantha


text:
BCP/Salvia leucantha/Logs

This page contains recent bloom logs for the plant Salvia leucantha (Mexican Bush Sage).

Recent Logs

 * --SB_Johnny | talk 10:22, 19 September 2007 (UTC)
 * SB Johnny-LM 11:59, 10 November 2007 (UTC)
 * SB Johnny-LM 18:34, 17 November 2007 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Salvia leucantha/Logs


text:
User:Me.swatha~enwikiversity

thanks i am me swatha. interested in helping wiki in any ways.

title: User:Me.swatha~enwikiversity


text:
BCP/Sicyos angulatus

Sicyos angulatus

title: BCP/Sicyos angulatus


text:
BCP/Sicyos angulatus/Logs

This page contains recent bloom logs for the plant Sicyos angulatus (Burr Cucumber).

Recent Logs

 * --SB_Johnny | talk 14:57, 31 August 2007 (UTC)
 * --SB_Johnny | talk 10:07, 8 September 2007 (UTC)
 * --SB_Johnny | talk 07:02, 1 October 2007 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Sicyos angulatus/Logs


text: Category:BCP/Family/Cucurbitaceae

title: Category:BCP/Family/Cucurbitaceae


text:
User:EdgeHillUni/Blog

=My Wikiversity Blog - Be bold= Copy this link and paste it into your aggregator. Add entry

My Second entry
Hello Again World EdgeHillUni 11:17, 19 September 2007 (UTC)

My first entry
Hello World EdgeHillUni 11:17, 19 September 2007 (UTC)

title: User:EdgeHillUni/Blog


text:
BCP/Chelone glabra

Chelone glabra

title: BCP/Chelone glabra


text:
BCP/Chelone glabra/Logs

2007 Logs

 * --SB_Johnny | PA! 18:04, 21 August 2007 (UTC)
 * --SB_Johnny | talk 07:04, 14 September 2007 (UTC)
 * --SB_Johnny | talk 11:26, 19 September 2007 (UTC)

2008 Logs

 * (no archived logs yet)

Recent Logs

 * Jomegat 03:18, 17 August 2008 (UTC)
 * Jomegat 23:57, 23 August 2008 (UTC)
 * Jomegat 01:01, 31 August 2008 (UTC)
 * Jomegat 22:47, 10 September 2008 (UTC)
 * Jomegat 20:08, 20 September 2008 (UTC)

title: BCP/Chelone glabra/Logs


text: Category:BCP/Family/Scrophulariaceae

title: Category:BCP/Family/Scrophulariaceae


text:
BCP/Alliaria petiolata/Logs

2007 Logs

 * --SB_Johnny | talk 13:25, 9 May 2007 (UTC)
 * --SB_Johnny | talk 09:56, 10 May 2007 (UTC)
 * --SB_Johnny | talk 23:17, 20 May 2007 (UTC)
 * SBJ 00:32, 23 May 2007 (UTC)
 * --SB_Johnny | talk 17:27, 23 May 2007 (UTC)
 * --SB_Johnny | talk 10:21, 26 May 2007 (UTC)
 * --SB_Johnny | talk 15:33, 9 June 2007 (UTC)
 * -- James Hade 04:12, 25 June 2007 (UTC) observed Howard County Maryland June 23, 2007, new blooms at leaf nodes, beneath maturing seed pods.
 * -- James Hade 12:01, 13 July 2007 (UTC) observed Howard County Maryland July 13, 2007, new blooms at leaf nodes, beneath mature seed pods.

2008 Logs

 * SB Johnny-LM 16:20, 16 April 2008 (UTC)
 * Tehpeggy 14:20, 24 April 2008 (UTC) blooms in Greenport, LI, NY, east end, north fork
 * SBJ 10:36, 26 April 2008 (UTC)
 * --Luai lashire 22:03, 28 April 2008 (UTC) been ripping them out of my yard for the past couple of days.
 * SB_Johnny-LM 09:50, 2 May 2008 (UTC)
 * --SB_Johnny | talk 09:50, 2 May 2008 (UTC)
 * --Luai lashire 20:57, 3 May 2008 (UTC)
 * --SB_Johnny | talk 09:39, 17 May 2008 (UTC)
 * --Turnvater Jahn 20:09, 21 May 2008 (UTC)
 * --SB_Johnny | talk 08:58, 27 May 2008 (UTC)
 * --SB_Johnny | talk 11:39, 4 June 2008 (UTC)
 * --SB_Johnny | talk 12:19, 14 June 2008 (UTC)

Recent Logs

 * Jomegat 21:22, 7 May 2009 (UTC)

title: BCP/Alliaria petiolata/Logs


text: Category:BCP/Family/Caryophyllaceae

title: Category:BCP/Family/Caryophyllaceae


text:
User talk:EdgeHillUni

Hello EdgeHillUni, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) --JWS 13:27, 19 September 2007 (UTC)

title: User talk:EdgeHillUni


text:
User talk:Me.swatha~enwikiversity

Hello Me.swatha, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) --JWS 13:28, 19 September 2007 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Me.swatha. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Me.swatha~enwikiversity that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:38, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 06:15, 19 April 2015 (UTC)

title: User talk:Me.swatha~enwikiversity


text:
User:Chucksafrit

Will add more when time allows.

title: User:Chucksafrit


text:
Portuguese Language/Phonology

Portuguese Vowels ( in IPA pronunciation)

initial or middle "a" [a],

final "a" [ɚ],

intial or middle "e". With accute graphic sign (é) is pronounced [ɛ], if circumflex graphic sign (ê) is pronounced [e],

final "e" [ɪ],

initial or middle "i" [i],

final "i" [ɪ],

initial or middle "o" if used with accute graphic sign (ó) is pronounced [ɔ], if used with circumflex graphic sign (ô) is pronounced [o],

final "o" [ʊ],

initial or middle "u" [ʊ],

nasalized "a", written "ã" [aŋ],

nasalized "e", pronounced when before "m" or "n" [eŋ],

nasalized "i", pronounced when before "m" or "n" [iŋ],

nasalized "o", pronounced when before "m" or "n" [oŋ],

nasalized "u", pronounced when before "m" or "n" [uŋ],

title: Portuguese Language/Phonology


text:
User:Sandeepjshenoy

Hi, I am Sandeep an Engineering student from India, specializing in Electronics.

title: User:Sandeepjshenoy


text:
User talk:Sandeepjshenoy

Hello Sandeepjshenoy, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) --JWS 15:44, 19 September 2007 (UTC)

title: User talk:Sandeepjshenoy


text:
User talk:Penelope~enwikiversity

Hello Penelope, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) Erkan Yilmaz ( evaluate me!, discussion ) 16:06, 19 September 2007 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Penelope. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Penelope~enwikiversity that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:40, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 06:17, 19 April 2015 (UTC)

title: User talk:Penelope~enwikiversity


text:
User:Averlienb

Averlienb joined Wikiversity on 12:22 AM (GMT +7), September 20 2007.

Averlienb is merely an anagram for her real name, which she prefers to be less known.

To know more about Averlienb, visit one of the following websites: friendster.com myspace.com/valinka

title: User:Averlienb


text:
User:Opasch

Hello, My name is Paolo. I am to improve my knowledge about math.

title: User:Opasch


text:
File:Sushant Sudarshan boy sixth dialogue.ogg

Used with the WikiU Film School Lesson on how to do Animatic Dialog Recording.


text:
User talk:Averlienb

Hello Averlienb, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) Erkan Yilmaz ( evaluate me!, discussion ) 17:03, 19 September 2007 (UTC)

Japanese
Hi, I see that you are interested in learning Japanese. Topic:Japanese is not active as of right now because the wikibook Japanese is undergoing restructuring. I see that you have some experience in Japanese. It would be a great help if you contributed to the Japanese book.

title: User talk:Averlienb


text: File:Joe Mac pretty girl enters2.ogg

title: File:Joe Mac pretty girl enters2.ogg


text: File:Joe Mac wedding melody2.ogg

title: File:Joe Mac wedding melody2.ogg


text: File:Joe Mac xmas melody2.ogg

title: File:Joe Mac xmas melody2.ogg


text: Nonlinear finite elements/Entropy inequality


text: File:Joe Mac papabear theme.ogg

title: File:Joe Mac papabear theme.ogg


text: File:Joe Mac mamabear theme.ogg

title: File:Joe Mac mamabear theme.ogg


text: File:Joe Mac goldilocks theme.ogg

title: File:Joe Mac goldilocks theme.ogg


text: File:Joe Mac babybear theme.ogg

title: File:Joe Mac babybear theme.ogg


text:
File:Nator7 Seduced By The Dark Side.pdf

Used with the WikiU Film School Lesson on how to format a movie script


text:
Nonlinear finite elements/Overview of balance laws

Governing equations in the deformed configuration
The governing equations for a continuum (apart from the kinematic relations and the constitutive laws) are

 * 1) Balance of mass
 * 2) Balance of linear momentum
 * 3) Balance of angular momentum
 * 4) Balance of energy
 * 5) Entropy inequality

Two important results from calculus
There are two important results from calculus that are useful when we use or derive these governing equations. These are

 * 1) The Gauss divergence theorem.
 * 2) The Reynolds transport theorem

These are useful enough to bear repeating at this point in the context of second order tensors.

The Gauss divergence theorem
The divergence theorem  relates volume integrals to surface integrals.

Let $$\Omega$$ be a body and let $$\partial \Omega $$ be its boundary with outward unit normal $$\mathbf{n}$$. Let $$\boldsymbol{A}(\mathbf{x})$$ be a second order tensor valued function of $$\mathbf{x}$$. Then, if $$\boldsymbol{A}$$ is differentiable at least once (i.e., $$\boldsymbol{A} \in C^0$$) then

\int_{\Omega} \boldsymbol{\nabla} \cdot \boldsymbol{A}(\mathbf{x})~\text{dV} = \int_{\partial \Omega} \boldsymbol{A}^T(\mathbf{x})\cdot\mathbf{n}~\text{dA} $$ It is often of interest to consider the situation where $$\boldsymbol{A}$$ is not continuously differentiable, i.e., when there are jumps in $$\boldsymbol{A}$$ within the body. Let $$\partial \Omega _{\text{int}}$$ represent the set of surfaces internal to the body where there are jumps in $$\boldsymbol{A}$$. In that case, the divergence theorem is written as

\int_{\Omega} \boldsymbol{\nabla} \cdot \boldsymbol{A}~\text{dV} = \int_{\partial \Omega} \boldsymbol{A}^T\cdot\mathbf{n}~\text{dA} + \int_{\partial \Omega_{\text{int}}} \left[\boldsymbol{A}^T_{+} - \boldsymbol{A}^T_{-}\right]\cdot\mathbf{n}_{+}~\text{dA} $$ where the subscripts $$+$$ and $$-$$ represents the values on the two sides of the jump discontinuity with normal $$\mathbf{n}_{+}$$.

Reynold's transport theorem
The transport theorem shows you how to ''' calculate the material time derivative of an integral. ''' It is a generalization of the Leibniz formula.

Let $$\Omega$$ be a body in its current configuration and let $$\partial \Omega $$ be its surface. Also, let $$\mathbf{v} = \dot{\mathbf{x}}$$.

If $$\phi(\mathbf{x},t)$$ is a scalar valued function of $$\mathbf{x}$$ and $$t$$ then

\cfrac{D}{Dt}\left[\int_{\Omega} \phi(\mathbf{x},t)~\text{dV}\right] = \int_{\Omega} \frac{\partial \phi}{\partial t}~\text{dV} + \int_{\partial \Omega} (\mathbf{v}\cdot\mathbf{n})~\phi~\text{dA} = \int_{\Omega} \left[\frac{\partial \phi}{\partial t} + \boldsymbol{\nabla} \cdot \left( \phi~\mathbf{v}\right) \right]~\text{dV} $$

If $$\mathbf{f}(\mathbf{x}, t)$$ is a vector valued function of $$\mathbf{x}$$ and $$t$$. Then

\cfrac{D}{Dt}\left[\int_{\Omega} \mathbf{f}(\mathbf{x}, t)~\text{dV}\right] = \int_{\Omega} \frac{\partial \mathbf{f}}{\partial t}~\text{dV} + \int_{\partial \Omega} (\mathbf{v}\cdot\mathbf{n})~\mathbf{f}~\text{dA} = \int_{\Omega} \left[\frac{\partial \mathbf{f}}{\partial t} + \boldsymbol{\nabla} \cdot (\mathbf{f}\otimes\mathbf{v})\right]~\text{dV} $$

To refresh your memory, recall that the material time derivative is given by

\begin{align} \cfrac{D\phi}{Dt} & = \frac{\partial \phi}{\partial t} + \boldsymbol{\nabla} \phi\cdot\mathbf{v} \\ \cfrac{D\mathbf{f}}{Dt} & = \frac{\partial \mathbf{f}}{\partial t} + \boldsymbol{\nabla} \mathbf{f}\cdot\mathbf{v} \\ \cfrac{D\boldsymbol{F}}{Dt} & = \frac{\partial \boldsymbol{F}}{\partial t} + (\boldsymbol{\nabla} \boldsymbol{F})^T\cdot\mathbf{v} \end{align} $$

Conservation of mass
For the situation where a body does not gain or lose mass, the balance of mass is written as

\cfrac{D\rho}{Dt} + \rho~\boldsymbol{\nabla} \cdot \mathbf{v} = 0 $$ Sometimes, this equation is also written in  conservative form as

\frac{\partial \rho}{\partial t} + \boldsymbol{\nabla} \cdot (\rho~\mathbf{v}) = 0 $$ If the material is  incompressible then the density does not change with time and we get

\boldsymbol{\nabla} \cdot \mathbf{v} = 0 $$ For Lagrangian descriptions we can show that

\rho~J = \rho_0 $$ where $$\rho_0$$ is the initial density.

Conservation of linear momentum
The balance of linear momentum is essentially Newton's second applied to continua. Newton's second law can be written as

\cfrac{D\mathbf{p}}{Dt} = \mathbf{f} $$ where the linear momentum $$\mathbf{p}$$ is given by

\mathbf{p}(t) = \int_{\Omega} \rho(\mathbf{x},t)~\mathbf{v}(\mathbf{x},t)~\text{dV} $$ and the total force $$\mathbf{f}$$ is given by

\mathbf{f}(t) = \int_{\Omega} \rho(\mathbf{x},t)~\mathbf{b}(\mathbf{x},t)~\text{dV} + \int_{\partial \Omega} \mathbf{t}(\mathbf{x},t)~\text{dA} $$ where $$\rho$$ is the density, $$\mathbf{v}$$ is the spatial velocity, $$\mathbf{b}$$ is the body force and $$\mathbf{t}$$ is the surface traction. Therefore, the balance of linear momentum can be written as

\cfrac{D}{Dt}\left[\int_{\Omega} \rho(\mathbf{x},t)~\mathbf{v}(\mathbf{x},t)~\text{dV}\right] = \int_{\Omega} \rho(\mathbf{x},t)~\mathbf{b}(\mathbf{x},t)~\text{dV} + \int_{\partial \Omega} \mathbf{t}(\mathbf{x},t)~\text{dA} $$ Now using the transport theorem, we have

\cfrac{D}{Dt}\left[\int_{\Omega} \rho~\mathbf{v}~\text{dV}\right] = \int_{\Omega} \left[\rho~\cfrac{D\mathbf{v}}{Dt} + \left(\cfrac{D\rho}{Dt} + \rho~\boldsymbol{\nabla} \cdot \mathbf{v}\right)\right]~\text{dV} $$ From the conservation of mass, the second term on the right hand side is zero and we are left with

\cfrac{D}{Dt}\left[\int_{\Omega} \rho(\mathbf{x},t)~\mathbf{v}(\mathbf{x},t)~\text{dV}\right] = \int_{\Omega} \rho~\cfrac{D\mathbf{v}}{Dt}~\text{dV} $$ Therefore, the balance of linear momentum can be written as

\int_{\Omega} \rho~\cfrac{D\mathbf{v}}{Dt}~\text{dV} = \int_{\Omega} \rho~\mathbf{b}~\text{dV} + \int_{\partial \Omega} \mathbf{t}~\text{dA} $$ Using Cauchy's theorem ($$\mathbf{t} = \boldsymbol{\sigma}\cdot\mathbf{n}$$) and the divergence theorem we can show that the balance of linear momentum can be written as

\boldsymbol{\nabla} \cdot \boldsymbol{\sigma} + \rho~\mathbf{b} = \rho~\cfrac{Dv}{Dt} = \rho~\mathbf{a} $$ In index notation,

\sigma_{ij,j} + \rho~b_i = \rho~\cfrac{Dv_i}{Dt} $$

Conservation of angular momentum
We also have to make sure that the moments are balanced. This requirement takes the form of the conservation of angular momentum and can be written as

\cfrac{D}{Dt}\left[\int_{\Omega} \mathbf{x} \times (\rho~\mathbf{v})~\text{dV}\right] = \int_{\Omega} \mathbf{x} \times (\rho~\mathbf{b})~\text{dV} + \int_{\partial \Omega} \mathbf{x} \times \mathbf{t}~\text{dA} $$ We can show that this equation reduces down to the requirement that the Cauchy stress is symmetric, i.e.,

\boldsymbol{\sigma} = \boldsymbol{\sigma}^T $$

Conservation of energy
The balance of energy can be expressed as

\rho~\cfrac{De}{Dt} = \boldsymbol{\sigma}:(\boldsymbol{\nabla}\mathbf{v}) - \boldsymbol{\nabla} \cdot \mathbf{q} + \rho~s $$ where $$e$$ is the internal energy per unit mass, $$\mathbf{q}$$ is the heat flux vector and $$s$$ is the heat source per unit volume.

We may also write this equation as

\rho~\cfrac{De}{Dt} = \boldsymbol{\sigma}:\boldsymbol{d} - \boldsymbol{\nabla} \cdot \mathbf{q} + \rho~s $$ where $$\mathbf{d}$$, the rate of deformation tensor, is the symmetric part of the velocity gradient. We can do this because the contraction of the skew symmetric part of the velocity gradient with the symmetric Cauchy stress gives us zero.

For purely mechanical problems, $$\mathbf{q} = 0$$ and $$s = 0$$. So we can write

\rho~\cfrac{De}{Dt} = \boldsymbol{\sigma}:\boldsymbol{d} $$ This shows that $$\boldsymbol{\sigma}$$ and $$\boldsymbol{d}$$ are  conjugate in power.

Entropy inequality
The entropy inequality is useful in determining which forms of the constitutive equations are admissible. This inequality is also called the dissipation inequality. In its Clausius-Duhem form, the inequality may written as

\cfrac{d}{dt}\left(\int_{\Omega} \rho~\eta~\text{dV}\right) \ge -\int_{\partial \Omega} \rho~\eta~\mathbf{v}\cdot\mathbf{n}~\text{dA} - \int_{\partial \Omega} \cfrac{\mathbf{q}\cdot\mathbf{n}}{T}~\text{dA} + \int_{\Omega} \cfrac{\rho~s}{T}~\text{dV} ~. $$ where $$\eta$$ is the specific entropy (entropy per unit mass) and $$T$$ is the temperature. In differential form the Clausius-Duhem inequality can be written as

\rho~\dot{\eta} \ge - \boldsymbol{\nabla} \cdot \left(\cfrac{\mathbf{q}}{T}\right) + \cfrac{\rho~s}{T} ~. $$

In terms of the specific internal energy, the entropy inequality can be expressed as

\rho~(\dot{e} - T~\dot{\eta}) - \boldsymbol{\sigma}:\boldsymbol{\nabla}\mathbf{v} \le - \cfrac{\mathbf{q}\cdot\boldsymbol{\nabla} T}{T} ~. $$ If we define the  Helmholtz free energy (the energy that is available to do mechanical work) as

\psi = e - \eta~T $$ we can also write,

\rho~(\dot{\psi} + T~\dot{\eta}) - \boldsymbol{\sigma}:\boldsymbol{d} \le - \cfrac{\mathbf{q}\cdot\boldsymbol{\nabla} T}{T} ~. $$

Governing equations in the reference configuration
The Lagrangian form of the governing equations can be obtained using the relations between the various measures in the deformed and reference configurations.

Balance of mass
The Lagrangian form of the balance of mass is

\rho(\mathbf{X},t)~J(\mathbf{X},t) = \rho_0(\mathbf{X}) $$

Balance of linear momentum
The Lagrangian form of the balance of linear momentum is

\boldsymbol{\nabla}_{\circ}\cdot\boldsymbol{N} + \rho_0~\mathbf{b} = \rho_0~\frac{\partial \mathbf{v}(\mathbf{X},t)}{\partial t} $$ where $$\boldsymbol{N}$$ is the nominal stress and $$\boldsymbol{\nabla}_{\circ}\cdot(\bullet)$$ indicates that the derivatives are with respect to $$\mathbf{X}$$. In terms of the first Piola-Kirchhoff stress $$\boldsymbol{P}$$ we can write

\boldsymbol{\nabla}_{\circ}\cdot\boldsymbol{P}^T + \rho_0~\mathbf{b} = \rho_0~\frac{\partial \mathbf{v}(\mathbf{X},t)}{\partial t} $$ In index notation,

P_{ji,j} + \rho_0~b_i = \rho_0 \dot{v}_i $$

Balance of angular momentum
The balance of angular momentum in Lagrangian form is

\boldsymbol{N}^T\cdot\boldsymbol{F}^T = \boldsymbol{F}\cdot\boldsymbol{N} $$ In terms of the first Piola-Kirchhoff stress

\boldsymbol{P}\cdot\boldsymbol{F}^T = \boldsymbol{F}\cdot\boldsymbol{P}^T $$ In terms of the second Piola-Kirchhoff stress

\boldsymbol{S} = \boldsymbol{S}^T $$

Balance of energy
In the material frame, the balance of energy takes the form

\rho_0~\frac{\partial e(\mathbf{X},t)}{\partial t} = \dot{\boldsymbol{F}}^T:\boldsymbol{N} - \boldsymbol{\nabla}_{\circ}\cdot\mathbf{Q}(\mathbf{X},t) + \rho_0~s $$ where $$\mathbf{Q}$$ is the heat flux per unit reference area.

In terms of the first Piola-Kirchhoff stress tensor we have

\rho_0~\frac{\partial e(\mathbf{X},t)}{\partial t} = \dot{\boldsymbol{F}}^T:\boldsymbol{P}^T - \boldsymbol{\nabla}_{\circ}\cdot\mathbf{Q}(\mathbf{X},t) + \rho_0~s $$

Entropy inequality
The entropy inequality in Lagrangian form is

\rho_0~(\dot{\psi} + T~\dot{\eta}) - \boldsymbol{N}:\dot{\boldsymbol{F}} \le - \cfrac{\mathbf{\mathbf{Q}}\cdot\boldsymbol{\nabla}_0 T}{T} ~. $$ In terms of the first P-K stress we have

\rho_0~(\dot{\psi} + T~\dot{\eta}) - \boldsymbol{P}^T:\dot{\boldsymbol{F}} \le - \cfrac{\mathbf{\mathbf{Q}}\cdot\boldsymbol{\nabla}_0 T}{T} ~. $$

Conjugate work measures
Whatever measures we choose to use to represent stress and strain (or a rate of strain), their product should give us a measure of the work done (or the power spent). This measure should not depend on the chosen measures.

Therefore, the correct combination of stress and strain should be  work conjugate or  power conjugate. Three commonly used power conjugate stress and rate of strain measures are

 * 1) The Cauchy stress ($$\boldsymbol{\sigma}$$) and the rate of deformation ($$\boldsymbol{d}$$).
 * 2) The nominal stress ($$\boldsymbol{N}$$) and the rate of the deformation gradient ($$\boldsymbol{F}$$).
 * 3) The second P-K stress ($$\boldsymbol{S}$$) and the rate of the Green strain ($$\boldsymbol{E}$$).

We can show that, in the absence of heat fluxes and sources,

\dot{e} = \cfrac{1}{\rho}~\boldsymbol{\sigma}:\mathbf{d} = \cfrac{1}{\rho_0}~\mathbf{N}:\dot{\boldsymbol{F}} = \cfrac{1}{\rho_0}~\mathbf{P}^T:\dot{\boldsymbol{F}} = \cfrac{1}{\rho}~\boldsymbol{S}:\dot{\boldsymbol{E}} $$ Many more work/power conjugate measures can be found in the literature.


text:
User:Coredevice

Daniel Velandia

title: User:Coredevice


text:
User talk:Coredevice

Hello Coredevice, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. When leaving comments for others to read, remember to sign and date; it helps everyone keep track of who is writing messages. The signature icon in the edit window makes it simple. To help you get started:
 * Take a guided tour and learn how to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research pages; and
 * Read and help develop our community policies.

If you're already excited about editing, our sandbox is the perfect place for all test edits. Also, don't forget to experiment with the links to your left. Be bold, and see you around Wikiversity!

P.S. Do you want live feedback ? You can find us in #wikiversity-en (see Chat) Erkan Yilmaz ( evaluate me!, discussion ) 06:21, 20 September 2007 (UTC)

Networking Regenesis
Hi, I've noticed you are listed as one of active participants in the topic: Computer networks page. If you are still active we are holding discussions as to how we wish to clean up the topic and move it forward. Please see the Topic_talk:Computer_networks page and add your thoughts there. Lysander89 00:28, 24 August 2009 (UTC)

title: User talk:Coredevice


text:
BCP/Aster divaricatus

Aster divaricatus

title: BCP/Aster divaricatus


text:
BCP/Aster divaricatus/Logs

2007 Logs

 * Luai lashire 18:51, 25 August 2007 (UTC)
 * SB Johnny-LM 09:56, 19 September 2007 (UTC)
 * --Luai lashire 14:54, 26 September 2007 (UTC)
 * SB Johnny-NHAMP 23:07, 8 October 2007 (UTC)
 * --Jomegat 04:20, 10 October 2007 (UTC)
 * --Luai lashire 01:36, 14 October 2007 (UTC)
 * --Jomegat 18:15, 15 October 2007 (UTC)
 * --Luai lashire 20:39, 17 October 2007 (UTC)
 * --Jomegat 16:42, 18 October 2007 (UTC)
 * --Luai lashire 22:54, 23 October 2007 (UTC)
 * --Jomegat 23:00, 1 November 2007 (UTC)
 * --Jomegat 00:49, 7 November 2007 (UTC)

2008 Logs

 * (no archived logs yet)

Recent Logs

 * Jomegat 23:49, 23 August 2008 (UTC)
 * Jomegat 00:09, 30 August 2008 (UTC)
 * Jomegat 21:38, 1 September 2008 (UTC)
 * Jomegat 22:44, 10 September 2008 (UTC)
 * Jomegat 12:27, 19 September 2008 (UTC)
 * --SB_Johnny talk 09:12, 23 September 2008 (UTC)
 * Jomegat 21:02, 29 September 2008 (UTC)
 * Jomegat 23:12, 3 October 2008 (UTC)
 * Jomegat 18:12, 3 November 2008 (UTC)

title: BCP/Aster divaricatus/Logs


text:
User:Sh nazari

Hello every one and dear friends

I am working on a theory of speared of eternal inelegancy in any existing universe and of course our universe as a home for Human being. I see this subject is very interesting; all people might have many questions such as

Q: are we the only intelligence creature existed in all universes? Q: if other planes have similar characters like Earth, could they have creatures and intelligence creature? How they look like? Q: If we refer to some theory, about the development of humans from Apes Big question is, why inelegancy did not developed in Apes? Even they older than us living on earth. Q: In the end of this subject, Human and other Creatures cannot live on earth forever The earth has its life. We won’t live on earth forever. We cannot travel long distance (e.g. thousands of years), because the human life is too short and many other barriers. So the question how we can save the inelegancy and human race?

I am using some Physics, Metaphysic, Chemistry, Genetics, basic math, other theories and some imagination. My theory is not based on science, but I used some scientific references to prove few part of it.

I would like to discuss this subject further with other people that interested in the subject, and the last thing I am new in Wikipedia. Should have any comment please contact me, many thanks

title: User:Sh nazari


text:
User talk:Sh nazari

Hello every one and dear friends

I am working on a theory of speared of eternal inelegancy in any existing universe and of course our universe as a home for Human being. I see this subject is very interesting; all people might have many questions such as

Q: are we the only intelligence creature existed in all universes? Q: if other planes have similar characters like Earth, could they have creatures and intelligence creature? How they look like? Q: If we refer to some theory, about the development of humans from Apes Big question is, why inelegancy did not developed in Apes? Even they older than us living on earth. Q: In the end of this subject, Human and other Creatures cannot live on earth forever The earth has its life. We won’t live on earth forever. We cannot travel long distance (e.g. thousands of years), because the human life is too short and many other barriers. So the question how we can save the inelegancy and human race?

I am using some Physics, Metaphysic, Chemistry, Genetics, basic math, other theories and some imagination. My theory is not based on science, but I used some scientific references to prove few part of it. I tried my best to answer these questions and many others and to find some solutions I would like to discuss this subject further with other people that interested in the subject, and the last things I am new in Wikipedia. Should have any comment please contact me

 * Sh nazari, Welcome. I think you will need to define your terms ... I do not know what you mean by "speared" or "inelegancy" in this context.  The subject sounds interesting so some discussion projects or pages should eventually attract some interest.   I will be interested in how you go about proving or disproving that the human race cannot live on Earth forever.   There are interesting books and papers around regarding how the human race might seed itself through the universe in the millions and billions of years ahead of us.   See you around.  Mirwin 16:48, 20 September 2007 (UTC)

title: User talk:Sh nazari


text:
Talk:Filmmaking Basics/3D Storyboard/QuickStart

Hello I was very much helped by the information with this article. Many thanks at you very fascinating resource. good by -67.52.216.8


text:
User talk:Lange2

Universal World University
My Name is Eric Leonard Lang and I want to join efforts with Wikipedia/ Wikiversity to create the Universal World University (UWU).

My Name is Eric Leonard Lang and I want to join efforts with Wikipedia/ Wikiversity to create the Universal World University (UWU).

1.	This Online University will allow individual’s world wide to express and demonstrate their academic knowledge base about selected subject(s)/topic(s)of their personal interest.

2.	Through an online web formatted worksheet which provides outline and structure, subscribers can intelligently write about their chosen topic of interest in great detail literally demonstrating their knowledge base and research as it pertains to applicable academic disiciplines if possible.

3.	The basic concept is that all hubbies and personal/ public interest fall under some form of quantifiable and academic discipline. Once such a paper or thesis is complete, the writer can then elect to submit it through UWU to the world for review and grade. A percentage grade based on the numbers of individual subscribers who agree or disagree will be assigned to the author’s written works. A feasible cut off for the number of subscribers who feel compelled to express their position(s) on the subject via written arguments or support, will be subject to a time deadline constraint consisting of either 30, 60 or 90 days. An example of how this constraint would work is by stipulating the first 50 subscribers, within such a prescribed time, can wage their opinion for percentage grade impact on the submitting author’s subject. Personal knowledge bases will be shared and challenged in this structured forum.

4.	This peer graded university will spawn intelligent written discussions on subjects of great personal interest; however, unlike blogs this website allows the full expression and organization of one’s thoughts and ideas through personal experience and will require the academic demonstrations in accordance with all facts currently established in early and modern literature whichever as applicable. All applicable disciplines should be demonstrated to some degree in the writings to include the principles of the chosen theoretical writing styles, e.g. (APA, MLA, etc).

My Name is Eric Leonard Lang and I want to join efforts with Wikipedia/ Wikiversity to create the Universal World University (UWU).

title: User talk:Lange2


text:
User:J07mac

a student at wikipedia

title: User:J07mac


text:
User:JWSchmidt/Blog/20 September 2007

I like the idea of making use of audio and video learning resources at Wikiversity. I previously pointed to Ward Cunningham's comments on collaborative video creation and we now have a working video player for use on Wikiversity webpages. I've been thinking about ways to facilitate collaborative video creation within Wikiversity and I'm starting to think that this is a good example of how we could use the Sandbox Server.

Video collaboration interface
How can collaborative creation of educational videos be facilitated by a wiki? One of the problems of conventional video resource creation is that it is often only the final product that gets uploaded. When collaboratively editing text, every word is available for easy access during the collaborative editing process. During the creation of video, there are often many smaller audio and video clips that get combined to produce the final uploaded video. Collaborative creation of educational videos would be facilitated by having a "bank" of all the small audio and video clips used during the production of videos.

In addition to making small audio and video clips available for use by others, collaborative creation of educational videos could be facilitated by lowering the barriers to creation of new video clips. YouTube provides a simple way for people to upload video from webcams. Wikiversity participants could be provided with a similar "one click" system for capturing audio and video clips with their PCs and uploading them directly to Wikiversity.

Assuming that Wikiversity has a bank or database of audio and video clips, it would then be useful to have an easy-to-use interface for viewing the clips, grouping them according to possible use in specific video creation projects, editing them, and combining clips for use in larger video projects. Just as wiki pages have a "history tab", it would be nice to keep a record of multiple versions of a video. Just as most wiki pages are available for new edits, there should be a simple way for wiki participants to view past versions of a video and then quickly create a new version.

What might be particularly useful is if the video editing interface could be used simultaneously by two or more collaborators who could view a draft version of a video under construction and discuss it in real time via audio chat.

Related

 * Format Conversion - there was a significant amount of discussion in January 2008 about file formats, including video. See also:
 * [Wikipedia Invites Users to Take Part in Open, Collaborative Video Experiment]
 * User:JWSchmidt/Blog/4 September 2007

title: User:JWSchmidt/Blog/20 September 2007


text: Template:Sandbox

title: Template:Sandbox


text:
Template talk:Sandbox

Template testing
I thought I should make something to play with. This one uses the #ifeq MediaWiki parser function to test and display where it is. I figure we can add other things to make a tool for playing around with MediaWiki parser functions and variables and Generating dynamic content with MediaWiki. • CQ 22:33, 7 July 2009 (UTC)

title: Template talk:Sandbox


text: Category:Free Content

title: Category:Free Content


text:
User:AL-KAFF

Personal Info.

 * Name: Abdullah Ahmad Shiekh bin Sir\Sayyed\Bubaker bin Shiekh Al-Kaff.

 * Nationality: Yemeni.

 * Origin: Hadhramout - Siey'un City.

 * Birthdate and place: 22nd Jan 1985, in Riyadh - S.A.

 * Living Place: Aden City - Yemen.

Studies' Info

 * College Studying Section: Electronics and Communication Engineering (Aden University).

 * Interrestings: Audio Engineering, Free Hand Drawing.

 * Researchings: Ideologies on world ordering, Soundwaves effect on human.

--AL-KAFF 21:29, 20 September 2007 (UTC)

title: User:AL-KAFF


text:
User talk:AL-KAFF

Welcome
Hello AL-KAFF, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; for it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other wikiversiters on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! --JWS 22:20, 20 September 2007 (UTC)

Invitation
Dear user of Wikiversity,

Do you like to join a reading club, where you can read and discuss literature? Reading clubs could have active and inactive participants. Active participants could be required to edit on a regularly basis untill a deadline is reached and another topic can be chosen for reading and discussing. Hopefully, reading clubs can ensure a social network on Wikiversity of people cooperating with eachother and becoming friends while discussing knowledge.--Daanschr 09:22, 1 November 2007 (UTC)

title: User talk:AL-KAFF


text: Category:Colleges

title: Category:Colleges


text:
Direct current/Generator

An Electrical Generator is a machine which converts mechanical power into electrical energy power.

It is based on the principle of production of dynamically induced EMF.

Whenever a conductor cuts magnetic flux, dynamically induced EMF is produced in it according to Faraday's Law's of Electromagnetic Induction. This e.m.f. causes a current to flow if the conductor circuit is closed. This is accomplished in an electric generator by means of an armature carrying conductors which works in conjunction with a magnetic field. Electromotive force is induced by the relative motion of the armature conductors and the magnetic field.

Hence, the basic essential parts of an electric generator are :

 * 1) A magnetic field
 * 2) A conductor or conductors which can so move as to cut the flux.

Basic DC machine is that of commutator type, ie. it is an AC machine furnished with a commutator such that it converts the AC to DC. In this respect we can say that the commutator segments act as mechanical rectifiers.

-

So as you can see there lies a simple generator with a field, coil and relative motion between them. So from faraday's laws of EMI we can say that the coil(loop) would house an EMF.

Depending upon field type DC generators are classified. These are mainly 2 types 1) separately excited generators 2) self excited generators

In separately excited generators field is excited from a separate voltage source. Whereas in self excited type field is excited with permanent magnets.

Depending on field connection with armature they are further classified as 3 types i) series generators ii)shunt generators iii)compound generators

title: Direct current/Generator


text:
BCP/Waldsteinia fragarioides/Logs

This page contains recent bloom logs for the plant Waldsteinia fragarioides (Barren Strawberry).

Recent Logs

 * --SB_Johnny | talk 11:33, 26 April 2007 (UTC)
 * --SB_Johnny | talk 17:27, 29 April 2007 (UTC)
 * --SB_Johnny | talk 11:26, 4 May 2007 (UTC)
 * SB Johnny-LM 00:23, 17 April 2008 (UTC)
 * --SB_Johnny | talk 12:12, 26 April 2008 (UTC)
 * --SB_Johnny | talk 12:06, 4 May 2008 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Waldsteinia fragarioides/Logs


text:
BCP/Weigela/Logs

2007 Logs

 * SBJ 10:30, 23 May 2007 (UTC)
 * --SB_Johnny | talk 17:27, 23 May 2007 (UTC)
 * SBJ 09:18, 25 May 2007 (UTC)
 * --SB_Johnny | talk 17:31, 27 May 2007 (UTC)
 * SBJ 08:28, 14 July 2007 (UTC) (Distinct set of flowers from the spring bloom)

2008 Logs

 * (no archived logs yet)

2011 Logs

 * (no archived logs yet)

Recent Logs

 * --SB_Johnny | talk 17:54, 9 May 2008 (UTC)
 * --SB_Johnny | talk 12:20, 20 May 2008 (UTC)
 * --SB_Johnny | talk 11:13, 27 May 2008 (UTC)
 * --SB_Johnny | talk 11:38, 4 June 2008 (UTC)

title: BCP/Weigela/Logs


text:
BCP/Dicentra spectabilis/Logs

2007 Logs

 * --SB_Johnny | talk 11:33, 26 April 2007 (UTC)
 * --SB_Johnny | talk 17:27, 29 April 2007 (UTC)
 * --SB_Johnny | talk 11:26, 4 May 2007 (UTC)
 * --SB_Johnny | talk 10:02, 9 May 2007 (UTC)
 * --SB_Johnny | talk 09:56, 10 May 2007 (UTC)
 * SBJ 12:05, 12 May 2007 (UTC)
 * --SB_Johnny | talk 23:17, 20 May 2007 (UTC)
 * --SB_Johnny | talk 17:27, 23 May 2007 (UTC)
 * --SB_Johnny | talk 10:21, 26 May 2007 (UTC)
 * SBJ 19:25, 31 May 2007 (UTC)
 * --SB_Johnny | talk 23:49, 31 May 2007 (UTC)
 * --SB_Johnny | talk 10:47, 3 June 2007 (UTC)
 * SB Johnny-LM 10:00, 9 June 2007 (UTC)
 * --SB_Johnny | talk 14:34, 9 June 2007 (UTC)

2008 Logs

 * SB_Johnny-LM 11:00, 20 April 2008 (UTC)
 * --SB_Johnny | talk 11:00, 20 April 2008 (UTC)
 * --SB_Johnny | talk 10:24, 27 April 2008 (UTC)
 * --Luai lashire 21:59, 28 April 2008 (UTC)
 * --Luai lashire 21:01, 3 May 2008 (UTC)
 * --SB_Johnny | talk 11:37, 4 May 2008 (UTC)
 * --SB_Johnny | talk 10:10, 17 May 2008 (UTC)
 * --SB_Johnny | talk 13:42, 10 June 2008 (UTC)

Recent Logs

 * --Anna reg 13:42, 20 April 2011 (Photo)
 * --Anna reg 20:17, 28 April 2010 (UTC)

title: BCP/Dicentra spectabilis/Logs


text: Category:BCP/Family/Fumariaceae

title: Category:BCP/Family/Fumariaceae


text:
BCP/Crocus vernus/Logs

This page contains recent bloom logs for the plant Crocus vernus (Crocus).

Recent Logs
--Luai lashire 23:42, 26 March 2008 (UTC)
 * SB Johnny-LM 11:13, 13 March 2007 (UTC)
 * --SB_Johnny | talk 18:06, 27 March 2007 (UTC)
 * Cormaggio talk 13:16, 29 January 2008 (UTC)
 * --Luai lashire 23:05, 13 March 2008 (UTC)
 * SB Johnny-LM 08:14, 22 March 2008 (UTC)
 * Ngravagna 17:44, 27 March 2008 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Crocus vernus/Logs


text: Category:BCP/Family/Iridaceae

title: Category:BCP/Family/Iridaceae


text:
BCP/Cornus mas/Logs

This page contains recent bloom logs for the plant Cornus mas (Cornelian Cherry).

2007 Logs

 * --SB_Johnny | talk 18:06, 27 March 2007 (UTC)
 * SB Johnny-LM 13:22, 31 March 2007 (UTC)

2008 Logs

 * --SB_Johnny | talk 14:18, 8 April 2007 (UTC)
 * SB Johnny-LM 08:31, 22 March 2008 (UTC)
 * SB Johnny-LM 10:55, 4 April 2008 (UTC)
 * SB Johnny-LM 10:04, 9 April 2008 (UTC)

Recent Logs

 * Richardofoakshire 14:40, 6 March 2011 (UTC)
 * Richardofoakshire 12:37, 12 March 2011 (UTC)

title: BCP/Cornus mas/Logs


text:
Website administration

Website administration is the process of maintaining a website. This process is done by the website administrator. Website administrators are responsible for running the site after completion. Tasks in maintaining a functional website may include any of the following: 1. Installation, configuration, and maintenance for hosting and domain purposes 2. Preserving the integrity of data on the server 3. Managing administrator and user accounts/passwords 4. Supervising server security and firewalls

On user-generated content sites, it is recommended to inform your contributors and visitors in advance of major changes, especially a possible shutdown. Ideally, inform users through a site notice at least three months before a planned shutdown so they have appropriate time to save what they wish, and at least one week before making the site read-only. Consider releasing users' text contributions as a compressed archive, since text compresses efficiently. Also consider sending users who have provided an email address an export of their account data.

Course
System Administration

Links

 * Website information on wikipedia
 * Webmaster information on wikipedia

title: Website administration


text:
BCP/Scilla siberica/Logs

This page contains recent bloom logs for the plant Scilla siberica (Siberian Squill).

Recent Logs

 * SB Johnny-LM 08:47, 22 March 2008 (UTC)
 * SB Johnny-LM 11:31, 4 April 2008 (UTC)
 * --Luai lashire 00:58, 10 April 2008 (UTC)
 * --SB_Johnny | talk 19:11, 13 April 2008 (UTC)
 * --Luai lashire 22:03, 17 April 2008 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * SB Johnny-LM 13:22, 31 March 2007 (UTC)
 * --SB_Johnny | talk 10:31, 12 April 2007 (UTC)
 * SB Johnny-LM 09:35, 14 March 2008 (UTC)

title: BCP/Scilla siberica/Logs


text:
BCP/Amelanchier canadensis/Logs

2007 Logs

 * --SB_Johnny | talk 11:33, 26 April 2007 (UTC)
 * --SB_Johnny | talk 17:27, 29 April 2007 (UTC)

2008 Logs

 * --SB_Johnny | talk 12:17, 20 April 2008 (UTC)
 * --Luai lashire 22:00, 21 April 2008 (UTC)
 * --SB_Johnny | talk 10:18, 27 April 2008 (UTC)
 * --Luai lashire 22:00, 28 April 2008 (UTC)

Recent Logs

 * Jomegat 12:36, 10 May 2009 (UTC)

title: BCP/Amelanchier canadensis/Logs


text:
BCP/Ajuga reptans/Logs

2007 Logs

 * SB_Johnny-LM May 13 2007 (from photographs)
 * --SB_Johnny | talk 17:27, 23 May 2007 (UTC)
 * SBJ 09:18, 25 May 2007 (UTC)

2008 Logs

 * SBJ 11:36, 25 April 2008 (UTC)
 * SB_Johnny-LM 09:49, 2 May 2008 (UTC)

Recent Logs

 * --SB_Johnny | talk 09:38, 17 May 2008 (UTC)
 * --Turnvater Jahn 20:41, 21 May 2008 (UTC)
 * --SB_Johnny | talk 08:41, 27 May 2008 (UTC)

title: BCP/Ajuga reptans/Logs


text: Category:BCP/Basal leaves only

title: Category:BCP/Basal leaves only


text:
BCP/Sisyrinchium montanum/Logs

2007 Logs

 * --SB_Johnny | talk 00:32, 24 May 2007 (UTC)
 * --SB_Johnny | talk 10:21, 26 May 2007 (UTC)
 * --SB_Johnny | talk 23:49, 31 May 2007 (UTC)
 * --SB_Johnny | talk 10:47, 3 June 2007 (UTC)
 * --SB_Johnny | talk 15:33, 9 June 2007 (UTC)

2008 Logs

 * --SB_Johnny | talk 00:17, 7 May 2008 (UTC)
 * --SB_Johnny | talk 10:58, 27 May 2008 (UTC)
 * --Jomegat 04:35, 3 June 2008 (UTC)
 * --SB_Johnny | talk 11:25, 4 June 2008 (UTC)
 * --SB_Johnny | talk 12:39, 7 June 2008 (UTC)
 * --Jomegat 23:44, 9 June 2008 (UTC)
 * --Jomegat 20:49, 29 June 2008 (UTC)

2009 Logs

 * Jomegat 23:21, 20 May 2009 (UTC)
 * Jomegat 02:19, 1 June 2009 (UTC)
 * Jomegat 01:38, 6 June 2009 (UTC)
 * Jomegat 00:20, 9 June 2009 (UTC)

Recent Logs

 * Jomegat 00:33, 8 May 2010 (UTC)

title: BCP/Sisyrinchium montanum/Logs


text:
BCP/Cardamine hirsuta/Logs

2007 Logs

 * --SB_Johnny | talk 25 April 2007 (photographic log)
 * --SB_Johnny | talk 19:35, 7 January 2007 (UTC)
 * --SB_Johnny | talk 11:40, 15 January 2007 (UTC)
 * --SB_Johnny | talk 15:37, 24 March 2007 (UTC)
 * --SB_Johnny | talk 18:06, 27 March 2007 (UTC)
 * --SB_Johnny | talk 19:16, 8 April 2007 (UTC)
 * --SB_Johnny | talk 10:31, 12 April 2007 (UTC)

2008 Logs

 * --SB_Johnny | talk 10:41, 7 March 2008 (UTC)
 * SBJ 10:05, 21 March 2008 (UTC)
 * SB Johnny-LM 08:30, 22 March 2008 (UTC)
 * --SB_Johnny | talk 09:24, 22 March 2008 (UTC)
 * --SB_Johnny | talk 10:53, 4 April 2008 (UTC)
 * SB Johnny-LM 10:53, 4 April 2008 (UTC)
 * SBJ 14:31, 4 April 2008 (UTC)
 * SB Johnny-LM 00:00, 9 April 2008 (UTC)
 * --SB_Johnny | talk 11:09, 12 April 2008 (UTC)
 * SB Johnny-LM 16:33, 16 April 2008 (UTC)
 * SBJ 10:36, 26 April 2008 (UTC) (flower and ripe seed)

Recent Logs

 * --SB_Johnny talk 11:07, 5 December 2008 (UTC)
 * Sb f 20:47, 20 March 2009 (UTC)

title: BCP/Cardamine hirsuta/Logs


text: Category:Proofs

title: Category:Proofs


text:
BCP/Berberis thunbergii/Logs

This page contains recent bloom logs for the plant Berberis thunbergii (Japanese Barberry).

Recent Logs

 * SB_Johnny-LM 27 April, 2007 (from photographic log)
 * SBJ 12:05, 12 May 2007 (UTC)
 * SBJ 11:36, 25 April 2008 (UTC)
 * SB_Johnny-LM 10:31, 2 May 2008 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Berberis thunbergii/Logs


text: Category:BCP/Family/Berberidaceae

title: Category:BCP/Family/Berberidaceae


text:
BCP/Berberis x gladwinensis/Logs

This page contains recent bloom logs for the plant Berberis x gladwinensis (William Penn Barberry).

Recent Logs

 * --SB_Johnny | talk 23:17, 20 May 2007 (UTC)
 * --SB_Johnny | talk 17:37, 3 May 2008 (UTC)
 * --SB_Johnny | talk 09:43, 17 May 2008 (UTC)
 * --SB_Johnny | talk 09:05, 27 May 2008 (UTC)

=====Archived Logs===== (If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Berberis x gladwinensis/Logs


text: Category:Finnish

title: Category:Finnish


text:
BCP/Tagetes erecta/Logs

2008 Logs

 * (no archived logs yet)

Recent Logs

 * SB Johnny-LM 19:59, 8 June 2007 (UTC)
 * --SB_Johnny | talk 08:39, 10 July 2007 (UTC)
 * --SB_Johnny | talk 10:24, 5 September 2007 (UTC)
 * --SB_Johnny | talk 10:39, 21 September 2007 (UTC)
 * --SB_Johnny | talk 11:32, 8 June 2008 (UTC)
 * --SB_Johnny | talk 10:07, 20 July 2008 (UTC)
 * --SB_Johnny talk 12:29, 9 August 2008 (UTC)

title: BCP/Tagetes erecta/Logs


text:
BCP/Prunus persica/Logs

This page contains recent bloom logs for the plant Prunus persica (Peach).

Recent Logs

 * --SB_Johnny | talk 11:33, 26 April 2007 (UTC)
 * --SB_Johnny | talk 17:27, 29 April 2007 (UTC)

Archived Logs
(If there are more than 5 signatures under the recent logs heading, move the oldest logs to under this heading (generally leave the 3 most recent).
 * (no archived logs yet)

title: BCP/Prunus persica/Logs


text:
BCP/Aster ericoides

Aster ericoides

title: BCP/Aster ericoides


text:
BCP/Aster ericoides/Logs

2007 Logs

 * --SB_Johnny | talk 13:47, 16 September 2007 (UTC)
 * --SB_Johnny | talk 13:59, 22 September 2007 (UTC)
 * --SB_Johnny | talk 07:27, 1 October 2007 (UTC)
 * SB Johnny-NHAMP 23:05, 8 October 2007 (UTC)
 * --SB_Johnny | talk 09:32, 10 October 2007 (UTC)
 * --SB_Johnny | talk 12:20, 24 October 2007 (UTC)
 * --SB_Johnny | talk 12:59, 1 November 2007 (UTC)

2008 Logs

 * (no archived logs yet)

Recent Logs

 * --SB_Johnny talk 09:18, 31 August 2008 (UTC)
 * --SB_Johnny talk 08:52, 24 September 2008 (UTC)
 * --SB_Johnny talk 12:08, 15 November 2008 (UTC)

title: BCP/Aster ericoides/Logs


text:
Technical writing/Specification

Requirements Evaluation Check-list
A requirements specification is never really done. It is an iterative document that reflects the plans and intentions of the development team. As those change, so must the specification change. It's a living record of what you are doing.

Still, you can check the quality of your communications. At every stage as you add, edit, or remove information ask yourself these kinds of questions:

 * 1) Does the requirement focus on what is required rather than a solution?
 * 2) Is the requirement easy to understand and difficult to misunderstand?
 * 3) Does the requirement contain simple, short, unambiguous statements?
 * 4) Is there an example illustrating the requirement? Is it needed?
 * 5) Is there a visual figure illustrating the requirement? Is it needed?
 * 6) Does the requirement contradict with any other requirement?
 * 7) Is the requirement complete (without requiring a reader to look for information elsewhere to understand the requirement)?
 * 8) Is each requirement uniquely identified?
 * 9) Can the requirement be tested?
 * 10) Can the requirement be traced to and from a business objective?
 * 11) Can the requirement be achieved with the given resources, time and technology?

There is a suggested check-list available for download and use at SSC San Diego Process Asset Library. You can also try NASA's Automated Requirements Measurementtool which is free for download and use.

Since the typical requirements specification has multiple authors, you'll find yourself editing what others have written. Similarly, you'll find others editing your words. This must be expected and encouraged.

At each phase, there should be a healthy back-and-forth between writers, managers, developers, architects, and the customers, each challenging and defining the requirements. As this process continues, the requirements become better understood. Out of scope requirements are identified and eliminated. All the stakeholders set priorities, so managers can break the work into phases. The design becomes clear, and only when the most important issues have all been answered should you begin the actual development phase.

"But we don't have time for requirements...."

If you try to build a house with no plans, just stacking bricks and hammering wood together, you're unlikely to succeed. Everyone knows you need plans first.

Some people begin coding before they understand the requirements. It's no wonder their software, like a house with no plans, crashes down.

How much time?
Experienced professionals spend between a quarter and a third of their time and effort on defining the requirements, planning, and design.

Incorrect from the instructor: Highly successful projects write test cases before they write code.

Corrected by Technical Writer: Highly successful projects include written test cases prior to coding.

Similarly, delivery, maintenance, and improvement of the software must be included in project planning from the beginning. When these crucial activities are left as an afterthought, the customer is rarely satisfied.

A rough guideline for successful projects:

 * 1/3 project initiation, analysis, planning, specification, design, user feedback

 * 1/3 development, testing, integration, documentation, user feedback

 * 1/3 delivery, training, maintenance, user feedback, improvement

Note: All projects vary, but those which short change the first third of the process to jump directly into development are at highest risk for failure no matter the size or complexity of the project.

Avoid this risk by focusing on user goals. Keep your users involved through the whole life cycle of your project.

It takes time and skill to do this work. It's not for junior personnel, since this type of work affects the fortunes of the whole company. Experienced business analysts, writers, designers, architects, and managers can spot problem areas. If there is ever a time to put your best people on the job, it's during the requirements analysis and design phases.

Focus on Meeting User Goals
{| cellspacing="0" cellpadding="0" style="margin:0em 0em 1em 0em; width:100%" User Goals, Functions, and Structures
 * style="width:100%; vertical-align:top; border:1px solid Gold; background-color:LightYellow;" |

 * User Goals Driven System Development Life Cycle

 * 1) Clarify and define User Goals, within their environment
 * 2) User Goals within environmental constraints are prioritized as Requirements
 * 3) Discover and describe Functions that meet the Requirements
 * 4) Detailed Specification of the Functions and user environment is the design for Structures
 * 5) Structures produce a Product
 * 6) Compare the Product against the User Goals

 * Repeat the lifecycle...

Small and frequent repetitions of this life cycle allow you to grow the system organically, building on previous successes and constantly ensuring that user goals are met.

Communicate with the Users
Look again at the major risk factors for all projects. The number one reason projects succeed or fail is user involvement.

It's a mistake to think of requirements specification as something you check off your list before starting the "real work". Teams that diligently gather requirements, then hide in the office to create the product (or worse, a prototype) will not be as successful at managing and meeting the user's expectations.

All the way through the development lifecycle, from initiation, through development, to improvement, you must keep close to your customers and welcome their involvement in mutually evolving the product to meet their goals.
 * }

The Development Life Cycle
How is an idea transformed into a tool that people can use?

It doesn't happen automatically. It takes people working together, pooling their specialist knowledge, sharing problems and solutions until they have reached their goals and introduce it to the world.

This development process repeats in so many areas of life. To build an office tower, first you have to have the idea, analyse and plan it, design it, actually build it with proper tools, open it to occupants, and maintain it. You think of what you have learned in building this structure, and how to do better next time. Stretching the analogy further, to paint you have to conceive an image, sketch, modify and design it, then paint it on the canvas (again, with the proper tools of course), frame and present it to a gallery, and follow it over its lifetime. You brood over the paintings you have created, planning how to improve your style.

In just about any endeavor where you build things, you'll find the same phases:

The Idea
 * 1) Initialization
 * 2) Analysis and Planning

Building the Idea
 * 1) Design
 * 2) Development
 * 3) Testing and Integration

Using the Idea
 * 1) Delivery
 * 2) Maintenance
 * 3) Improvement

In building software and systems, it's called the SDLC, Software (or) System Development Life Cycle.

Some formal methodologies have more or fewer "phases" or "steps" in their life cycles, but they all follow this same pattern.

Note from Technical Writer: Remove personification - "they"

Requirements are written in the first third of the Idea phase of life cycle, modified and tracked in the Building phase, and used as testing and acceptance criteria in the Building and Using phases. In addition, they provide the basis of user documentation and training, as well as the library of lessons learned for the next project.

Note from Technical Writer: Remove personification - "they"

The requirements are not separate from the design, tests, or user documentation. The requirements are the roots of all these other documents. Therefore it makes sense to keep requirements open, visible, and in constant flux.

Note from Technical Writer: Remove personification - "they"

The more they change and the more your users, developers, testers, and managers use them, the more likely you'll have a successful project.

The specific methodology you use is less important than simply reaching clear written agreement reflecting understanding between the developers and users.

Requirement Specification Patterns
There are hundreds of templates and dozens of methodologies each requiring more or less the same basic areas for specification.

 * 1) Functional Specifications tracked to User Goals
 * 2) Workflows and Dataflows
 * 3) User and System Environment Constraints & Limitations
 * 4) Data Structures, Elements, Interfaces, Inputs, Outputs
 * 5) Performance, Safety and Reliability
 * 6) Security/Privacy

The closer you understand your user goals, the more naturally you will tailor your requirements to your project.

Quality Red Flags
There are some red flags you should always watch out for:

 * Generalizations like "user friendly", "fast", or "24/7"
 * No description of inputs or outputs
 * Lots of long paragraphs
 * Structures without a clear link to functions and user goals

Specify Functions and Structures
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.

For each User Goal, you have derived a variety of required functions.

Write these functional requirements as testable imperative statements. For each test, describe the environment where the test takes place and the outcomes.

This generates the structures required to support the functions that meet the user goals.

List these structures and describe their parameters in testable statements.

 * IMPORTANT TIP: Use proper sentence structures and select words and phrases based on explicit definitions, not what the popular culture thinks they mean. Define your terminology early and often.

Note from Technical Writer: Improve Clarity

Keep it short

 * All your commands and prohibitions must be short.
 * Break long sentences and paragraphs into short commands and lists.
 * Use the active voice and present tense.
 * If a sentence has more than three punctuation marks, re-write it to make it easier to understand.

Use consistent terminology

 * Define all technical terms in a glossary or terminology database so there is no disagreement on meaning.
 * Don't use synonyms. Always use the same term for the same meaning.

Break it down

 * Chunk the information to the level developers will understand.
 * Sort the chunks into understandable groups using tables and lists.
 * A sentence with many commas, or words like or, and, but, and/or, contains lumps of requirements. It must be broken down further.

Testability
User goals have to be tested against the functionality of the system. It's how the user knows they're getting what they're paying for. This is where most projects seem to begin their documentation process, analyzing a system by its structure, trying to deduct the functionality, and guessing at the goals of hypothetical users.

That doesn't work very well. Your team will be trapped in a test, fix, test, fix pattern until the users give up or the team quits. Either way, it's the kind of project everyone hates. It doesn't have to be that way.

If a requirement isn't testable, it's not valid.

Develop your tests with your users wherever possible. Be sure to let them describe the actual environment where the product will be used. Listen again for their end goals, and make sure the system lets them achieve those goals without making them feel lost or dependent on experts.

You have to be able to derive a test for each user goal before the development begins. This allows you to both test the requirements, and give the developers concrete specifications of what is expected. In addition, if you follow common standards, you can create much of the content of the user guides, help files, test cases, and future maintenance and help desk reference.

The key is identifying not only the simplified user goals, but also the underlying cases where that goal can either be met or blocked.

This means that each goal has to be assigned to one or many tests. The tests validate different aspects of the goal.

For the user goal of keeping their information safe from outsiders, you'd get the following requirement.

This requirement leads to several obvious test cases.

Writing Clear Requirements
{| cellspacing="0" cellpadding="0" style="margin:0em 0em 1em 0em; width:100%" Remember your Reader
 * style="width:100%; vertical-align:top; border:1px solid Gold; background-color:LightYellow;" |

Writing Clearly

 * Target your writing to your reader.
 * Developers want exact, clear, organized prose, tables and diagrams with testable statements.
 * Testers want enough information to infer the test cases, but you don't have to write every possibility.
 * Avoid redundancy. State it once and then make references to that statement.

According to Donn Le Vie, Jr., a good requirements specification accomplishes four goals:

Shows you understand what the customer wants Chunk and sort the information Lead the Development Validate the delivery When you write requirements, you'll mostly be using imperatives. Imperatives express direct commands, requests, and prohibitions. In many circumstances, using the imperative mood may sound blunt or even rude, but in technical communications they are normal.
 * Requirements are the "customer's assurance" that you understand what needs to be done. You must therefore keep requirements up to date with the users. The purpose of the project is the users. By keeping them involved in your team, not just providing status reports but inviting them to contribute their time and ideas, you'll enjoy a much better outcome. Surprises must be avoided...never delay bad news, and your customers will trust you more.
 * Requirements break down into chunks and sort these chunks into logical gloms. These information chunks define the work, limit the scope, and orders the requirements in terms of priorities.
 * Requirements each have a unique identifier, usually a combination of letters and numbers, that allow you to add more information and decisions as you progress through the software development life cycle. Each requirement is the parent to a number of following designs, tests, and user interfaces. This is why successful projects devote at least a quarter of their total effort to defining requirements and planning.
 * Requirements allow you to know when you are done. By checking the product you have created against the requirements, you can validate that you have met or exceeded your customer's expectations.
 * }

Note from Technical Writer: Remove personification - "they"

Use
Using a consistent format may be boring, but it's accurate and saves you time and arguments over how to word things. Use the Subject + Auxiliary Verb + Main Verb + Object formula wherever possible.

Auxiliary Verbs

 * Must
 * Will

 * Use simple word order:

Subject + (strong command auxiliary) + Main Verb + Object.

The technical writer will write using proper grammar and tone.

Remember: Technical writers do not personify inanimate objects.

https://www.e-education.psu.edu/styleforstudents/c1_p15.html

"A related issue is the use of unintentional personification—i.e., assigning human traits to inanimate objects—in technical writing. In a phrase such as "when the drillstring feels the weight," the seemingly literal claim that an inanimate object such as a drillstring "feels" anything is clearly inaccurate. Similarly, a sentence such as "Boeing stock enjoyed a 2% increase today" could imply that stocks have emotions. Although such a sentence may well appear in the daily newspaper, its tone would not suit a technical paper. In technical writing, avoid unintentional personification, which is always revealed by the verb you use to express a noun’s action."

Avoid

 * Weak suggestions are optional, and not a contractual part of the system requirements specification.

 * Generalities have no place in a requirement specification. If it cannot be measured or tested, it must be restated.

 * The word shall might mean must, may, should or can, depending on who is using it. It is therefore best avoided entirely.

{| cellspacing="0" cellpadding="0" style="margin:0em 0em 1em 0em; width:100%" Be Strong and Clear
 * style="width:100%; vertical-align:top; border:1px solid Gold; background-color:LightYellow;" |

Shall, Must, Will, Should
Here is the NASA terminology recommendation for writing clear requirements:

 * Shall is usually used to dictate the provision of a functional capability.
 * Must or must not is most often used to establish performance requirements or constraints.
 * Is required to is often used as an imperative in specifications statements written in the passive voice.
 * Are applicable is normally used to include, by reference, standards or other documentation as an addition to the requirements being specified.
 * Responsible for is frequently used as an imperative in requirements documents that are written for systems whose architectures are already defined. As an example, "The XYS function of the ABC subsystem is responsible for responding to PDQ inputs."
 * Will is generally used to cite things that the operational or development environment are to provide to the capability being specified. For example, "The building's electrical system will power the XYZ system."
 * Should is not frequently used as an imperative in requirement specification statements. However, when it is used, the specifications statement is always found to be very weak. For example, "Within reason, data files should have the same time span to facilitate ease of use and data comparison."

(emphasis added TWFred 07:34, 15 December 2007 (UTC))

In disagreement with NASA, the US Government's Plain Language group recommends against using the word shall entirely, as it is not clear to most readers what it means. There are hundreds of lawsuits that center around the meaning of shall.

Strong Commands
Commands give a direct order. You must eat all your food, is a command.

Note: The second person (you) is always implied, so Eat all your food has the same meaning.

Commands are the primary tool of requirements writers. They are strong and definitive.

Note from Technical Writer: Remove personification - "they"

Commands tell the developers what to make, and how to test it. Testing the commands against the deliverable is how customers check they have received what they paid for.

Strong commands follow a pattern:

 * Commands are short
 * Commands use active voice
 * Commands use strong verbs

Use these verbs:

Must

The strongest verb is Must. It leaves no room for doubt that what follows is a necessity.

Will

Use Will for a statement of fact.

In many requirement specifications (particularly in software), the words shall and will have special meaning. Most requirement specifications use the word shall to denote a requirement. The word will is reserved for a statement of fact. However, some documents deviate from this convention and use the words shall, will, and should to denote the strength of the requirement. Well-written requirement specifications define these words near the beginning of the document.

For example, on standards published by IEC (International Electrotechnical Commission), ASTM (American Society for Testing and Materials), IEEE (Institute of Electrical and Electronics Engineers), requirements with "shall" are the mandatory requirements, meaning "must", or "have to". The IETF (Internet Engineering Task Force) defines shall and must as synonymous terms denoting absolute requirements, and should as denoting a somewhat flexible requirement, in Request for Comments (RFC) documents.

(See: Shall and will and RFC 2119)

Strong Prohibitions
You cannot stop at describing only what the user wants. You must also describe what the user wishes to avoid. This is especially true for safety warnings, loss of data, security considerations and other environmental factors.

Strong Prohibitions

 * Shall not
 * Must not
 * Cannot
 * May not
 * Do not

IMPORTANT: In the command form, Can and May are weak, but used as a prohibition, Cannot and May not are strong.

 * You may not put needles in your ears.
 * The system cannot delete any files.

Be sure to use X must not rather than No X must. The second does not actually prohibit anything, instead merely stating X isn't required to do something, but still could.
 * }

{| cellspacing="0" cellpadding="0" style="margin:0em 0em 1em 0em; width:100%" Get Rid of Weak Suggestions and Useless Generalities
 * style="width:100%; vertical-align:top; border:1px solid Gold; background-color:LightPink;" |

Weak Suggestions
Weak Suggestions don't belong in a requirement specification. Suggestions and requests, in the pressure of developing a working system on time and on budget, will probably be ignored or badly implemented. Rewrite them in strong requirement language, or eliminate them.

Avoid using

 * Should
 * May
 * Can

You will often find that weak suggestions are out of scope, or have not been analyzed. Either way, exclude them from specifications until they are clearly required and well understood.

Useless Generalities

 * How tall is high?
 * How little is small?
 * How big is large?

This is the kind of discussion you will find yourself having with developers and testers if you include ambiguous terms in your requirements. Generalities must be avoided wherever possible and replaced with specific measurable reference points.

How you convert a generality into a specification depends on the context. Here are some examples:

 * Too general: Enough memory for the users.

 * Clear: The system must provide 20gb of free hard drive space for each user.

 * Too general: The system shall shut down quickly.

 * Clear: The complete power down sequence shall last no more than five (5) seconds.
 * }

Traceability
With time, requirements will usually change.

Customers change their minds. The market changes and demands additional requirements. Developers find new solutions that impact the rest of the system.

Attempting to set the requirements in stone is impossible. Instead, you define the requirements as clearly as you can, and anticipate they will evolve over the life cycle of the project.

By assigning a unique identifier to every requirement, you can control this inevitable process.

Unique Identifiers and Tracking Changes
There are many ways to label and number requirements. As long as you allow for the system to expand, use whatever is reasonable for your audience.

For example, if we create requirements for a pocket calculator we could immediately find the following types of requirements:

 * Size
 * Math Functions
 * User Interface
 * Power

Each of these types of requirements contains many sub-requirements, so you can put them into a table:

Calculator Size Requirements (1st draft)

Over time, though, you discover new requirements and add them to the end of the list. Where it makes sense, you can also add requirements in the middle of your list:

Calculator Size Requirements (with new items)

What is important is to construct your Unique Identifiers so that you can add more items. In this example, each UniqueID has an interval of ten so nine additional requirements can be inserted anywhere in the list. Of course you can also add items to the end of the list.

Remember: DO NOT re-number your Unique Identifiers. Once an item has an identifier, don't change it. (For this reason, you cannot use your word processor's auto-numbering tools.)

Use Strong Words and Phrases

 * Use the most simple words appropriate to the intent of the statement.
 * Use imperatives correctly and be consistent. Remember, "must" prescribes, "will" describes, "must" and "must not" constrain, and "should" suggests.
 * Avoid weak phrases such as "at a minimum", "be able to", "capable of", and "not limited to".
 * Do not use words or terms that give the provider an option on the extent that the requirement is to be satisfied such as "may", "if required", "as appropriate", or "if practical".
 * Do not use generalities where numbers are really required such as "large", "rapid", "many", "timely", "most", or "close".
 * Avoid fuzzy words that have relative meanings such as "easy", "normal", "adequate", or "effective".

Provide Examples

 * Immediately follow what is to be illustrated with the example.
 * Repeat an example if it is not already located on the same page. It's better to be repetitive than to divert the reader's attention.
 * Ensure that the example is not mistaken as part of the specification by the use of italics, quotes, or being explicit. For example: "This is an example."

Use References and Standards

 * Identify all external documents in the section of the Software Requirements Specification (SRS) designated for that purpose by the appropriate Data Item Description (DID). For DI-IPSC-81433 and NASA DID-P200 its Section 2.
 * Identify each reference cited with a unique number or identifier, such as "2.14".
 * Cite references by short or common title, full title, version or release designator, date, publisher or source, and document number or other unique document identifier. For example: "2.14 NASA Software Management, Assurance, and Engineering Policy, NMI 2410.10, March 26, 1991."
 * Use the unique citation identifier when referencing information in the cited document. For example: " as defined by Section 3 of reference document 2.14."

Use Tables, Diagrams, and Lists

 * Title and Identify each table and chart by a unique identifier.
 * List each table and chart in the SRS's table of contents by title, unique identifier and page number. Help the reader find it!
 * Identify the purpose of the table or chart in the text immediately preceding it. No surprises!
 * Explain each aspect or element of the table or chart (columns, rows, symbols, blanks, etc.) from right to left then top to bottom. No puzzles!

Building and Maintaining Usable Requirements
A requirement is a singular information “chunk” of what a product or service should do or be. It is most commonly used in systems or software engineering. It identifies a necessary attribute, capability, characteristic, or quality that must be of value and utility to the end user. Requirements show what structures and functions are necessary for the particular project.

Well written and planned requirements are essential to the successful development of every project. The format doesn't matter so much as the fact that the requirements are:

 * 1) Unambiguous
 * 2) Trackable
 * 3) Updatable

Requirements are typically placed into these categories:

 * Functional requirements describe the functions that the system must execute;
 * Structural requirements constrain or support the solution. Structural requirements are sometimes known as constraints, quality, or even, "non-functional" requirements. They can denote something about the system itself, and how well it performs its functions. Examples of such requirements include availability, testability, maintainability, and ease-of-use. Note from Technical Writer: Remove personification - "they"

Often 'business need' and 'feature' are spoken of as types of requirements. Each functional requirement should be traceable up to system feature and business need. In this workshop we use the term User Goal.

The continuing requirements process has three repeating activities:

 * Elicitation – the developer must validate the end user’s requirements for the project by showing progress, asking questions, and drawing out additional detail.
 * Analysis – the requirements must be evaluated for accuracy, completeness and reachability by discussion between the developers, managers, and the end user.
 * Recording – the requirements must be recorded flexibly, leaving room for additions and revisions. Use an open numbering/ID system for this.

Read more about NASA requirement recommendations)

In the real world, a working requirement specification never stops being edited and updated. It's not an artifact, but a workspace where users, designers, developers, and managers can share their ideas and come to agreement.

For requirement specifications to be useful, they must be used, and then tested.

Note from Technical Writer: Remove personification - "they"

{| cellspacing="0" cellpadding="0" style="margin:0em 0em 1em 0em; width:100%" Maintaining Good Requirements
 * style="width:100%; vertical-align:top; border:1px solid Gold; background-color:LightYellow;" |

Characteristics of good requirements
Good requirements are:

 * 1) Necessary – Something that must be included.
 * 2) Unambiguous – Use strong words without vague terms.
 * 3) Concise – Easy to read yet conveys the essence of what is required.
 * 4) Consistent – Does not contradict other requirements. Contains a terminology list for key words.
 * 5) Complete –Does not require you to look at additional text to know what the requirement means.
 * 6) Achievable – A realistic requirement that can be implemented with the available resources, and time.
 * 7) Verifiable – Can be verified by test, inspection, review, analysis, simulation or demonstration.
 * 8) Traceable - Has a unique identifier and is tracked through the entire SDLC.

Record all requirements which are necessary even if you think they are "common sense".

Note from Technical Writer: Remove personification - "they"

Your requirements specification document must have a clear structure. Your customers, developers, and testers should all be able to find what they're looking for within thirty seconds.

The requirements specification is a project deliverable whether or not it is required by a customer. Like any project deliverable, it must be verified. Ask your colleagues to review it. It's a good practice to have software architects, test engineers, domain experts, and customers review your specifications and provide feedback early and often.

The most important aspect of requirements specifications is that they are USED AND TESTED THROUGH THE WHOLE LIFE CYCLE. Note from Technical Writer: Remove personification - "they"
 * }

Learn More…

 * Requirements — Wikipedia
 * Requirements Analysis — Wikipedia
 * Capability Maturity Model — Wikipedia
 * Software development lifecycle
 * Writing Software Requirements Specifications — TechWR-L: Empowering Technical Writers Since 1993
 * Writing Effective Requirements Specifications — NASA
 * Requirements: An introduction — IBM
 * Writing good requirements is a lot like writing good code — IBM
 * Painless Functional Specifications - Part 4: Tips — Joel on Software
 * Writing Quality Requirements
 * Manage and Trace Requirements (Available via Web Archive, while site is unavailable)
 * Defense Standard — Wikipedia
 * Software performance testing — Wikipedia
 * Software verification — Wikipedia

Links to Templates and Examples
Using a template saves you time and helps you to organize your work. If your organization already uses a template, so should you. If your organization doesn't have a template, you can download and adopt a free template according to your needs.

Using a template should not restrict you. Consider template as a guideline and adopt it according to project needs.

Read the very short RFC 2119 for a good definition of key words in writing requirements.

Requirements Examples

 * Axia-Consulting Human Resources Example
 * XML Services (XS) functional area of the Defense Information Infrastructure (DII) Common Operating Environment (COE)
 * Military standard documentation
 * Ken Rigby's DI-IPSC-81433 Software Requirements Specification

Free Template Downloads
The following links contain templates that when last checked are free to use and modify:

 * Project Connections has some free templates as well as a paid subscription option.
 * Process Impact Templates with a suggested donation to Norm Kerth
 * A Canadian Government Template that is very flexible.
 * A Template from the Texan Project Delivery Framework

Example: Asimov's Three Laws of Robotics

 * 1) A robot may not injure a human being or, through inaction, allow a human being to come to harm.
 * 2) A robot must obey orders given to it by human beings except where such orders would conflict with the First Law.
 * 3) A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Discussion Questions

 * 1) How does Asimov identify a strong commands?
 * 2) How does Asimov identify a strong prohibitions?
 * 3) How would you break these laws down into smaller requirements?
 * 4) How would you test these requirements?
 * 5) Are there any unclear terms that you can further define?
 * 6) What other "Laws of Robotics" would you add?

title: Technical writing/Specification


text:
User talk:Hanna.ishutsina

Welcome
Hello Hanna.ishutsina, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; for it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other wikiversiters on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! --JWSchmidt 13:37, 21 September 2007 (UTC)

title: User talk:Hanna.ishutsina


text:
User talk:Immortal~enwikiversity

Welcome
Hello Immortal, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; for it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other wikiversiters on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! Erkan Yilmaz ( evaluate me!, discussion ) 15:11, 21 September 2007 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Immortal. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Immortal~enwikiversity that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:33, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 06:11, 19 April 2015 (UTC)

title: User talk:Immortal~enwikiversity


text:
User talk:Kneiterd

Welcome
Hello Kneiterd, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; for it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other wikiversiters on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! Erkan Yilmaz ( evaluate me!, discussion ) 15:12, 21 September 2007 (UTC)

title: User talk:Kneiterd


text:
User talk:AboutVirtues

Welcome
Hello AboutVirtues, and welcome to Wikiversity! If you need help, feel free to visit my talk page, or contact us and ask questions. After you leave a comment on a talk page, remember to sign and date; for it helps everyone follow the threads of the discussion. The signature icon in the edit window makes it simple. To get started, you may
 * Take a guided tour and learn to edit;
 * Explore our learning projects;
 * Browse our portals, schools, and research activities;
 * Read and help develop our community policies；or
 * Chat with other wikiversiters on #wikiversity-en.

And don't forget to explore Wikiversity with the links to your left. Be bold, and see you around Wikiversity! Erkan Yilmaz ( evaluate me!, discussion ) 15:54, 21 September 2007 (UTC)

title: User talk:AboutVirtues