Thinking in Requirements Engineering — Elicitation(2/2)

Though many requirements elicitation techniques are proposed, very few of them are widely adopted in industry.  For the nature of requirements, it’s true that no silver bullet exists to solve all types of elicitation problems at once. Hence, some researchers put efforts to find out requirements elicitation selection criteria, where they mainly do empirical studies or systematic review. Most of their findings distinguish elicitation techniques in terms of differences, similarities, advantages and disadvantages. Most important of all, those selection guidance are vaguely given based on situational characteristics. However, among those situational characteristics, none of them, as far as I know, mention the types of stakeholders that might affect the appropriateness of elicitation techniques as well. 

There are many types of stakeholders that should be taken into consideration when eliciting requirements. Those different types of stakeholders play different roles in participating the software development activity. Hence, what they know about, how they access, and what their interests on the software to be built differ from one type of stakeholders to another. In other words, the requirements we aim to get from different groups of stakeholders are supposed to be of inequitable value, different forms and focuses. Therefore, we can apply different elicitation techniques with a particular emphasis on certain aspects of requirements based on what type of the stakeholder is.

To illustrate the above idea, the following are some examples to articulate how to choose techniques and what to consider as targeting outcomes when eliciting requirements from different types of stakeholders. To start requirements elicitation , understanding high-level goals of the project is often necessary to better progress the elicitation process. And those goals mainly from champions (aka.) sponsors, company leaders etc.. As what ‘s wanted from them are goals/expectations of the project – tacit knowledge in their minds, structured interview is a good way to get that. For normal operators, as they are very familiar with the kind of software to be developed, if they have a existing system, participant observation, storytelling, and use cases suit them better, or if it’s an innovative project, focus group, brainstorming and survey would be better. In such cases, the intended requirements we try to discover from them are mainly about functional requirements, usability, maintainability, etc. One more example is for functional beneficiaries, such as interfacing systems, purchasers, they usually look for reliability, scalability etc from the developing software. Questionnaires and meetings with those concerns might be good.

2 thoughts on “Thinking in Requirements Engineering — Elicitation(2/2)

  1. My experience has been that some stakeholders can be very difficult to get hold of. Indeed some of them can (ironically) be reluctant to share domain knowledge. This is particularly prevalent in the health sector. Interesting blog.

    • wow! ^ ^ Thanks! I am very delighted to see your reply. Yes, I guess that is one cause which makes requirements engineering difficult and challenging but very interesting and enjoyable as well. So as it is the case like that, may I ask that whether you have found any useful techniques to deal with that? (well, here I presume you are a requirements analyst/engineer…)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>