Who should have a say in what a software system should do? The broad term we use for anyone with a vested interest in a software system is a stakeholder. Notice we didn’t say customer or user or something similar. Stakeholders can come in a lot of forms.
Consider a “student information system.” A “SIS,” if you will, that is used by everyone on a college campus for different reasons:
And this is only a sample. Trying to ascertain all the different needs for a software system can be a challenge. That’s where requirements elicitation (or analysis) comes in. This is the process by which a requirements engineer gathers the info they need about a system and talks the stakeholders through their actual needs. (Remember: Solve the right problem!)
Here are some example elicitation techniques. Some are more suited for smaller, more agile projects, while others are for large-scale projects that use more plan-driven methods. Can you figure out which is which?
There’s no clear-cut right or wrong answer about which techniques to use. The challenge is in getting enough reliable information to build the correct system, but not too much that it basically overwhelms the developers with conflicting feedback. A good requirements engineer knows how to prioritize needs from the more critical stakeholders, while also recognizing exactly who the more critical stakeholders are.