Eliciting software

What do you see when someone asks you to imagine a car? Which make, model, and color is the car you picture? If you want someone else to picture the exact same car you do, the only way you can achieve this is by describing your car in detail.

Some details may seem irrelevant or too obvious to you until someone asks about them. As a result of elicitation, a BA creates a set of project objectives. Requirements elicitation is an important step of the software development discovery phase. During the elicitation process, a business analyst works closely with the client and all stakeholders, studying and validating their needs and assumptions as well as project risks. The discussion ends when stakeholders can think of no new use cases or when the use cases they can think of have a low priority and can be implemented during future iterations.

For example, one Apriorit BA was working on a reporting system for a logistics company. One of its key features was the ability to download multiple PDF files simultaneously.

When our BA asked for more details on this feature, it turned out that the solution had to download more than files at a time. Realizing that this would influence system performance, the business analyst specified a time limit for the downloading process.

Eliciting requirements usually happens in three stages. During these stages, a business analyst collects relevant information from the client, conducts elicitation sessions with stakeholders, and gets approval for the requirements before handing them over to developers. Preparation starts with business analysts collecting the documentation they need and analyzing the current system if one exists.

Documentation usually includes but is not limited to :. To speed up the study of complex documents, a BA usually asks the client to provide a subject-matter expert SME — someone who knows the organization, project, and technology well. The next preparatory step is analyzing stakeholder roles. During this analysis, a BA defines all stakeholders affected by the project and decides which of them should be involved in elicitation.

This stage is necessary to speed up the elicitation process, engage only relevant stakeholders in the discussion, and keep everyone affected by future changes informed. We prepare a table that lists various project tasks and stakeholders. A business analyst then determines whether a particular stakeholder is responsible or accountable for an activity, can consult on it, or should be informed about changes. For one of our projects, we had to reduce the call handling time in a call center by introducing a new system for taking calls.

This system impacted a lot of people: operators, supervisors, the operations department, etc. Our business analysts prepared a RACI matrix that allowed them to quickly assess the needs of stakeholders, determine their responsibilities, and figure out how to work with each of them without causing any issues.

Once stakeholder analysis is completed, the business analyst prepares use case and process flow diagrams to discuss them with stakeholders. A use case diagram is a graphical representation of a relationship between an actor a user, application, or system and a solution.

By discussing use cases with stakeholders, we agreed on the swiftest and most comfortable interactions with the system. What is Requirement Elicitation? Requirement gathering or requirement elicitation is key to success for any software development.

Why is it important in the software development process? Can you imagine starting software development without proper information about the system?

Certainly a big NO! A project can fail for the following reasons:. Poorly defined requirements. From the project management prospective most of the project fail when they do not meet the following criteria: a. Deadline b. Cost The reason behind software failure may be poor requirement elicitation. As a result would lead to lost development time, missed project timelines, loss of revenue, increased frustration amongst team members, poor quality of documentation — the list of impacts can go on and on.

Lack of communication. Lack of communication or ineffective communication especially with stakeholders can lead to software failure. Less involvement of stakeholders in communication will ultimately lead to loss of trust. A bad leadership. Also, a single stakeholder might also sometimes express two incompatible requirements. Changing requirements is another issue — In the case of successive interviews or reviews from the customer, there is a possibility that the customer expresses a change in the initial set of specified requirements.

While it is easy to accommodate some of the requirements, it is often difficult to deal with such changing requirements. Partitioning the system suitably to reduce complexity — The projects can sometimes be broken down into small modules or functionalities which are then handled by separate teams.

Often, more complex and large projects require more partitioning. It needs to be ensured that the partitions are non-overlapping and independent of each other.

Validating and Tracing requirements — Cross-checking the listed requirements before starting the implementation part is very important. Also, there should be forward as well as backward traceability.

For eg, all the entity names should be the same everywhere, i. Identifying critical requirements — Identifying the set of requirements that have to be implemented at any cost is very important.

The requirements should be prioritized so that crucial ones can be implemented first with the highest priority. Elicitation is the cornerstone of any project, as it plays a critical role in bringing the requirements for a project to the table. Scientists and engineers agree that elicitation errors are one of the most common causes of project failures and abandonment that negatively impact the bottom line. To avoid the possibility of fatal mistakes hampering a project, adequate research and preparation are hence necessary for the elicitation process.

Simply put, the goal of a requirements elicitation is to exhaustively identify the assumptions, risks, and needs involved in any project. Requirements elicitation is one of the most complex, error-prone, communication-intensive, and challenging stages of the software development process, as it is pivotal in determining the budget, time estimate, and scope of a project. The clarity of requirements elicitation should be exceptional in order to deliver solutions that end-users find useful and satisfying.

Incorporating requirements elicitation into business analysis practices enables Business Analysts to act as a bridge between developers, stakeholders, and end-users, thereby facilitating the seamless development of applications that are responsive to customer requirements.

Factors, such as the customer's profile and organizational structure, as well as the project type, should be considered by the business analysis team before adopting a requirements elicitation technique or a combination of techniques. There are many requirements elicitation techniques for obtaining critical information from Subject Matter Experts and stakeholders. The most popular ones are listed below. The requirements elicitation process begins with brainstorming.

To facilitate focused and fruitful brainstorming sessions, business analysts should set up a team with representatives of all stakeholders for capturing new ideas. Suggestions coming out of brainstorming sessions should be properly documented in order to draft the plan of action.