POZNAN SUPERCOMPUTING AND NETWORKING CENTER (PNCS)
ul. Noskowskiego 10
61-704
Contact:
Marcin Wolski <marcin.wolski@man.poznan.pl>,
Maciej Łabędzki <maciej.labedzki@man.poznan.pl>,
Adam Rybicki <adam.rybicki@man.poznan.pl>,
Louis Hancquart <hancquartlouis@gmail.com>,
Marcin Jankowski <marcin.j.jankowski@student.put.poznan.pl>,
Mirosław Ochodek <Miroslaw.Ochodek@cs.put.poznan.pl>,
Software Development Studio <sds@cs.put.poznan.pl>
File:
Business_Case_PCSS_Project.docx
Requirements Tracker
(Business Case)
Authors: Louis Hancquart, Marcin Jankowski
Version: 12.05.2015
1. Problems
a) Outline of the situation
In the Poznan Supercomputing and Networking company (later on called “PCSS” or
“Company”), developers work on big projects. Developing the software is based on
requirements, which are stored and maintained independently from the source code. The
requirements are generally long and can change quickly (every 2 weeks).
There is a lot of code, lot of developers so that the code can evolve quickly as well. Also
developers often change so they have to maintain the code that was written by someone else.
b) Main problems
Running a project, PCSS developers are not sure about which requirements are
implemented, which are not and what changed from the previous release. They also don’t
know who did which requirement and which part of the code is directly connected with a
requirement/is its implementation.
c) Other problems
PCSS also mentions other problems not directly correlated with those described above: low
quality of code and fact that not every team use scrum (teams are spread across Poznan and
Warsaw).
2. Solution outline
Provided solution must read the source code of a project and be able to make an index
referencing which piece of code corresponds to which requirement.
It will be software and later in this document called an “Application”.
3. Options
a) Do nothing

The application is not created

Things are left as they are
b) Do minimum

The application can generate an index (HTML report) of which requirements in
what version are satisfied in the Project

Users can access the part of the code which satisfies the requirement
c) Do over the minimum

The application satisfies “Do minimum” option

The application is able to generate a report of which requirements in what
version are satisfied, which are not, which are in progress

The application recognizes which requirements are satisfied using definition
of done

The application is compatible with Maven and Confluence tools

The application is independent of form of requirements – migration to
different forms of requirements is simple
d) Do very over the minimum

The application satisfies “Do over the minimum” option

The application contains plugin(s) to IDE(s) used by developers
e) Recommendation
SDS Team recommends gathering all data required for and designing “Over the minimum”
version; starting implementation from “minimum” version; extending the application to “over
the minimum” or maybe even “very over the minimum” as it will be noted that scope of the
development work can be widened. Justification: “over the minimum” version covers whole
“minimum” version so it is possible to create it in an iterative way. PCSS likes iterative
processes. Moreover it is the fact that the application will be further developed by PCSS
developers after finishing the SDS project so it will be good to design the application in good
way from the beginning.
4. Results for each option
a) Do nothing

Problems are not solved
b) Do minimum

Developers (and others) can check which requirements are satisfied within
what version

Developers (and others) can check which part of the code implements chosen
requirement
c) Do over the minimum

Facts from the results of “minimum” version are achievable

Developers (and others) can check which requirements are not implemented
and which are in progress

Developers (and others) can check who did which requirement

Developers (and others) can check what has changed from the previous
release

Developers (and others) can check which part of the code is directly connected
within which requirement
d) Do very over the minimum

Developers are able to track requirements directly within their workspace (in
an IDE)
5. Benefits
a) Expected benefits

Mainly benefits will be found during everyday work

Better understanding of the progress in the project

Finding unused code

Discovering potential vulnerabilities

Identifying what have been done so it is not done again
b) Dis-benefits

Developers won’t use the solution if they don’t feel it is helpful or if it is too
complex to use
6. Timescales
a) Earliest starts

Initiating stage: beginning of May 2015

Development work: beginning of October 2015
b) Latest starts

Initiating stage: half of May 2015

Development work: half of October 2015
c) Earliest ends

Initiating stage: end of June 2015

Development work: half of January 2016
d) Latest ends

Initiating stage: end of September 2015, although work and the documents can
be improved during development work

Development work: end/half (depending on bachelors thesis defences
schedule) of February 2016
e) Due date: end of February 2016
f) Increments deliveries: during development work within scrum
approach. The code and unit tests should be submitted to PCSS 1 day
before sprint review
7. Costs
Main cost will be time. For PCSS and PUT employees it is counted in their work time, for SDS
team and developers team (bachelors students) it is counted in their courses time (calculated
within ECTS).
Used rooms, devices and software are available for free either from PUT or PCSS.
As solution will be software it won’t generate costs for materials.
A framework or an existing libraries can be used to speed up the development but they must
be free of costs for PCSS use. Any proposal of leaving this rule must be consulted within PCSS
and they have to agree the license.
For the moment of writing this version of the business case it is not known whether funds for
this project will be found.
8. Investment appraisal
Not applicable for the moment of writing this version of the business case.
9. Major risks
a) Killing project risks

Not enough developers want to work on our project (“middle” probability,
“medium” impact): people from PCSS can help to develop in such case.
Previously it was planned to develop the application by developers from PCSS
and it will be developed by them after ending the project

Provided code quality will be low (“middle” probability, “low” impact): project
will be continued even if this happens. For preventing PCSS proposes
internship for bachelors to learn company standards, code quality,
conventions etc.
b) Positive risks

10.
Framework or library or any other software which solves this project’s
problems will be found
References
Not applicable for the moment of writing this version of the business case.