Hi all, 

thank you for your replies. I am fully aware the main issue is the lack of process in my company. On many aspects I would say. I am not here to bash on my employer who hired me couple of months ago. I know the main issue is that people expect miracles without following best practice. This is due to that there has been minimal investment in many aspects of the business. Most of the staff is either not technical, or operating as test technicians. They need replacement parts on systems that fails, they need a new measurement instrument but they have no clue on the physics involved (optic/acoustic/vibration/shock/temperature...). They just need something that look like what they have at the moment. Their criteria are not defined. It is also difficult to schedule meetings them, for more than 30mins.

I have already made some spreadsheets to capture the systems requirements. As some of you mentioned, one issue is that this is ignored. And the cause is that no one has really been educated to this. I think it will come with time but I have flagged two other issues with spreadsheets: 

1) lack of formalism in regard to how you capture the requirements, which enable ways to write them wrongly : e.g. I can ask a technician to review the requirements I drafted based on the conversation we have in the lab. And he may add: "there  should be a way to fix this device to this support using a plastic or ss bracket", rather than: "the device shall be mounted on the system using a bracket" and "the mounting bracket shall not corrode while the system is in operation"
If there was a tool to avoid to write multiple requirements in one, that would be ideal.

2) Spreadsheets are messy, not fault proof and hard to maintain.
   Anyone who did a bit of oriented object may understand what I mean. Or anyone who deleted a column in Excel which was link to some formulae will concur with me. Also any improvement of the spreadsheet is generally undocumented, and hard to implement for all other project spreadsheets.
One main issue I have had was numbering requirements, or reordering them. 


Through my research, I found a file format call reqIF. I will have a deeper look at it. It seems that Eclipse has something call ProR to edit such files (https://www.reqif.academy/library/books/handbook/?p=sec-rmf_derivatives.html). This is something I might explore in the future. 

For other aspects of project planning, I have now access to MS projects, and I am self-training on it. 

PS: Not so satirical, but I joined as an electromechanical engineer, I was given a desk, a laptop and solder iron. trackability of legacy projects from my predecessor was inexistent, and I am still running in the labs after screwdrivers .

Hi all, 

thank you for your replies. I am fully aware the main issue is the lack of process in my company. On many aspects I would say. I am not here to bash on my employer who hired me couple of months ago. I know the main issue is that people expect miracles without following best practice. This is due to that there has been minimal investment in many aspects of the business. Most of the staff is either not technical, or operating as test technicians. They need replacement parts on systems that fails, they need a new measurement instrument but they have no clue on the physics involved (optic/acoustic/vibration/shock/temperature...). They just need something that look like what they have at the moment. Their criteria are not defined. It is also difficult to schedule meetings them, for more than 30mins.

I have already made some spreadsheets to capture the systems requirements. As some of you mentioned, one issue is that this is ignored. And the cause is that no one has really been educated to this. I think it will come with time but I have flagged two other issues with spreadsheets: 

1) lack of formalism in regard to how you capture the requirements, which enable ways to write them wrongly : e.g. I can ask a technician to review the requirements I drafted based on the conversation we have in the lab. And he may add: "there  should be a way to fix this device to this support using a plastic or ss bracket", rather than: "the device shall be mounted on the system using a bracket" and "the mounting bracket shall not corrode while the system is in operation"
If there was a tool to avoid to write multiple requirements in one, that would be ideal.

2) Spreadsheets are messy, not fault proof and hard to maintain.
   Anyone who did a bit of oriented object may understand what I mean. Or anyone who deleted a column in Excel which was link to some formulae will concur with me. Also any improvement of the spreadsheet is generally undocumented, and hard to implement for all other project spreadsheets.
One main issue I have had was numbering requirements, or reordering them. 


Through my research, I found a file format call reqIF. I will have a deeper look at it. It seems that Eclipse has something call ProR to edit such files (https://www.reqif.academy/library/books/handbook/?p=sec-rmf_derivatives.html). This is something I might explore in the future. 

For other aspects of project planning, I have now access to MS projects, and I am self-training on it. 

PS: Not so satirical, but I joined as an electromechanical engineer, I was given a desk, a laptop and solder iron. trackability of legacy projects from my predecessor was inexistent, and I am still running in the labs after screwdrivers .

ReqIf is a transfer format. I've used it to transfer requirement sets between different tools and different databases with the same tool. It is not without it's limitations. Mostly that it doesn't handle deletions very well.

Given that Eclipse is free, its worth giving it a try. I had not come across that tool.

At risk of someone throwing things at me, but there is also ISO/IEC/IEEE 15288: 2015 - System and Software Life Cycle Processes which is also available as the INCOSE Systems Engineering Handbook. The contains a lot of good detail about how systems engineering processes should work. You will also find supporting material in the SEBoK (sebokwiki.org)

There is also the INCOSE Guide to Writing Requirements which has some good practices. the useful thing with this guide is that it defines testable criteria for checking a requirement. Some tools even automate some of these checks now.

What I've seen done is that during a peer review, the checklist is used against each requirement. In theory the person preparing the requirements could use the same checklist to check their work before submitting. We essentially had the checklist incorporated into our process.

A lot of its is practice and training. Even with experienced requirements engineers, if the tool pushes you into writing multiple requirements in an object, they will. Using MS Word tends to cause this behaviour. But sometimes is difficult to write a single atomic requirement that is complete, testable, concise, which is also where you see multiple requirements being written. 

Regards,

Mark