The Secret of Success in Projects: Requirements Elicitation

Despite the efforts of project teams and too many resources, projects often fail. Requirements and time limits that cannot be correctly determined due to a lack of communication between stakeholders are the most common obstacles on the road to failure. Generally, the results appear in the form of not meeting user requests, exceeding the promised times due to frequent changes, or employee dissatisfaction. The keys to success are well-defined requirements, a seamless communication network among stakeholders, self-organization, and project teams that are capable of meeting changing needs. In order for the projects to successfully see the finish line, understanding how the factors we have underlined guide us on the difficult path to success is as important as bringing them to life.

In this article, we set out to elicit and define the requirements. Requirements are a set of specific definitions that help meet customer needs. Successfully identified requirements are the starting line for a project that has the potential to succeed. Requirements elicitation is an interactive and research-based process that occurs during meetings with customers and users. Therefore there is a serious difference between “gathering” and “eliciting” requirements (Requirements Elicitation). Gathering requirements refer to the act of asking the customer for a list of things they want to do whereas eliciting requirements is the act of separating user wants and needs. While customers often find it challenging to separate what is a need and what is a desire, they need guidance from project teams.

Many types of requirements are defined in projects, including business requirements, business rules, user requirements, functional and non-functional requirements. While business requirements and business rules can affect the project, identifying user requirements, functional and non-functional requirements is the most important action in the success of the project. When starting a project at Medianova, we first work to elicit user requirements that define what users can do with the product to be developed. Then, we discuss the most preferred methods while defining user requirements in Agile Project Development.

• Use Case,
• User Story,
• Wireframe,
• Storyboards

Use Cases are one of the best ways to show the relationship between the system and end-users. Used to describe a task from a stakeholder perspective in the development of a product. It is expressed in the form of a simple and general table like the following, free from technical details.

User stories, which are quite simple in terms of reading, writing, and evaluating, are another way of defining the most preferred end-user requirements. A user story should be easily separated from other user stories and can be developed and implemented independently. Instead of focusing on specific technical details, the focus should be on the main and important aspects of the user requirement. The predictability of the time required to design and implement a user story is another important point. User stories with unpredictable durations are probably quite wide in scope and are called Epic. In such a case, the user story should be divided into more than one user story in smaller parts. At the same time, it is one of the most important features of a well-defined user story that it definitely adds value to the end-user and can be tested.

The impressions that give the user and the customer an idea about how the product will look like, are called Wireframe. Wireframes are used to give a general idea about the product to be developed, to receive feedback from users and customers about the product, to include them in the product development process, and to communicate with the development team. Storyboards, on the other hand, are generally expressed as showing wireframes with a relationship to create a flow. It is intended to help the development team design requirements, help identify what may be overly complex or missing in supporting tasks, and ensure that the development team is aware of the product’s functionality and feel.

Below is an example of a storyboard created for a social media app and contains no design elements for the sake of simplicity. The product is an application that allows users to post about whatever they want and share them with their followers. Once a post is created, the post will be displayed on the timeline of all users following them. Next to the post, the user’s profile picture and user’s name are displayed. There is also a timestamp on each post that shows the date and time the post was created. Followers can identify favorite content that they can access to review and read later.

All of these efforts are not to create super and laborious documents, but to identify user needs more quickly and accurately. Before each different project, we define the requirements in customized formats according to the project type, the method used, stakeholders, and time constraints and as simple as possible. We associate the success of our projects with these factors and continue our effectiveness in the market with products that fully meet customer needs.