Polarion Software Weblog

In the previous post we defined the requirements lifecycle and we outlined its formats and capture methods. Let’s now take a look at a few of the ways organizations approach requirements management today. Depending on an organization’s needs, the requirements management process can range from the most simple and rudimentary, to extremely formalized. We’ll also look at ways that Polarion Requirements™ can be used to enhance and improve each method of working.

In this post we will address the manual requirements process. In the next posts we will take a look into the Agile and Formal requirements processes, and then explore the “Polarion Way”.

The Manual Requirements Process

For many organizations, the requirements management process continues to be a manual process. Elicitation is not tool enabled, but is handled through face to face discussions, workshops and meetings. The capture mechanism is typically a Word document, Excel spreadsheet or PowerPoint presentation, sometimes backed by a UML model. In rare circumstances, a Mind Map will be used as the capture method. The discussion stage is handled through direct interaction over the document through meetings, or the document is circulated to stakeholders via email, and comments are gathered through these virtual interactions using the Track Changes feature in Word, or by saving comments conveyed in the email messages.

(more…)

Intro

In this Blog series I will try to reveal new ways to improve your requirements process – regardless of your starting point or requirements process. In this post I will define the requirements process and outline the various capture methods available today. In future posts we’ll look at the pros and cons of various common approaches used by organizations today to manage requirements, from the simplest manual process, to agile processes used in software development organizations, through to the most formal requirements process – and in each case, outline ways Polarion Requirements can be leveraged to better each process method.

Finally, for organizations that are approaching the requirements discipline for the first time, or who have a requirements process that is in-between the processes we’ve described – not too agile or not formal – I will share some recommended best practices for requirements management that we at Polarion have cultivated through our own experience in developing software, all of which can be easily enabled with Polarion Requirements or Polarion ALM Enterprise and implemented within any organization.

Why requirements?

In computing science terms, requirements management remains an immature discipline. While best practices surrounding the requirements management process and tooling continue to advance, there is tremendous opportunity for organizations to tighten up their product development process through greater maturity of the requirements management discipline.

Failure to properly define and manage requirements is often at the root of software project and product failure. It is a business reality that customers and management rarely know, or can describe in exact terms what they want at the end of the day. And too often, these same business sponsors will change their mind midstream – causing requirements to change. The impact of change even early in the project causes a downstream ripple effect, impacting project schedules, deadlines, delivery dates, and staffing commitments.

The ultimate goal of requirements management is, at the end of the day, to ensure that the final product meets the needs of the business. While this seems like a simple task, the process of articulating business needs or specifications, especially for complex products or software applications, is immensely difficult and requires significant elicitation and communications expertise plus advanced technologies to absorb, and manage detailed requirements and groups of requirements through to successful product/project delivery.

Organizations are individual in their approach to requirements management. Some companies and teams continue to rely upon manual processes – opting for a simple, tool-free approach that costs nothing and presents no learning curve. Others, such as a software development team who have embraced an agile development process, such as SCRUM and XP, demand a more fluid and transparent requirements process and lightweight tools that allow for iteration and frequent change. And finally, there are organizations with complex product development processes or in regulated industries that need a highly formalized and rigid requirements process and significant tooling support.

(more…)

Sometimes you may want to embed other web pages into a polarion wiki page. This may be the case if you want to

• embed existing wiki pages of other wiki systems you are currently using
• embed pages of your intranet
• embed exisiting web 2.0 application like mind mapper, drawing tools or whiteboarding tools

Please find below some example wiki code snipplets using the <iframe> </iframe> command

Embedding a wiki page e.g. from wikipedia
<iframe src=”http://en.wikipedia.org/wiki/Main_Page” width=”100%” height=”500″</iframe>

Mind Mapping with http://www.text2mindmap.com
<iframe src=”http://www.text2mindmap.com/” width=”100%” height=”500″</iframe>

Mind Mapping with http://bubbl.us
<iframe src=”http://bubbl.us/edit.php” width=”100%” height=”500″</iframe>

Mockups with Balsamiq (commercial) http://www.balsamiq.com
<iframe src=”http://www.balsamiq.com/demos/mockups/Mockups.html” width=”100%” height=”600″</iframe>

Drawing Charts with http://www.mxgraph.com
<iframe src=”http://www.mxgraph.com/demo/mxgraph/editors/workfloweditor.html” width=”100%” height=”500″</iframe>

Best Wishes
Tim

We are glad to announce the first localized version of our open source training materials for Subversion 1.5. Materials are available in Portuguese and can be downloaded here.

http://www.polarion.org/index.php?page=download&project=subtrain

Best Wishes
Tim

The described scenario assumes you want to open Polarion ALM to external customers or suppliers

If you are just running a Polarion ALM instance that is directly accessible from the Internet you also expose your Subversion repository , confidential content is accessible from outside.

Actually the Subversion repository is already protected by the access file, but it is easy to expose content by mistake.

This blog describes an approach to open Polarion ALM to external customers and avoid the risk described above.

Internal users access Polarion ALM directly from inside the internal network. The change will be transparent for them.

External users access Polarion ALM via a proxy provided by Apache. This proxy will forward safe requests only which don’t reveal internal content of your repository, even if Subversion’s access file is not configured to hide that information.

Basic configuration of the proxy
The basic configuration of the Apache running the proxy is quite simple.

Adding the following lines to the default configuration is sufficient (replace <polarion-server> with the URL of your Polarion server):
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
ProxyRequests Off
ProxyPass /polarion <polarion-server>/polarion
ProxyPassReverse /polarion <polarion-server>/polarion

With this configuration all requests to <external-server>/polarion will be passed to <internal-server>/polarion. Please make sure that the Firewall grants access from external-server to internal-server on port 80.

Securing the Proxy
With this configuration an external user could still access files in the repository. Actually, it is not that bad, as the user has to know the exact path of the file he tries to access.

Following line closes this possibility:
ProxyPass /polarion/webdav !

Unfortunately this configuration has a disadvantage: It will also disable access to LiveDocuments using Word and Excel for the external users.

Re-enabling access to Attachment
Disabling all access to the repository also prevents users from downloading attachments.

To enable download of attachments, the /svnwebclient/fileDownload.jsp URL has to be forwarded to the internal server.

Add following lines to the configuration of your Apache acting as proxy:
ProxyPass /svnwebclient/fileDownload.jsp <polarion-server>/svnwebclient/fileDownload.jsp
ProxyPassReverse /svnwebclient/fileDownload.jsp <polarion-server>/svnwebclient/fileDownload.jsp

Doing that without any additional precautions is risky: Again, the access of the external user to files in the repository is only restricted by the access configuration.

An additional layer of security can be implemented by restricting the parameters of the URL to only allow download of files inside the project(s) the external user is able to access. This is achieved by using mod_rewrite to redirect every forbidden access to a nonexistent URL.

Add following lines to your configuration:
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/svnwebclient/fileDownload.jsp$
RewriteCond %{QUERY_STRING} !^.*&url=<project-location>
RewriteRule .* /nonexistent

<project-location> has to be replaced with the location of the project in the repository, all slashes (/) in have to be replaced with %2F and a %2F should be appended at the end.

Example:
Assuming you want to expose Library project from the Polarion demo-data and your internal Polarion server has the URL http://polarion.

You can get the location of the project from the Overview Topic of the project.

The location is Demo%20Projects/demolibrary, the string to use is Demo%20Projects%2Fdemolibrary%2F

The resulting configuration to use for the proxy is:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
ProxyRequests Off
ProxyPass /polarion http://polarion/polarion
ProxyPassReverse /polarion http://polarion/polarion
ProxyPass /polarion/webdav !
ProxyPass /svnwebclient/fileDownload.jsp http://polarion/svnwebclient/fileDownload.jsp
ProxyPassReverse /svnwebclient/fileDownload.jsp http://polarion/svnwebclient/fileDownload.jsp
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/svnwebclient/fileDownload.jsp$
RewriteCond %{QUERY_STRING} !^.*&url=Demo%20Projects%2Fdemolibrary%2F
RewriteRule .* /nonexistent

Best Wishes
Benjamin