Requirements Management
Discussion
Hi all
I'm a design engineer in nuclear and have the opportunity to move into requirements management, which is something I'd not had any exposure to before moving into nuclear.
I like doing CAD, but the speed of nuclear and all the red tape and box ticking that follows means it's a world of difference from the manufacturing industry I'd always been in previously and the requirements management would be a complete change for me.
Does anyone have any experience with it they could share? It seems like I'd have a lot more exposure to a lot more stuff, albeit not quite as exciting?
I suppose it would offer a pathway to moving into project management, planning, stakeholder management.
I'm a bit apprehensive as it's not something I've ever had experience with or had to do, but maybe change can be good.
Cheers!
I'm a design engineer in nuclear and have the opportunity to move into requirements management, which is something I'd not had any exposure to before moving into nuclear.
I like doing CAD, but the speed of nuclear and all the red tape and box ticking that follows means it's a world of difference from the manufacturing industry I'd always been in previously and the requirements management would be a complete change for me.
Does anyone have any experience with it they could share? It seems like I'd have a lot more exposure to a lot more stuff, albeit not quite as exciting?
I suppose it would offer a pathway to moving into project management, planning, stakeholder management.
I'm a bit apprehensive as it's not something I've ever had experience with or had to do, but maybe change can be good.
Cheers!
frisbee said:
In my experience it's little more than wordsmithing - getting requirements from a customer, rewording them a bit to add "value" while fiddling around with lots of spreadsheets.
There may be more to it in some industries and companies but it's likely to be a dead end.
I'm a systems engineer and have worked in Nuclear. Requirements management includes more than this in reality. The wordsmithing part is only really the writing part. You've also got to understand & link the requirements from top level Stakeholder requirements down to your low level subsystem and component requirements. This will involve working with your Hardware and Software engineers closely to ensure this is complete. You'll have your right hand side V&V tasks, how are the requirements met, what testing will take place, how and by whom? What are the impacts of certain requirements being met and how will you negotiate with the customer if these aren't met.There may be more to it in some industries and companies but it's likely to be a dead end.
As for the Nuclear side, yes it will be glacial. I remember discussing a single requirement for over a week at one point! Chances are the requirements will be 'managed' via a documentation driven approach, which is probably the most painful way to do it. Huge documents no one ever reads and documents that will need to be reviewed by 20 different people to get sign off. If you're lucky you'll have a MBSE model and requirements management tool such as DOORS to use instead but my experience with defence or nuclear is the former. DM me if you want to have a more in depth chat. I've found, personally, systems engineers don't have a very exciting job, but I've made it pay very well in my circumstance at least.
Thanks for the responses both. Given me something to go and think about and look into.
I should add that it would be alongside my current CAD role for the time being, with the amount of RM I do tailoring up or down dependent on where things are at, so I'm not jumping straight into it fully.
I'll have a look into some sort of training courses too, can't hurt
I should add that it would be alongside my current CAD role for the time being, with the amount of RM I do tailoring up or down dependent on where things are at, so I'm not jumping straight into it fully.
I'll have a look into some sort of training courses too, can't hurt
You may also find the MoSCoW Method of analysis useful to define what has been under consideration and what the results of that are.a
https://www.projectsmart.co.uk/tools/moscow-method...
https://www.projectsmart.co.uk/tools/moscow-method...
If you want to get from Design Engineer to Project Manager, Requirements Management isn't the way to do it. As others have said, RM is positively glacial even outside nuclear and needs people who move glacially through the detail to check, check and check again that the golden thread is continually complete. PM candidates need to show ability to move at pace and I have never met an RM who cut the mustard as a PM yet, they're just too slow.
If you want to get into PM in nuclear at the moment have a look at
HPC: https://careers.macegroup.com/gb/en/job/31743/Assi...
SZC: https://www.linkedin.com/jobs/view/3964098112/?ref... (it will reopen in a few weeks,we I've heard they just need SPMs and PMs first to train the APMs)
If you want to get into PM in nuclear at the moment have a look at
HPC: https://careers.macegroup.com/gb/en/job/31743/Assi...
SZC: https://www.linkedin.com/jobs/view/3964098112/?ref... (it will reopen in a few weeks,
Also look at big engineering consultancies like Jacobs, Frasier Nash etc.
I work with some folk who do requirements and dip into it myself at times, mainly use moscow on the IT side. Can be interesting having to pull legislation, regulations, internal policies, good practices and the requirements for the thing B itself together and balance them. I’d rather be doing, but some folk enjoy it a lot.
Need to be very wary of the difference between a requirement and a solution, certainly in IT then you’re defining the former so someone else can define the latter.
I work with some folk who do requirements and dip into it myself at times, mainly use moscow on the IT side. Can be interesting having to pull legislation, regulations, internal policies, good practices and the requirements for the thing B itself together and balance them. I’d rather be doing, but some folk enjoy it a lot.
Need to be very wary of the difference between a requirement and a solution, certainly in IT then you’re defining the former so someone else can define the latter.
Have worked in the same industry as you in a similar role for longer- I wouldn't describe requirements management as a step on the pathway to a projects role at all, it's another 'specialism' just like an engineering role. If you want to switch over to projects you can do that directly from your current role, I have worked with quite a few PMs who did just that.
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff