"Systems Engineering for the rest of us..."
Stakeholders are the ones who have an interest in a system or a stake in the outcome of the use of a system. The stakeholders are the source of many of the system requirements. For example; suppose we are to procure a payroll system.
Leaving out any of these groups when discussing the needs of a payroll system is very dangerous. Consider what would happen if your payroll system printed checks with no bank routing numbers or you failed to withhold taxes on your full time employees. Stakeholders understand the needs of the system. Stakeholders may not be able to precisely articulate needs, but their gut tells them what the system must do. And they know it when the system is not doing it.
A systems engineer knows how to find the stakeholders and interview them to collect the needs of the system.
These needs become the grist for the formal requirements against which the system is built or bought. Payroll is used as an example system because every business person knows almost everything about it.
But what if your business has a process that is not so well understood? And what if to stay competitive you need to procure a new tool or subsystem by some means? How do you find out what the system has to do? First, you examine the existing system, to see what it does. Often, the existing system will not be remotely like the new one but many of the requirements will be the same. These if overlooked will be a monumental embarrassment. Next you interview the stakeholders to discover the needs. Often they know what the previous system; did not do, should have done or did poorly.
Back | Next | Systems | Requirements