Establishing the groundwork

In an ideal world, stakeholders and software engineers would collaborate on the same team. In such cases, requirements engineering is simply a matter of having meaningful conversations with team members who are well-known.

We go over the steps that must be taken to lay the groundwork for an understanding of software requirements—to get the project started in a way that will keep it moving toward successful completion.

Identifying the stakeholders

Any person who benefits directly or indirectly from the system being developed is a stakeholder. Business operations managers, product managers, marketing people, internal and external customers, end-users, consultants, product engineers, software engineers, and support/maintenance engineers are the usual stakeholders.

Each stakeholder sees the system differently, gains different benefits when the system is successfully developed and faces different risks if the development effort fails.

Recognizing Multiple Viewpoints

Because there are so many different stakeholders, the system’s requirements will be examined from various perspectives. Each of these stakeholders will contribute data to the requirements engineering process. As information is gathered from multiple viewpoints, emerging requirements may be inconsistent or contradictory. You should categorise all stakeholder information so that decision-makers can select an internally consistent set of system requirements for the system.

Advertisements

Working toward Collaboration

If there are five stakeholders involved in a software project, there may be five different opinions on the set of requirements. Customers must work together as well as with software engineering practitioners to create a successful system. A requirements engineer’s job is to identify areas of commonality as well as areas of conflict or inconsistency. Collaboration does not always imply that requirements are set by a committee. In many cases, stakeholders collaborate by providing their perspective on requirements, but a strong “project champion” may ultimately decide on which requirements are accepted.

Asking the first questions

The first set of questions asked is context-free and focuses on the customer and other stakeholders, as well as the overall project goals and benefits. You could ask

  • Who is the person or organisation behind the request for this work?
  • Who will make use of the solution?
  • What is the economic value of a successful solution?
  • Is there a different source for the solution you require?

These questions aid in identifying all stakeholders who will be interested in the software being developed. Moreover, the questions identify the quantifiable benefit of successful implementation as well as potential alternatives to custom software development.

The following set of questions helps in gaining a better understanding of the problem and allows the customer to express his or her thoughts on a solution:

  • How would you characterise “good” output produced by a successful solution?
  • To what problem(s) will this solution be applied?
  • Can you describe (or show me) the business environment in which the solution will be used?
  • Will there be any special performance issues or constraints that will influence how the solution is approached?

The final set of questions is concerned with the effectiveness of the communication activity itself.

  • Are you qualified to respond to these questions? Is your response “official”?
  • Are my queries relevant to the issue you’re dealing with?
  • Am I interrogating you too much?
  • Can anyone else add to this?
  • Do you have any further questions?

These questions will assist in “breaking the ice” and initiating the communication required for successful elicitation.

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments