From URS to application – a look behind the scenes of your project at anic

How does this work? Tailor-fit software from anic – a case study

Your idea is one-of-a-kind! This requires tailor-made adjustments to the work. How does anic implement your project? Allow us to illustrate this with a real example.

In the beginning was the requirement

Chemical structures should be determined from calculations of quantum chemistry (link to explain molecular modeling) in a ChemReg system. Laboratory management software should continuously be provided with updated data on these structures. Due to the large number of structures, only a minimum level of user interaction should be necessary.

As a User Requirement Specification (URS), we presented this process in the form of UML use cases and UML sequence diagrams. The chemical structures from the calculations should be in SDF format. In addition to the molecular structure, additional data should be added as associated data in the SDF export. As FRS (Functional Requirement Specifications), documentation should be created in Excel and PDF format for the data fields that were to be imported. The molecular structures from the SDF export should be registered in the ChemReg system via Web API and should return unique identifiers for molecules that have already been registered. Molecules and extended data should be added to various Oracle database tables depending on the data in order to be able to work with them in the laboratory management software. For the  FRS (Functional Requirement Specifications), we created a database diagram of the corresponding tables of the laboratory management software into which data should be read. A file server loads the SDF export files and prepares the affected files for manual checking in the event of error messages from the ChemReg system.

The requirement meets the reality

The Web API of the ChemReg system changed several times, and the extended data in the Associated Data Fields for the SDF export were expanded several times. What happens if the requirements change during the course of the project? For us, agile project management is not just a catchphrase – we proved it clearly here. We were able to adapt to all changes at short notice.

Testing and documentation

(Project management was carried out via the TFS). Automated tests with NUnit were carried out in the TFS. The entire customer infrastructure from the web API to the file server and database access was simulated using the Moq mocking framework in order to make the tests independent of direct access to the customer system.

Behavior driven development was handled with SpecFlow and Gherkin.

Documentation: the customer received program documentation as a PDF as well as test protocols for the automated tests and SpecFlow tests in XML and TRX format (Microsoft MSTest format).