Setting Up ReqView Environment

Download and Install ReqView

You can download the ReqView installer for Windows, Mac, or Linux from the ReqView Download page. To install ReqView for your platform, follow the standard system install procedure:

• Install ReqView for Windows
• Install ReqView for Mac
• Install ReqView for Linux

Activate ReqView License

You can use ReqView with the following license plans: FREE, PRO, TEAM, or ENTERPRISE. For more information on which plan fits best to your needs, see Choose License Plan.

No worry, you can also follow this tutorial using a free evaluation TEAM license, see Request Free Trial License.

To activate ReqView PRO or TEAM license, run ReqView, select Help->Activate License, and choose the license file you received by email. If you need more help, see Activate License.

The ReqView ENTERPRISE plan enables you to share floating licenses in large teams. To use this license, your system administrator shall install and configure a license server (typically at your premises), see Floating License Server. Then you can activate the ENTERPRISE client license same as we described for the PRO and TEAM plans above.

Choose Version Control System

Using a Version Control System (VCS) in conjunction with ReqView is not strictly necessary. However, it is highly recommended, as it enables some great benefits:

• Baselines. Using a VCS facilitates easy freezing, marking (also sometimes called tagging), and saving of versions of project documents, corresponding to the different project milestones (pre-PDR version, PDR-approved version, etc.). You can retrieve these document versions at any later time to display or compare them.

• Enhanced Team Collaboration. Using a VCS in conjunction with ReqView greatly improves multi-user synchronization in the project team.

• Audit Trail. You can commit document changes to the VCS repository with a custom message describing changes frequently. This provides timely snapshots that allow fast recovery from editing errors.

To achieve these benefits, ReqView integrates with two of the most popular open source VCS in the industry: Git and Subversion (also known as SVN). The integration with the SVN and Git is quite similar and provides the same functionality.

When you need to decide which VCS to use with ReqView, the following guidelines may help:

• If your organization already uses either Git or SVN, then there is already organizational knowledge with that VCS, as well as an active server environment. In this case, it may be best to choose the VCS the organization already uses.

• If you plan to run a hybrid development team that shares its development artifacts over the internet, using GitHub, GitLab, Bitbucket or Azure DevOps (ADO) as the repository, then using Git as a VCS should be the way to go.

• If you work in a closed environment and do not have any previous VCS experience, SVN is easier to set up and understand. It may be worthwhile to note that Git provides means to migrate from an SVN repository, should a future need to migrate to Git arise.

In this tutorial, we will use Git and all further text will demonstrate using Git as the VCS. SVN could be used equally well. You can find the full details of how to use SVN on the Collaborate via Subversion (SVN) documentation page.

Install Git

To use Git, you need to install Git command line tools on each computer running ReqView, see Install Git Client.

Your system administrator will select a Git provider, such as GitHub, GitLab, Bitbucket, or ADO. Another option might be using an on-site Git server like Gitea or Gogs. In this tutorial, we will use GitHub and host Git repositories in the cloud.

You may also choose to install a Git GUI client program. The need to issue Git commands directly is rare, but in these cases, a GUI may come handy. Fortunately, Git is very popular, and there are plenty of good, open-source, free GUI Git clients.

Setup ReqView Local Workspace

A ReqView Project is an entity that contains ReqView Documents and also holds some project-wide definitions, such as the configuration of project traceability links. In small projects (about 10-20 documents), the whole real-life project is usually organized as a single ReqView project.

Project management practices of bigger projects usually divide the project, after completing the system requirements and design phase, into subprojects. Such subprojects are defined for different sub-components, and/or according to disciplines, working groups, etc. In these cases, a distinct ReqView project will usually be created for each sub-project.

ReqView projects can be linked together, creating a hierarchical project tree structure (the linking of ReqView projects will be explained later in this tutorial).

ReqView projects are stored in Project Folders, which are directories on the local filesystem. These directories should be allocated solely to ReqView and to the local Git repository for that project.

ReqView Local Workspace is the local directory storing various ReqView projects you are working on. We recommend the following organization of the Local Workspace:

• A directory in the Local Workspace root directory will be created for each real-life project. The directory name will be the same as the project name.

• If the project is a small-scale project, that project directory will be the ReqView Project Folder.

• In the case of bigger projects that the user plans to divide into subprojects, a directory for each ReqView sub-project will be created in the project’s directory. The name of these directories will be the same as the sub-project names, and each directory will be the ReqView project folder of the corresponding sub-project. The only limitation of this simple organization is that each sub-project should have a unique name, which is a good practice anyway.

You do not need to create all the project directories in advance. You can add directories for projects and subprojects as the work progresses or the need arises. You can even easily split small projects into subprojects later.

ReqView Local Workspace for UNEX Project

Our initial directory structure of the Local Workspace for our example UNEX project inspired by the UNEXMIN project will look like:

<ReqView_WS>
+--- 498-doc-templates-prj
+--- UNEX
    +--- UNEXsys
    +--- … additional sub-projects added later

• Directory <ReqView_WS> denotes the root directory for the ReqView Local Workspace used in this tutorial.

• Directory 498-doc-templates-prj stores a small ReqView project to maintain our document templates.

• Directory UNEX stores sub-projects of our example UNEX project. In the beginning, it will contain ReqView project UNEXsys describing top-level stakeholder and system requirements. After doing the system design, we will decide on further sub-projects storing information for each discipline, for example, one for the UNEX mechanics, one for the UNEX software, etc.

In the next chapter, we will introduce various methodologies and development standards for the Systems Development Life-cycle (SLDC) process. Then, we will discuss selection of development model for our example UNEX project.