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.

Software requirements VS architecture — Literature 1

The Twin Peaks model, proposed in 2001, begins with the observation that software requirements and architecture are often developed in a concurrent and iterative fashion [1]. This observation implies the inevitable intertwining of requirements and architecture though it is implicit in practice. By understanding this relationship, practitioners are able to build software systems more cost-effectively and of higher quality. More specifically, they can improve how new systems are built, how change requests are handled, and how new functionality is introduced [2].

The literature on the relationship between requirements and architecture is limited. In “Traversing the twin peaks” [3], the authors argue that requirements are the end result of an architecting process. More concretely, since requirements drive architecture and architecture influences requirements in return, this back and forth interplay constantly shapes requirements and architecture till all trade-offs and conflicts are balanced. Hence, the resulting requirements could more appropriately reflect the ultimate designed architecture. In that sense, the architecturally significant requirements in the resulting requirements are almost the same as the architectural design decisions. 

Bosch [3] proposes the idea that requirements engineering should be done by the architects and they should work with the lead developers to elicit and specify requirements which actually is an implicit state-of-the-practice. This view is partly supported by a study that finds most non-functional requirements are discovered by architects [4]. Bosch dismisses the importance of documenting requirements, as he claims that documentation often becomes outdated very quickly. He emphasizes that it is more effective to let the architects contact the stakeholders and learn their needs directly. 

If requirements are elicited by architects, they might tend to drift into solutions space instead of standing in the problems space. However, this problem could be solved by careful requirements validation from stakeholders. Moreover, in some sense, software development teams just need such proactive perspectives from the solution space to predict feasibility of certain requirements.

References
[1] Nuseibeh, B. (2011 ) “Weaving Together Requirements and Architectures.” Computer 34(3): 115-117.
[2] Cleland-Huang, J., et al. (2013). “The Twin Peaks of Requirements and Architecture.” IEEE Software 30(2): 24-29.
[3] Mirakhorli, M. and J. Cleland-Huang (2013). “Traversing the Twin Peaks.” IEEE Software 30(2): 30-36.
[4] Ameller, D., et al. (2012). “How do software architects consider non-functional requirements: An exploratory study.” The 20th IEEE International Requirements Engineering Conference (RE), 2012.

Thinking in Requirements Engineering — Elicitation(1/2)

The last twenty years has witnessed the increasing awareness and recognition of the importance of requirements engineering in software development. And a lot of methods, techniques and principles are proposed by academics to better engineer requirements. However, as a matter of fact, very few of them have been widely adopted in industry. Someprojects even skip requirements engineering entirely or partly, despite of its importance. Moreover, the role of requirements engineering hasn’t been widely accepted in industry as it should be. As a result, the current practice of requirements engineering in industry really seems to fall behind with the current academic research. What causes this big gap between academia and industry is well worth considering and studying.

Requirements engineering, usually regarded as the first phase in the software development, lays the foundation of the software to be built. It’s reported that errors in requirements usually have a bigger influence on the software and cost more to repair than errors made in other phases. Therefore, it’s worthwhile putting great efforts on requirements engineering for developing good software.

However, requirements engineering is very difficult. Requirement is perhaps the most people-oriented and least tangible concept in software development, where it largely depends on the stakeholders and they often change their minds unexpectedly. Besides, practitioners have to distinguish what features/properties the software really needs to have from what the stakeholders want and negotiate with them to resolve any conflicts. There is also a danger of misinterpretation when eliciting requirements from stakeholders, which consequently results in ill-defined or unclear requirements. With those difficulties both in nature and in practice, it’s hard to produce a great requirements specification.
From the above perspective, requirements are important and difficult to obtain accurately. Despite of its inherent difficulty, one of the top requirements problems in practice is the lack of stakeholder input. This problem, to some extent, indicates that current requirements engineering techniques and methods are not suitable or effective to produce good quality requirements, which is due to the low productivity from communications with stakeholders. Different stakeholders hold different views of requirements according to their distinguishing roles and interests for the software to be built. Therefore, requirements need to be understood from different perspectives. Hence, different eliciting strategies should be applied to different groups of stakeholders.