06 Mar

Requirements: feasibility, desirability, and viability

Requirements: feasibility, desirability, and viability

It is crucial to clearly define the requirements at the beginning of each research report. These requirements represent the specific criteria and expectations set by the client and other key stakeholders, such as end-users, for the solution that needs to be developed for the problem.

The requirements should be varied and categorized into various design criteria: feasibility, desirability, and viability.

  • Feasibility investigates whether the proposed solution is technically, financially, and operationally executable within the available resources and timelines.
  • Desirability assesses the extent to which the proposed solution meets the needs and expectations of stakeholders, including users, customers, and other involved parties.
  • Viability encompasses the sustainability and effectiveness of the solution in the long run, including factors such as market potential, competitive position, and risk management. In other words, viability focuses on the long-term effectiveness and continuity of the solution.

By first naming the requirements and then evaluating them based on the three criteria, we can identify the most suitable solution for the problem and maximize the chance of success at implementation.


Mentioning Requirements in a Study/Report/Thesis

The requirements must be described at the beginning of the study. Then, it is essential to explain under the chapter “Methods and Techniques” how these requirements have been tested. In the Results chapter, it can then be discussed to what extent the selected solution (such as a proof of concept) meets the requirements. A score table can be used as a tool for this.

In the Implementation Plan chapter, reference can be made to the steps that need to be taken so that the criteria of desirability, feasibility, and viability remain guaranteed. Concretely, this means: how can the client ensure that the solution (or proof of concept) is realized, what costs are involved in proving the feasibility, and what further steps can the client take to ensure that the solution is sustainable in the long term? What are the points of attention and risks (risk management/risk control), and are there any recommendations? It is also important to consider potential consequences and implications, as well as prerequisites such as legislation (including GDPR) and ethics.

Also, read this blog about the criteria of a good research report.


Flexibility and Communication in Research

Be aware that research is not a linear process. What you establish at the beginning of your research can change along the way. This also applies to the demands and wishes (requirements). Initially, you set these requirements in consultation with your client, but during the research, you can adjust them based on new insights you acquire. This can happen, for example, through conversations with experts, target groups, and other important stakeholders. Therefore, it is essential to know well who is important for your research so that you can accurately tailor the demands and wishes to their needs. Feel free to adjust or supplement requirements and other necessary information with valuable data during your research. This will enhance the quality of your research and enable you to support viewpoints, results, and conclusions with strong evidence more effectively.

It is, of course, important to sit down regularly, for example, once a month, with your client to discuss progress and any changes, such as in the requirements. In this way, you create support and keep your client informed of the progress. This can lead to new insights or suggestions that you can get from your client, which can further improve the content of your research.


Requirements and Quality Requirements

Be aware that requirements and quality requirements do not have the same meaning. Both terms, quality requirements and requirements, are often used in project management, product and service development, and software development, but thus do not have the same meaning:

  • Quality Requirements: These are the criteria that a product or service must meet to be considered of good quality. Quality requirements are usually broad and cover aspects such as reliability, user-friendliness, performance, safety, and so forth. They describe the general characteristics of the end product or service that the customer or user expects.
  • Requirements: These are specific functionalities, features, or performance that a product or service must have to meet the needs of the customer, client, and other stakeholders.

In short, quality requirements are more general criteria that define the overall quality of the end product, while requirements describe specific functionalities or features needed to meet those quality requirements and other demands.


Examples of Requirements

Below, we explore a selection of examples of requirements by criterion, bearing in mind that these are merely illustrations. Not all may find their way back into your research. Thus, it is imperative to always define your requirements in consultation with stakeholders.

Feasibility:

  • Technical Feasibility: The utilization of existing technologies to implement a solution.
  • Financial Feasibility: The available budget for developing and implementing the solution.
  • Operational Feasibility: The capability to integrate the proposed solution into existing systems and processes without disruptions.
  • Timeline Feasibility: Realistically setting deadlines and milestones for the project.
  • Resource Feasibility: Availability of personnel, expertise, and other resources required for executing the project.
  • Scalability: The possibility to adapt the solution to growing needs and size of the project.
  • Technological Infrastructure: Checking the availability and compatibility of the required infrastructure.
  • Legal and Regulatory Feasibility: Complying with laws and regulations related to privacy, security, and other relevant areas.
  • Risk Management: Identifying and managing potential risks that could hinder the execution of the project.
  • Availability of Suppliers and Partners: Assessing the availability and reliability of external suppliers and partners needed for the project.

Desirability:

  • User-Friendliness: The degree to which the solution is intuitive and easy to use for end users.
  • Customer Satisfaction: Meeting the expectations and needs of customers and stakeholders.
  • Functionality: Providing the right features and capabilities to meet the specific needs of users.
  • Flexibility: The ability to adapt the solution to changing demands and environments.
  • Aesthetics: The visual design and presentation of the solution to be attractive to users.
  • Performance: The speed, reliability, and responsiveness of the solution in use.
  • Accessibility: Ensuring that the solution is accessible to all users, including people with various abilities and limitations.
  • Compatibility: The interoperability of the solution with various devices, platforms, and systems.
  • Security and Privacy: Ensuring the security and protection of sensitive data and information.
  • Brand Reputation: Maintaining or enhancing the reputation and perception of the brand among users and the market.

Viability:

  • Market Potential: The size of the market and growth opportunities for the solution.
  • Competitive Position: The ability to compete with other similar solutions in the market.
  • Return on Investment (ROI): The return achieved through the investment in the development and implementation of the solution.
  • Long-Term Profitability: The sustainability of the earning model and profitability in the long term.
  • Business Scalability: The ability to scale the solution to new markets or target groups.
  • Customer Retention: The ability to maintain customers and secure their long-term loyalty.
  • Operational Efficiency: The ability to reduce operational costs and increase efficiency after implementation.
  • Risk Management: The ability to identify and manage potential risks that could threaten the viability of the solution.
  • Innovation Potential: The ability to continuously innovate and adapt the solution to changing market conditions.
  • Sustainability: The ability of the solution to generate positive social and environmental impact over the long term.

Good requirements are formulated as SMART as possible. SMART stands for Specific, Measurable, Acceptable, Realistic, and Time-bound. By formulating requirements in this way, they can be defined clearly, concretely, and feasibly, which is essential for a successful research report.


MoSCoW-methode

A clever method for prioritizing requirements is the MoSCoW method, which aids in classifying them based on their urgency and importance to the project. Incorporating requirements ensures that research focuses on meeting the needs of key stakeholders and that the final solution will be effective in addressing the problem. Furthermore, later in the Results chapter, it can be more easily demonstrated that the specified demands and desires of various stakeholders have been met, which can show that the desired effect with the created solution can be achieved.

Regarding the Moscow methodology: The MoSCoW method is a technique often used in project management and requirements engineering to determine the priorities of demands and requirements. The name “MoSCoW” is an acronym that stands for:

  • Must have: These are the essential requirements that absolutely must be present in the end product or solution. These requirements are crucial for the project’s success and constitute the core functionality.
  • Should have: These are important requirements that are strongly recommended to include in the end product or solution. Although they are not essential, they significantly contribute to its value and usability.
  • Could have: These are optional requirements that are desirable but not critical. They can be included if there is sufficient time and resources available but can also be deferred to later versions of the product.
  • Won’t have (at this time): These are requirements that are consciously excluded from the current scope of the project. They will not be implemented in the current phase but may be considered in the future.

By categorizing the requirements based on these four levels, the MoSCoW method helps project teams and stakeholders to gain clarity on what is essential and what is optional, thereby allowing them to better prioritize and make decisions about the project’s scope. This contributes to effective resource allocation and helps to meet the project’s key objectives.


Effectively Stating Requirements

Stating requirements in a research report, account, or thesis, as indicated above, is of essential importance to provide clarity about the expectations and criteria to be fulfilled. Below are some steps described in a bit more detail that you can take to mention requirements effectively:

  1. Identify the Requirements: Analyze the needs and expectations of the client, stakeholders, and end-users to identify the requirements that should be included in the research.
  2. Be Specific: Formulate the requirements as specifically and measurably as possible. If possible, use quantitative measures to define the requirements.
  3. Organize the Requirements: Structure the requirements into categories or sections to make them easier to understand and follow. For example, this could be per functional area or per stakeholder group.
  4. State the Requirements in the Introduction: Include a section in the introduction of the report where the main requirements are listed. This gives the reader an overview of what is expected from the research.
  5. Substantiate with Literature: Support the stated requirements with literature or relevant sources to emphasize their necessity and validity.
  6. Clarification in the Methodology: Describe in the methodology section how the requirements were established and validated, and which methods were used to collect and analyze them.
  7. Include in Results and Discussion: Discuss in the Results and Discussion sections how the selected solution meets the requirements. If possible, provide evidence or examples to support this evaluation.
  8. Reflect in Conclusion, Recommendations, and Implementation Plan: Reflect in the conclusion and recommendations sections on the extent to which the requirements have been met and make recommendations for any follow-up steps to address potential shortcomings. Additionally, include the requirements in an implementation plan to offer a clear strategy for the practical execution of the project.

By following these steps, mentioning requirements in a research report, account, or thesis can help to improve the relevance, validity, and usability of the research.


SOURCES

This particular blog post was inspired by the books listed below. It should be noted that the original language of the sources used was Dutch.

 

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

Leave A Reply

Your email address will not be published. Required fields are marked *