Skip to content

Users and Developers’ Roles in Requirements Elicitation Process

Statement

From your point of view, describe the strengths and weaknesses of users during the requirements elicitation activity. Describe also the strengths and weaknesses of developers during the requirements elicitation activity.

Solution

Multiple groups are responsible for the requirements elicitation process, and each group has its own objectives and concerns from this process. This process mustn’t finish until all groups’ concerns are resolved, the requirements are fully defined, and a clear Specification Document has been generated.

The ultimate goal of the requirements elicitation process is to define the requirements for the system and avoid costly and time-consuming surprises that may appear at later stages of the project. So, Developers usually take a great deal of this process -and they should do so- but Developers also have their strengths and weaknesses during this process.

Strengths of Developers during the requirements elicitation process:

  • Understanding business context (domain): Developers who understand the business domain can think of the bottlenecks related to the domain at such an early stage, allowing them to fix them in minimal time.
  • Previous experiences: Developers with previous experience with similar systems (not necessarily the same domain) can utilize their experience to extract the most out of the requirements elicitation process.
  • Knowledge about the client’s history: Developers with knowledge about the client’s previous experiences and their results can utilize that to raise any potential flaws in the requirement that caused problems in the previous projects and plan a better solution accordingly.
  • Knowledge about the client’s company structure: Developers who know their clients well can easily go to the right person to make the right decision with minimal effort, which will help the project’s timeline.

Weaknesses of Developers during the requirements elicitation process:

  • Lack of experience with similar systems or similar domains.
  • Lack of knowledge about the client’s structure: this may make developers constantly ask the wrong people to make decisions related to business logic or company policy; until this is resolved, the project may be delayed.
  • Too many players (stakeholders) in the process: When too many teams are involved, decision-making becomes more difficult and time-consuming.
  • Not discussing the non-functional requirements: non-functional requirements are usually not listed in the customer statement of requirements, and leaving such details non-discussed can lead to surprises and delays in the very late stages of the project.

The word Users is used in a vague context here, but we can consider it as the group of people who are not developers but also involved in the requirements elicitation process, which may include any client’s teams and/or any other stakeholders, investors, testers, managers, etc.

Strengths of Users during the requirements elicitation process:

  • Business policy and business logic decisions: Users who know their business well can make the right decisions and respond properly to any point that may arise during the process.
  • Knowing the set of the end-users: systems may be used internally by the company’s employees or available to the public; there are significant differences between the two. While internally used systems are more tolerated in terms of complexity -since companies can train their employees to use them-; public systems are more complex to develop but must be easier to use.
  • Technical knowledge: Users who are better educated about technologies, in general, can easily talk to developers in a professional way that facilitates the process.

Weaknesses of Users during the requirements elicitation process:

  • Lack of knowledge about the business policy: e.g., new hires, irrelevant teams, or departments injected into this process.
  • Lack of technical knowledge: can be a barrier in communicating with the developers.

References

  • Marsic, I. (2012). Software engineering. Rutgers Unversity. https://www.ece.rutgers.edu/~marsic/books/SE/book-SE_marsic.pdf