Requirements Elicitation

Slide Deck: Requirements Engineering

Talking to Your Stakeholders

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:

• Students: enroll in classes, pay bills, check graduation requirements
• Faculty: see class rolls, admit students off the wait list, see student records for advising
• Registrar: create classes, assign classes to rooms, process graduation requests
• Financial Services: issue invoices, process scholarships
• Board of Visitors: approves the purchase of the system

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!)

Elicitation Techniques

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?

• interview - very common, usually structured, but could just be a conversation with stakeholders, must ensure the customer agrees with the outcome of interview (more agile, but can be used with plan-driven)
• observation - watch people do their current daily jobs and see where problems arise (both)
• examining docs / artifacts - read everything you can about current policy and procedures (both)
• JAD (joint application design) - very structured “board room” requirements gathering session (plan-driven)
• groupware - kind of a mix of asynchronous interview with a large digital whiteboard (both)
• questionnaires - an asynchronous interview with as many stakeholders as possible (both)
• prototypes - rapid prototyping is often a good way to determine if you’re on the right track (both)
• focus groups - group interview sessions (both, but tends to be more plan-driven)
• on-site customer - the customer is a member of the team and guides the whole process (agile)

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.

---