Welcome to sphinx-needs Discussions! Introduce yourself :)

[danwos]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[danwos]

Hi all,

I'm Daniel, founder and maintainer of this project :)

On my daily job I'm developing tools and solutions for project management, SW development and SW integration for Automotive companies in Germany.

I mainly use Python as my first-class programming language, but also JavaScript where ever it is needed (mostly for web front ends).

4 years ago a tooling-team, where I was part of, searched for a way to document a development project easily and compliant to the Automotive Standard ISO26262.
Normally for such stuff IBM Doors, Atlassian Jira and other expert tools are used. But setting them up takes normally days and understanding them even more. So we wanted a simple solution, which provides a single documentation and which contains everything what is needed to show our compliance to the ISO26262 standard (single-source-of-truth).
So sphinx-needs was born and since then it is still used in all my tool development projects.

One apology at the end, as customer projects and my family are taking much time, I'm not always able to solve tickets or answer issues in a reasonable amount of time. So from my side my development contribution is more coming in waves: Minor stuff for a couple of time and then some days of full-time commitment. I try hard to get my self better organized, but you know, life is a monster ;)

[twodrops]

My name is Nirmal Sasidharan and my role is as software architect at a automotive supplier in Germany.

My history with documentation started with developing tools based on SGML around 2001, moving through the XML era, to eclipse based modeling tools like oAW, EMF, Xtext etc. I was until some time ago Eclipse committer for several projects. I focus now more on refactoring legacy systems and bringing them under testing. My primary aim is to think as a developer and take all steps to improve developer efficiency.

I am the founder of docs-as-code community inside our company to bring about mindset and cultural changes towards docs-as-code among developers, process-responsible and management primarily by creating awareness and clearing myths on docs-as-code.

Sphinx based documentation is already established at our company and we plan to extend it with Sphinx-Needs.

Our usecase would be to use Sphinx/Sphinx-Needs through out the entire "V" lifecycle and use it as the means for documentation and traceability of engineering artifacts/elements. The traceability requirements in a safety critical environment like automotive can be as complex as the picture below.

I am happy to be here to exchange with the developers and users of Sphinx-Needs and contribute to improving this great little extension (with my limited knowledge of Python) 😄

[danieleades]

Hello,

My name is Dan, i'm a software project manager for a robotics software company. I'm primarily a Rust developer, and I dabble in Python. Don't get to use much of either day to day anymore though!

Where I work the engineering teams live in a world of plain-text, git, and code reviews. Senior management on the other hand lives in a world of PDFs, audited workflows, and heavyweight document approval processes. For people like me who live in between there's a massive overhead in bridging those two universes.

My hope is that sphinx-needs can bridge that gap- allowing engineers to use plain-text and standard software tools, and generate compliant documents that satisfy our document management requirements. I'd like to use this for managing requirements and test cases, and if possible, test results (extension may be required before sphinx-needs can meet our test results management requirements)

I'm enjoying cleaning up some of the code, and it gives me an opportunity to build my understanding of how this extension works.

There's a couple of open bugs that are preventing me from being able to fully adopt sphinx-needs in my workplace, particularly one that prevents me generating PDFs. I'm also hoping (a little cheekily) that if i can make a few positive contributions to the code base I can get the priority of those bumped up the list ;)

Longer term my goal is to attempt to integrate sphinx-needs into our quality process. If i can do that, then we can adopt it and my team can use, extend, and actively contribute to sphinx-needs on company time.

[sembooooo]

Hi ,
My name is Sana Srikar.
My role is as software Developer at a automotive supplier in Germany.

I mainly use DOORS as my requirements tool but this docs-as-code spiked my interest.
I am learning on how to use this tool and get benefited.
Facing difficulties in understanding on how to set up documentation as it is the very beginning.

i want to try out sphinx needs instead of DOORS (Ofcourse i hate it that is another story ).

[Thomas-Swindells-t]

Hi,
I'm Thomas, I'm a software architect working on cloud based systems.

Like others I'm trying to establish sustainable, consistent and useful architecture documentation in a manner that can handle new features being developed and understand how they may impact other parts of the system. In particular allowing the automatic maintenance of different perspectives - such as a use case view which concentrates on the end to end details of the use cases and shows which components that the use case touches, but also component centric views which concentrate on individual pieces and link to the use cases that interact with them.

I've already started tweaking the code and hope to be able to contribute these back shortly (once the internal company legal aspects are sorted).

[danwos]

Thanks for your introduction.
Your requirements for different views sounds familiar and any idea is highly welcome. :)
And if you have any problems with the code, just drop a line.

[rsarrazin2]

Hi everyone,

My name is Roland Sarrazin, a software and solution architect for a Vietnamese OEM. I was brought to the docs-as-code mindset (and tooling!) by @twodrops's pioneering work in my previous position working as a software architect for a German automotive supplier.

My main drivers are high quality software and integrated (and enjoyable!) developer experience, both of which are greatly supported by tool initiatives like @danwos's.

I plan to contribute by reporting high-quality issues, but so far I haven't had the opportunity to do so ;-).

[danwos]

Hi @rsarrazin2,
Thanks for the introduction and welcome to our community.

[twodrops]

@rsarrazin2 Welcome to the community. Thanks for the nice words. Feels great that you are driving the topic now outside the organization where we were once together. Way to go!

[gdeane-cri]

Hello, my name is Gordon Deane, and I am a principal engineer at a small medical device startup in Cambridge, UK. Medical device regulation puts a high value on traceability of requirements, tests, risk scenarios and regulatory requirements. We have an interdisciplinary team so a pure docs-as-code solution seemed too alien to the team, but the Microsoft Office manual trace that was used previously simply didn't scale or provide value to engineers. We'd also had a bad experience with a formal trace database tool so management did not want to go that way.

I've put together a solution using sphinx-needs that seems to work quite well. It uses Python to scrape requirements and risk items out of spreadsheets, manual test protocols and test results out of Word documents, and a slightly modified sphinx-test-reports to ingest our automated test results that are tagged to requirement IDs. I'm also using Python to generate multi-level trace result tables in the form we want. (Ideally this would be a new directive, but given time constraints I've done it as a two-pass sphinx build to make a needs.json database, then adjust the database and form RST reports, and then run the final build).

At some point when we're less busy (ha ha) I hope to push back some of the ideas into contrib.

Main pain points so far: needimport is a great tool but has some limitations when used with larger databases: syntax errors in RST parsing imported description text are cryptic and difficult to tie to specific needs (you only get the line number of the import directive) and unless you explicitly filter and subdivide it, the import creates as link targets one massive gigantic page. Otherwise I'm very happy, thanks for your hard work!

[danwos]

Welcome Gordon to our small community.
Integrating external data is a common case and the feature requests for this are endless :)
I understand your problems with needimport and hopefully, we will have a more robust, model-driven exchange format someday.

If you need any help or want to talk, let me know.