Style Guide creation and various edits to the Tutorial and Reference Sections. Signed-off-by: Maha Jastram <maha@jastram.de>
diff --git a/org.eclipse.rmf.documentation/rmf-images/views.png b/org.eclipse.rmf.documentation/rmf-images/views.png new file mode 100644 index 0000000..cdbe1df --- /dev/null +++ b/org.eclipse.rmf.documentation/rmf-images/views.png Binary files differ
diff --git a/org.eclipse.rmf.documentation/rmf-images/views_highlighted.png b/org.eclipse.rmf.documentation/rmf-images/views_highlighted.png new file mode 100644 index 0000000..586dd3a --- /dev/null +++ b/org.eclipse.rmf.documentation/rmf-images/views_highlighted.png Binary files differ
diff --git a/org.eclipse.rmf.documentation/rmf-latex/introduction.tex b/org.eclipse.rmf.documentation/rmf-latex/introduction.tex index 62b9d68..18df933 100644 --- a/org.eclipse.rmf.documentation/rmf-latex/introduction.tex +++ b/org.eclipse.rmf.documentation/rmf-latex/introduction.tex
@@ -26,7 +26,7 @@ \section{Contributing} -Documentation is one of those things that gets easily neglected in open source projects. It is also one of the easiest for outsiders to contribute to. The documentation is managed as Latex, which may scare some people. But no worries, those who don't want to learn Latex don't have to. +Documentation is one of those things that gets easily neglected in open source projects. It is also one of the easiest for outsiders to contribute to. The documentation is managed as \LaTeX, which may scare some people. But no worries, those who don't want to learn \LaTeX don't have to. There are broadly two ways for contributing to the documentation:
diff --git a/org.eclipse.rmf.documentation/rmf-latex/main.tex b/org.eclipse.rmf.documentation/rmf-latex/main.tex index 62102c5..6cea694 100644 --- a/org.eclipse.rmf.documentation/rmf-latex/main.tex +++ b/org.eclipse.rmf.documentation/rmf-latex/main.tex
@@ -5,7 +5,7 @@ \usepackage{xcolor} \usepackage[utf8]{inputenc} \usepackage{soul} - +\usepackage{wrapfig} %---------------------------------------------------------------------------------------- % MACROS %---------------------------------------------------------------------------------------- @@ -63,5 +63,8 @@ \chapter{Glossary} \input{glossary} +\chapter{Style Guide} +\input{style_guide} + \end{document}
diff --git a/org.eclipse.rmf.documentation/rmf-latex/reference.tex b/org.eclipse.rmf.documentation/rmf-latex/reference.tex index e49fd1c..40ce5ad 100644 --- a/org.eclipse.rmf.documentation/rmf-latex/reference.tex +++ b/org.eclipse.rmf.documentation/rmf-latex/reference.tex
@@ -1,20 +1,72 @@ -This is the reference manual for ProR. +We hope you find this reference manual useful. It's a work in progress and will be actively improved and expanded. \section{Editors} -Upon opening a ReqIF Model, the ReqIF Editor opens providing an overview of the model. In essence what you are seeing is the Eclipse Workbench, with several modifications. A detailed description of the Workbench can be found in Eclipse's Workbench User Guide. +\begin{wrapfigure}{l}{.3\linewidth} +\includegraphics[height=.9\textwidth]{../rmf-images/views_highlighted.png} +\caption[flushleft]{Views.} +\label{fig:Views} +\end{wrapfigure} -A model contains any number of specifications, and the details of each specification can be inspected individually. The windows in which all relevant information appears are called Views. + +Upon opening a ReqIF Model, the editor opens providing an overview of the model. In essence what you are seeing is the Eclipse Workbench, with several modifications. Here you will find a quick overview of each component. A more detailed description of the Workbench can be found in Eclipse's Workbench User Guide. + +A model contains any number of specifications, and the details of each specification can be inspected individually. The windows in which all relevant information appears are called Views. At your disposal are many Views with productivity, debugging, help and team resources. We will be focusing only on the Views relevant to ProR. +\clearpage +\newpage \subsection{ReqIF Overview Editor} +This figure was briefly described in the tutorial. Here we'll go deeper in depth. +\begin{figure}[h!] + \centering + \includegraphics[width=\linewidth]{../rmf-images/Screenshot_intro.png} + \caption{The \pror{} user interface} + \label{fig:user_interface_overview} +\end{figure} +(1) is the Project Explorer window. Here you will see a hierarchical listing of the project and the associated models. + +(2) The Editor shows you a hierarchical breakdown of the model. Each specification with it's associated SpecObjects is listed in a spreadsheet. Because the SpecObjects of each requirement can vary, not all fields will be completed. Because the fields need to be created and then associated with the SpecObjects, they may not all be (nor do they need to be) represented. But what appears and how they appear can be customized. + +In the Editor, you see the SpecObjects that exist in this Specification. +There is currently only one, with the description "Start editing here". + +The Outline (3) has four folders: + +\begin{itemize} + +\item + "Specifications" shows the Specifications in the ReqIF. You can + expand the tree to expose the hierarchy of SpecObjects in the + ReqIF model. +\item + "SpecObjects" shows all SpecObjects in the ReqIF model as a flat list. + Keep in mind that SpecObjects in Specifications are references. In + contrast, this folder shows all SpecObjects created for the ReqIF model, whether or not they are referenced. +\item + "SpecRelations" shows all SpecRelations in the ReqIF as a flat list. + For now, we will ignore SpecRelations. +\item + "SpecRelationsGroups" ***** I HAVE NO IDEA. SHALL WE IGNORE THIS, TOO? +\end{itemize} + +The properties of a selected Element are shown in the Properties view +(4). As the only Requirement in the model is selected, we see its +SpecObjectType ("Requirements Type") and its only Attribute +("Description") with the value "Start editing here.". There are two +tabs "Standard Attributes" and "All Attributes" at the bottom of the +Properties view. ***** The "Standard Attributes" tab shows you all standard +attributes of the selected element. The "All Attributes" shows all +existing ReqIF attributes of the selected element. + +Above the main working windows it the tool bar (5) and, at the very top, the menu bar (6). \subsection{Specification Editor} \section{Views} -By default, ProR's Workbench displays three views: +By default, ProR's Workbench displays the following three views: \subsection{Project Explorer View}\index{Project Explorer View} @@ -24,7 +76,6 @@ \section{Configurations} -While the windows are a Workbench feature, more information can be found in Eclipse's Workbench User Guide. The ProR menu contains entries to launch a number of configuration dialogs. @@ -54,7 +105,7 @@ As an example, consider the following Datatype Configuration Dialog: \begin{figure}[h!] -\centering +\centering \includegraphics[width=0.8\linewidth]{../rmf-images/pror_datatype_configuration.png} \caption{Datatype Configuration Dialog} \label{fig:DatatypeConfig}
diff --git a/org.eclipse.rmf.documentation/rmf-latex/style_guide.tex b/org.eclipse.rmf.documentation/rmf-latex/style_guide.tex new file mode 100644 index 0000000..ac1b4b0 --- /dev/null +++ b/org.eclipse.rmf.documentation/rmf-latex/style_guide.tex
@@ -0,0 +1,68 @@ +This simple guide is intended to explain the style used in this documentation. We request that you follow it as closely as possible when creating content in order to maintain a clear, concise and easy to read body of work. + +The documentation was created with and is maintained with \LaTeX. That stands to reason that much of the formatting is software-dependent, leaving us to worry about more important things. But that still leaves some decisions for us to make. For example, alphabetization, certain punctuation, spelling and hyphenation of certain words, and the like will be accounted for here. + + +\section{alphabetization} + +What should and should not be alphabetized: + +\begin{itemize} + +\item + General terms such as ``requirements'' or ``specifations'' not used in a ProR or Eclipse specific manner are written in lower-case. +\item + ProR- and Eclipse-specific terms shall be capitalized. i.e., terms such as ``Eclipse Workbench,'' ``SpecObject,'' ``Editor,'' and ``Views'' are capitalized. + +\end{itemize} + +\section{Punctuation} + +\begin{itemize} + +\item + \textbf{Mdashes} shall be used when needed—here is a perfect example—with no spaces. +\item + \textbf{Periods} will be followed by double-spaces. +\item + When \textbf{Colons} are used to introduce a series of numbered items in a list, do not capitalize the first item after the colon (unless it's a proper noun) and seperate the list items with semi-colons, e.g.: + There are three differences: (1) the first difference; (2) the second difference; and (3) the third difference. + +\end{itemize} + +********** + + +\section{Contributing} + +Documentation is one of those things that gets easily neglected in open source projects. It is also one of the easiest for outsiders to contribute to. The documentation is managed as Latex, which may scare some people. But no worries, those who don't want to learn Latex don't have to. + +There are broadly two ways for contributing to the documentation: + +\begin{description} + \item[File a bug.] Visit the \href{https://bugs.eclipse.org/bugs/enter_bug.cgi?assigned_to=&blocked=&bug_severity=normal&bug_status=NEW&comment=&contenttypeentry=&contenttypemethod=autodetect&data=&dependson=&description=&flag_type-1=X&flag_type-11=X&flag_type-12=X&flag_type-2=X&flag_type-4=X&flag_type-6=X&flag_type-7=X&flag_type-8=X&form_name=enter_bug&keywords=&&op_sys=All&product=MDT.RMF&qa_contact=&rep_platform=All&short_desc=&version=unspecified}{RMF Bug Tracker}. You can just point out a problem or request for improvement. You can also provide some text to be added to the documentation (unformatted). If you do, however, then you need to sign a Committer License Agreement (CLA) + \item[Submit improved \LaTeX via Gerrit.] If you are technically inclined (meaning that you know what \LaTeX and git are, and how to use them), then you can contribute via the Gerrit code review system, as described \href{https://wiki.eclipse.org/Gerrit}{at eclipse.org}. +\end{description} + +\subsection{Gerrit for Contributions} + +TODO - when done, update the parent section as well. + +\section{Licensed as EPL} + +This work is licensed under the Eclipse Public License. + +\section{Acknowledgements} + +Many parties were involved in the creation of RMF. We would like to thank the core team that made it possible. + +\begin{figure}[H] + \centering + \includegraphics[width=\textwidth]{../rmf-images/2012_03_sprint_team.jpg} + \caption{The RMF team during a Sprint in April 2012 in Düsseldorf, Germany + (left to right) Lukas Ladenberger, Mark Brörkens, Ingo Weigelt, Said Salem, Michael Jastram} + \label{fig:intro_core_team} +\end{figure} + + +The roots of this project were created by Andreas Graf, Michael Jastram and Nirmal Sasidharan, who joined together individual projects to create RMF. Their efforts were financed by the research projects itea Verde and FP7 Deploy. RMF was assembled at the Eclipse Foundation, where it has been active ever since. Figure~\ref{fig:intro_core_team} shows four of the five RMF Committers at a joint coding session (missing is Andreas Graf).
diff --git a/org.eclipse.rmf.documentation/rmf-latex/tutorial.tex b/org.eclipse.rmf.documentation/rmf-latex/tutorial.tex index 3b19514..e049d14 100644 --- a/org.eclipse.rmf.documentation/rmf-latex/tutorial.tex +++ b/org.eclipse.rmf.documentation/rmf-latex/tutorial.tex
@@ -7,38 +7,19 @@ The following compares the concept of a spreadsheet with a ReqIF model and differentiates between the terminology: \begin{description} - \item[Specification.\index{Specification}] (Excel-equivalent: Sheet) A ReqIF model -consists of an arbitrary number of specifications. The specification is -the "container" for the requirement. Think of an Excel document that -allows you to create an arbitrary number of sheets. Each sheet can be compared to a single specification. There are two differences: (1) The specifications are references rather than independant entities (which means that the same requirement can appear in multiple places); (2) The contents of the specification appear in a list, hierarchically. + \item[Specification.\index{Specification}] (Excel-equivalent: Sheet) A ReqIF model consists of an arbitrary number of specifications. The specification is the "container" for the requirement. Think of an Excel document that allows you to create an arbitrary number of sheets. Each sheet can be compared to a single specification. There are two differences: (1) the specifications are references rather than independant entities (which means that the same requirement can appear in multiple places); (2) the contents of the specification appear in a list, hierarchically. - \item[SpecObject.\index{SpecObject}] (Excel-equivalent: Row) A SpecObject represents the actual -requirement. A requirement typically has a number of attributes. Again -compared to Excel, each row in a sheet represents a requirement. In -contrast to Excel, the ReqIF model may contain SpecObjects that do not -appear in any specification. + \item[SpecObject.\index{SpecObject}] (Excel-equivalent: Row) A SpecObject represents the actual requirement. A requirement typically has a number of attributes. Again compared to Excel, each row in a sheet represents a requirement. In contrast to Excel, the ReqIF model may contain SpecObjects that do not appear in any specification. - \item[Attribute.\index{Attribute}] (Excel-equivalent: Cell) In the columns are the attributes. -Besides the actual text of the requirement, typical attributes include ID, status, etc. -Note that there are no "standard" attributes. The ReqIF model contains the definitions -of the attributes. Here the Excel analogy starts to breakdown. In -Excel, by default, each row has the same columns. Different SpecObjects may have -different sets of attributes. + \item[Attribute.\index{Attribute}] (Excel-equivalent: Cell) In the columns are the attributes. Besides the actual text of the requirement, typical attributes include ID, status, etc. Note that there are no "standard" attributes. The ReqIF model contains the definitions of the attributes. Here the Excel analogy starts to breakdown. In Excel, by default, each row has the same columns. Different SpecObjects may have different sets of attributes. - \item[SpecType.\index{SpecType}] (Excel-equivalent: Column configuration) Each SpecObject -has a SpecObjectType. The SpecObjectType contains a list of attributes -for the SpecObject. For instance, the SpecObjectType "Headline" may -have only one attribute "HeadlineText". Another SpecObjectType -"Requirement" may have three attributes, "ID", "Description" and -"Status". A specification may then contain a mixture of SpecObjects -with different types. + \item[SpecType.\index{SpecType}] (Excel-equivalent: Column configuration) Each SpecObject has a SpecObjectType. The SpecObjectType contains a list of attributes for the SpecObject. For instance, the SpecObjectType "Headline" may have only one attribute "HeadlineText". Another SpecObjectType "Requirement" may have three attributes, "ID", "Description" and "Status". A specification may then contain a mixture of SpecObjects with different types. \end{description} There are many more concepts, but this is enough to get us started. -Let's look at a concrete example to understand this. Here is a snippet -of a Specification: +Let's look at a concrete example to understand this. Here is a snippet of a Specification: \begin{figure}[H] \centering @@ -47,15 +28,12 @@ \label{fig:spec_example} \end{figure} -The table shows the first four SpecObjects, as visualized in a -Specification. The tree-like structure is recognizable: INF-1 is a node -with three children, REQ-1, REQ-2 and REQ-3 (this can be seen by the -indentation). Let's look at INF-1 and REQ-1. When one is selectedin the main pain, it's attributes appear in the properties pane below. +The table shows the first four SpecObjects, as visualized in a specification. The tree-like structure is recognizable: INF-1 is a node +with three children, REQ-1, REQ-2 and REQ-3 (this can be seen by the indentation). Let's look at INF-1 and REQ-1. When one is selectedin the main pain, it's attributes appear in the properties pane below. INF-1 has two attributes, "Description" and "ID". The SpecObjectType is "Information Type" (shown as the root in the properties view). -REQ-1, REQ-2, and REQ-3 have three attributes, "Description", "ID" and "Status". The -SpecObjectType is called "Requirements Type". Let's look closer at the SpecObjectType. +REQ-1, REQ-2, and REQ-3 have three attributes, "Description", "ID" and "Status". The SpecObjectType is called "Requirements Type". Let's look closer at the SpecObjectType. \begin{figure}[H] \centering @@ -64,21 +42,11 @@ \label{fig:spec_example} \end{figure} -The "Requirements Type" SpecObjectType is shown in the picture, with -arrows indicating how the Attributes relate to the SpecObjectType (a -simple one-to-one relationship). A SpecObjectType has one entry for each -Attribute, consisting of a name and a Datatype. For instance, the first -entry has the name "ID" and the datatype "T\_ID\_REQ". Note that -multiple Attributes may have the same Datatype: "Description" and -"Status" both have the Datatype "T\_String32k". +The "Requirements Type" SpecObjectType is shown in the picture, with arrows indicating how the Attributes relate to the SpecObjectType (a simple one-to-one relationship). A SpecObjectType has one entry for each Attribute, consisting of a name and a Datatype. For instance, the first entry has the name "ID" and the datatype "T\_ID\_REQ". Note that multiple Attributes may have the same Datatype: "Description" and "Status" both have the Datatype "T\_String32k". -Last, The Datatypes must be defined as well. In this example, there are -two Datatypes, "T\_String32" and "T\_ID\_REQ". These are finally -based on a number of standard types that ReqIF supports. +Last, The Datatypes must be defined as well. In this example, there are two Datatypes, "T\_String32" and "T\_ID\_REQ". These are finally based on a number of standard types that ReqIF supports. -NOTE: As of this writing, we only implemented the simple and the -enumeration ReqIF types. This leaves out the complex ones (rich text, -attachments, embedded files, etc.) for now. +NOTE: As of this writing, we only implemented the simple and the enumeration ReqIF types. This leaves out the complex ones (rich text, attachments, embedded files, etc.) for now. \section{Tutorial 1: Creating a basic ReqIF Model} @@ -86,13 +54,7 @@ \subsection{Install \pror{}} -You can download \pror{} from the -\href{https://www.eclipse.org/rmf/download.php}{Download page}. -Alternatively, you can install \pror{} in any Eclipse-Installation via its -update site (also listed on the -\href{https://www.eclipse.org/rmf/download.php}{Download page}). Using -the update site allows you to use the Eclipse Update mechanism, -something that is currently not yet enabled for the standalone version. +You can download \pror{} from the \href{https://www.eclipse.org/rmf/download.php}{Download page}. Alternatively, you can install \pror{} in any Eclipse-Installation via its update site (also listed on the \href{https://www.eclipse.org/rmf/download.php}{Download page}). Using the update site allows you to use the Eclipse Update mechanism, something that is currently not yet enabled for the standalone version. \subsection{Create the Model} @@ -122,36 +84,23 @@ The Editor (2) shows your Specifications. -In the Editor, you see the SpecObjects that exist in this Specification. -There is currently only one, with the description "Start editing here". +In the Editor, you see the SpecObjects that exist in this Specification. There is currently only one, with the description "Start editing here". The Outline (3) has four folders: \begin{itemize} \item - "Specifications" shows the Specifications in the ReqIF. You can - expand the tree to expose the hierarchy of SpecObjects in the - ReqIF model. + "Specifications" shows the Specifications in the ReqIF. You can expand the tree to expose the hierarchy of SpecObjects in the ReqIF model. \item - "SpecObjects" shows all SpecObjects in the ReqIF model as a flat list. - Keep in mind that SpecObjects in Specifications are references. In - contrast, this folder shows all SpecObjects created for the ReqIF model, whether or not they are referenced. + "SpecObjects" shows all SpecObjects in the ReqIF model as a flat list. Keep in mind that SpecObjects in Specifications are references. In contrast, this folder shows all SpecObjects created for the ReqIF model, whether or not they are referenced. \item - "SpecRelations" shows all SpecRelations in the ReqIF as a flat list. - For now, we will ignore SpecRelations. + "SpecRelations" shows all SpecRelations in the ReqIF as a flat list. For now, we will ignore SpecRelations. \item "SpecRelationsGroups" ***** I HAVE NO IDEA. SHALL WE IGNORE THIS, TOO? \end{itemize} -The properties of a selected Element are shown in the Properties view -(4). As the only Requirement in the model is selected, we see its -SpecObjectType ("Requirements Type") and its only Attribute -("Description") with the value "Start editing here.". There are two -tabs "Standard Attributes" and "All Attributes" at the bottom of the -Properties view. ***** The "Standard Attributes" tab shows you all standard -attributes of the selected element. The "All Attributes" shows all -existing ReqIF attributes of the selected element. +The properties of a selected Element are shown in the Properties view (4). As the only Requirement in the model is selected, we see its SpecObjectType ("Requirements Type") and its only Attribute ("Description") with the value "Start editing here.". There are two tabs "Standard Attributes" and "All Attributes" at the bottom of the Properties view. ***** The "Standard Attributes" tab shows you all standard attributes of the selected element. The "All Attributes" shows all existing ReqIF attributes of the selected element. Above the main working windows it the tool bar (5) and, at the very top, the menu bar (6). @@ -162,26 +111,18 @@ \begin{itemize} \item - Add two more attributes to the SpecObjectType called "ID" and - "Owner" and + Add two more attributes to the SpecObjectType called "ID" and "Owner" and \item We will show those Attributes in the Specification \end{itemize} -To add new attributes, we open the Datatype Configuration dialog with -\pror{} \textgreater{} Datatype Configuration. Alternatively you can also click on the ``T'' in the Tool Bar. +To add new attributes, we open the Datatype Configuration dialog with \pror{} \textgreater{} Datatype Configuration. Alternatively you can also click on the ``T'' in the Tool Bar. -The resulting dialog box has two folders in the upper pane: one for SpecTypes and one for Datatypes. -Currently, there is only one Datatype (T\_String32k) and two SpecTypes, -one called "Requirements Type" with one attribute "Description" and -one called "Specification Type" with one attribute "Description". +The resulting dialog box has two folders in the upper pane: one for SpecTypes and one for Datatypes. Currently, there is only one Datatype (T\_String32k) and two SpecTypes, one called "Requirements Type" with one attribute "Description" and one called "Specification Type" with one attribute "Description". In the lower pane are the details in regards to each attribute. -We add more Attributes to "Requirements Type" by right-clicking -"Requirements Type" and selecting "New Child \textgreater{} Attribute -Definition String". This will create a new element. Upon selecting, we -can rename it and tailor the details. Double-click on the ``Long Name'' variable and type in ``ID''. Change the Type by double-clicking the field and choosing ``T\_String32k'' from the drop-down menu. Repeat the process but this time change the ``Long Name'' to "Owner". In the end, the dialog should look as follows +We add more Attributes to "Requirements Type" by right-clicking "Requirements Type" and selecting "New Child \textgreater{} Attribute Definition String". This will create a new element. Upon selecting, we can rename it and tailor the details. Double-click on the ``Long Name'' variable and type in ``ID''. Change the Type by double-clicking the field and choosing ``T\_String32k'' from the drop-down menu. Repeat the process but this time change the ``Long Name'' to "Owner". In the end, the dialog should look as follows \begin{figure}[h!] \centering @@ -190,23 +131,15 @@ \label{fig:datatype_configuration} \end{figure} -Upon closing the dialog, little will have changed - the Specification -still shows just two columns, Description and Link. However, if you -select the requirement, you will see the new Properties (ID and Owner) -in the Property view. +Upon closing the dialog, little will have changed - the Specification still shows just two columns, Description and Link. However, if you select the requirement, you will see the new Properties (ID and Owner) in the Property view. \subsection{Showing the new Attributes in the Specification} -To show the new Attributes in the Specification, we have to configure -the Specification columns. We do this by selecting \pror{} \textgreater{} -Column Configuration. You can also click on the spreadsheet icon in the Tool Bar. +To show the new Attributes in the Specification, we have to configure the Specification columns. We do this by selecting \pror{} \textgreater{} Column Configuration. You can also click on the spreadsheet icon in the Tool Bar. -The resulting Dialog shows one entry, ``Description'' for the one and only Column of the -Specification. In the ``Value'' column double click on ``Description to choose it and replace it with ``ID''. +The resulting Dialog shows one entry, ``Description'' for the one and only Column of the Specification. In the ``Value'' column double click on ``Description to choose it and replace it with ``ID''. -By clicking on the "Add Column" icon at the top of the -dialog, create a new column and name it ``Description''. In this view, the columns can be dragged and dropped -to change their order as desired. +By clicking on the "Add Column" icon at the top of the dialog, create a new column and name it ``Description''. In this view, the columns can be dragged and dropped to change their order as desired. The resulting window should look like this: @@ -217,32 +150,17 @@ \label{fig:column_configuration} \end{figure} -Note that you have to provide free text for the columns for the same -reason that we used free text for the ``Labels'' earlier: This way we can -easily match multiple SpecObjects of different types. +Note that you have to provide free text for the columns for the same reason that we used free text for the ``Labels'' earlier: This way we can easily match multiple SpecObjects of different types. -You can actually adjust the width of the columns simply by dragging the -column headers. +You can actually adjust the width of the columns simply by dragging the column headers. \subsection{Adding new SpecObjects} -Now we can finally add SpecObjects by right-clicking on a row in the -Specification. In the context-menu, there are two submenus: "New -Child" and "New Sibling". "New Child" is the only way to produce a -hierarchical structure. +Now we can finally add SpecObjects by right-clicking on a row in the Specification. In the context-menu, there are two submenus: "New Child" and "New Sibling". "New Child" is the only way to produce a hierarchical structure. -In both menus, there are three entries "Spec Hierarchy", "Adding -SpecObjects" and "SpecObject (Requirement Type)". Some background is -needed here: +In both menus, there are three entries "Spec Hierarchy", "Adding SpecObjects" and "SpecObject (Requirement Type)". Some background is needed here: -We said before that Specifications contain references to SpecObjects. A -SpecHierarchy is the "Wrapper" that allows the hierarchical structure -and that points to the referred SpecObject. Usually, we don't have to be -concerned with them. Therefore the second option: If selected, a new -SpecHierarchy is created and associated with a new SpecObject, which in -turn is set immediately to the given SpecObjectType. If we had more than -just one SpecObjectType (besides "Requirements Type"), there would be -an entry for each type in the context menu. +We said before that Specifications contain references to SpecObjects. A SpecHierarchy is the "Wrapper" that allows the hierarchical structure and that points to the referred SpecObject. Usually, we don't have to be concerned with them. Therefore the second option: If selected, a new SpecHierarchy is created and associated with a new SpecObject, which in turn is set immediately to the given SpecObjectType. If we had more than just one SpecObjectType (besides "Requirements Type"), there would be an entry for each type in the context menu. To continue the exercise, select the child "SpecObject (Requirement Type)". Now we have two SpecObjects. The original is numbered on the far left-hand side of the pane with a 1. The second one, the child, is numbered 1.1. Now we should change the ID's of each entry. Click in the ``ID`` for number 1 and type in INF-1. Under Description, type ''A ProR tutorial``. For the second, change the ID to REQ-1 and ''Learn now to create a new requirement'' in the Description column.
