As it is said in the SWEBOK guide, requirements elicitation is concerned with two main issues:
- Where the requirements come from, and;
- How the software engineer can collect them.
The first issue implies the existence of some sources, which provide requirements. The simplest example of such a source is, certainly, customers. The second one means that there are some techniques that can be useful for engineers if they want to elicit requirements.
It’s extremely important to understand that the relations between the development team and the customer strongly influence the performance, costs, quality and ultimately the final result of the project. Before construction stage begins, requirements specialists must create all opportunities for productive connections between developers and stakeholders. One of the good and important things that has to be taken into consideration at the very beginning of any project is the project scope that means a description of the software specifications and it’s purpose, which are used to define the most important business needs of the customer.
1) Requirements Sources
Let’s talk about the probable sources, from which the requirements can be obtained. As I said before the first source that comes to my mind is stakeholders, or to be more precise customers. However, there are many other sources that even are not people.
Goals
Goals as the most completed description of the expected result of the project are, certainly, involved in the process of requirements elicitation. However, the common problem is a poor and vague formulation of the goals. One of the possible decisions of the problem is a feasibility study. It enables engineers to assess the value and cost of the goals. In other words a feasibility study assesses the project potential to success. This assessment is based on several criteria:
- Historical background;
- Descriptions of the product;
- Accounting statements;
- Management;
- Marketing research;
- Financial data;
- Legal requirements;
- Tax obligations.
Also the other classification can be used to systematize the factors that have influence on the project success potential:
- Technical feasibility;
- Economic feasibility;
- Legal feasibility;
- Operational feasibility ;
- Scheduling feasibility.
Thus now it’s clear that there is a great variety of things that can be used to evaluate whether the project goals are feasible or not.
Domain Knowledge
In our specific case this means that there is a background, which have to be always kept in mind, when we elicit the requirements. This background is also known as an application domain. It determines the requirements more specifically.
This description seems a little vague. So, I’ll give some examples. If we create a system for banks, all the features of banking can be represented as an application domain. If we create software for airliners other features constitute the application domain. Another example is legal constraints for any project. So, we can see that most domain knowledge requirements are a kind of constraints.
Stakeholders
Stakeholders are all people who are connected with the project, no matter how they are connected. The main idea is that they have impact on it or it has impact on them. It’s clear that all those people have different views on the project, and that is why the requirements specialist need to represent and compare all the viewpoints and find a compromise between them. That is an additional proof of complexity and importance of software requirements elicitation.
Let’s enumerate most common stakeholders:
- Users – people who will use the software. It’s a very big group, which contains many diverse stakeholders. Their requirements are also varies strongly;
- Customers – that is people who actually pay for the software. They represent the target market;
- Requlators – those people who control the application domains, about which we have spoken earlier (e.g. different authorities);
- Software engineers – the perfect example about software engineers’ requirements is reusing component of another software. It’s a great way to decrease costs and increase the speed of development. So, the software ability to reuse should be taken into consideration even before the project begins.
Business Rules
These are constraints that are determined by the structure of the business.
The Operational Environment
This is the environment in which the software will be executed. This type of requirements is especially important, because it’s closely connected with the money and general feasibility of the project. As we have discussed before the feasibility or the potential project value and costs mean a lot. Hence, it’s clear that operational environment requirements must be elicited very thoroughly. An example of such requirements is time performance constraints in real-time software.
The Organizational Environment
When software engineers create a system for a client company it will be a great plus if they undersatnd the business-processes and other features of the client organizations. It is important because new software should not break all the processes by unplanned changes. It should be integrated in the whole system.
2) Elicitation Techniques
After the sources were determined requirements specialists must find a way to actually elicit the requirements. The very important fact here that a software engineer should understand that generally sources can not provide the precise requirements. They just give requirements-related information, which later should be converted in the appropriate form.
Now I am going to describe some common techniques for getting such information:
Interviews
It’s probably the most popular and exactly the most traditional approach to elicit requirements. Different types of interviews are used in almost all projects. They can be divided in two categories:
- Closed interviews – they have a standard list of questions; the results are collected, systematized
- Open interviews – there is no any agenda here; an engineer explores different issues in order to understand better the needs of a stakeholder.
In practice requirements specialists use mix of them. A totally unprepared conversation is often unsuccessful, when strictly-defined questions always generate new ones in the process of communication.
Scenarios
Scenario-based conversation includes a kind of frame, which is given to the stakeholder by the interviewer. The question in this type of interview often contain words like ‘what if…‘ or ‘how is this done…‘.
The most common approach to simplify and improve informance of scenario-based conversation is formalizing it with use-case description, for example in the form of UML use-case diagrams.
Prototypes
Prototypes include all different open testing techniques such as mock-ups, drafts, beta-testing and other. These methods allow to elicit additional requirements already when the project is going. The requirements elicitation is a long-term process that isn’t completed before the final version of the software is created.
The good side of prototyping is a relative simplicity in use for stakeholders that means that it’s easier for engineers to get the requirements from them. However, there are some disadvantages, for instance, expensive prototypes development.
Facilitated meetings
Unlike interviews where there is just one interviewer facilitated meetings allow to compare different views and show to the stakeholder where the conflict is. However, such meetings should be carefully controlled, because the critical abilities can be eroded by group loyalty.
User Stories
This technique is common for Agile methods. It allows to avoid the waste information, which always occurs if the detailed requirements are derived. A standard user story builds upon the following template: “As a <role>, I want <desire> so that <benefit>”. However, it needs additional description of factors that have to be reached in order to fulfill the user story.
Conclusion
In this article I spoke about the software elicitation techniques and the sources providing requirements. If you have any questions or anything to add, you are welcome!
Thank you for keeping your time to read this!