How can I create successful software

With requirements analysis for a successful software project


The requirements analysis should always be at the beginning of a software project. Because only when you know exactly how your individual departments work can you define how a software solution can not only support these processes, but also optimize them. And of course you can only indicate to a provider which functions a solution must contain with the results of a detailed requirements analysis. Analyzing your own workflows critically and looking for potential for optimization poses challenges for many companies, but it is the key to successful software implementation.

What is a requirements analysis?

A requirements analysis can basically be used for every project and is essential for IT projects and software implementations. The aim is to determine, specify and structure all the requirements for a planned project.

What is a requirement?

A requirement is a clear, documented, physical and functional necessity that a particular design, product or process must be able to carry out.

The requirements must also be checked for technical and economic feasibility. The results of the requirements analysis are usually documented in a specification sheet.

Why should a requirements analysis be carried out?

A thoroughly carried out requirements analysis prevents a software project from failing or the planned budget being exceeded because requirements change afterwards or cannot be implemented by the provider himself. It forms, so to speak, the foundation for all decisions relating to the project, system architecture, contract drafting or communication internally or between the provider and your company.

It is not just a matter of formulating requirements, but of being able to check at an early stage whether they are technically and economically feasible.

Another advantage is that a requirements analysis helps to create a common consensus. Include the right stakeholders and users in the planning right from the start, increase software acceptance and avoid unnecessary features. In addition, you can use a requirements analysis to identify structures and processes with optimization potential.

With the right requirements management, you can keep an eye on your goals for your project. They ensure that software meets the needs of the user and optimally supports them in their work. You also take into account the input of all stakeholders and user groups through the analysis.

How do you carry out a requirements analysis?

Identify your stakeholders for the project

The introduction of software will change the daily work methods in certain areas of your company. For example, by introducing a CRM solution, you interlink departments such as marketing, sales and service more closely with one another or manage resources via an ERP system using a central tool instead of many different ones. Each department has different work processes and different demands on the software. In addition, there are technical IT requirements, the interests of management and, if necessary, legal concerns of the data protection officer.

The various interest groups need to be identified and included in the requirements analysis. In this way you ensure that your project is not over-planned based on the individual needs of the users.

The as-is analysis or inventory

The as-is analysis should be carried out before the requirements analysis. Here you examine the internal work processes in all departments, how they run step by step in detail. This inventory should be as detailed as possible and can therefore take several months.

For example, if you want to introduce new CRM software, you should ask yourself the following questions for the as-is analysis:

  • When does which department come into contact with customers via which communication channel?
  • Which processes are used for service inquiries, complaints, maintenance orders, orders and product inquiries and who initializes them?
  • Where is information on customers, business partners, service providers, products and goods processed and stored? Which employees process this information with which access rights?
  • How are the entries from the field service, sales, independent sales representatives or the maintenance and repair service processed?
  • How are reporting, analyzes and evaluations created?
  • How does communication work internally and how is knowledge exchanged between employees?

You can read about which approaches are suitable for determining the current situation in our article on As-is analysis.

Which processes can be optimized?

After taking stock of the situation, discuss which processes have room for improvement and where. To do this, include feedback from all stakeholders, e.g. customers and management, in the requirements analysis. Consider anything that will help make your processes leaner and more effective.

Use different methods for employee surveys in order to collect as much information and suggestions for improvement as possible:

  • Structured interviews
  • Focus Groups
  • questionnaire
  • Moderated workshops
  • Online surveys
  • Reports from employees

The target state: from process to function

After the as-is analysis, you will know how your processes have run so far and what they should ideally look like. As part of the requirements analysis, you should use this as a basis in the target definition to describe in detail the individual functions that the software solution should map. Which entries in the system require which processing steps and how are the results displayed? When creating requirements, especially when introducing software, it is important to work with different levels of granularity. So first create a rough concept, e.g. on the basis of use cases (concrete use cases), and then work them out step by step in more detail.

Example: Status tracking of spare parts orders

A field service employee from the repair service records an order for the next maintenance date on the move. The colleague from the planning department sees this order and immediately orders the intended spare part.

The system uses a color-coded order status to show the sales representative that the required part has already been ordered.



  • Use cases should always be described consistently and in full sentences.
  • The name should indicate what the user wants to achieve.
  • Actors should always be named precisely: e.g. field staff from the repair service
  • Work steps of the actors and work steps of the system should, for example, be indicated by indent or another color.
  • The individual steps in the event flow are written in an active style to make it clear who is doing them.
  • The focus is on the activity of the user. The effect of the individual actions on the system should be described logically and clearly.
  • Use cases should not be longer than two pages.

What types of requirements are there?

In a requirements analysis, a distinction is often made between functional and non-functional requirements.

What are functional and non-functional requirements?

Functional requirements

Functional requirements directly affect the system to be developed or the software to be developed. These are necessary features, properties, functions, actions and interactions.

In a CRM, these could look like this:

  • Organization and management of contact details
  • Call and email integration
  • Management of tasks
  • Sales forecasts
  • Pipeline view for sales phases
  • Calendar integration

Nonfunctional requirements

Non-functional requirements relate to the framework conditions of a project:

  • Technical: hardware, programming languages
  • Interfaces: to existing systems such as ERP or DMS, communication, storage media
  • Quality of service: speed, storage space, reliability and maintainability
  • Support: version management, changes and further development, manuals and documentation
  • Usability: ergonomics, learnability, languages, presentation and help area

Evaluate every single process

After you have completely listed your work processes in the as-is analysis, the next step is the evaluation. Without question an extensive task. The more thoroughly you go at this point, the better you are prepared for future discussions with potential software providers. Therefore, clarify the following questions in the requirements analysis in the course of the target definition:

  • Is the process you defined superfluous?
  • Has the process been worked out optimally?
  • Can you make the process even more efficient?

Prioritize your needs

Once you have assessed your processes in detail, you can go one step further in the requirements analysis. Break down your revised processes into these three categories:

  1. Core processes: You cannot and do not want to do without these under any circumstances.
  2. Optional processes: You would like to depict this. The implementation depends on other factors, namely on
    1. the level of implementation costs
    2. the complexity of the implementation
    3. the actual feasibility of the processes
  3. Processes that cannot be changed: This can include a certain system that you have already firmly integrated into your company and are using. If you are planning to introduce a CRM system and are already using an ERP solution, the new software must provide an interface to the existing system.

If you use this method, you will know exactly what your core needs are. You can also specify the prioritization of the individual requirements later in the specification sheet. In this way, you can concentrate specifically on the providers who implement your requirements optimally while also adhering to your budget.

Responsibilities with different priorities

The prioritization of the individual processes is mainly the task of the key users. A key user is the person in the company who has specialized in the relevant software and is the first point of contact for the topic. They have the best insight into their respective specialist areas. So making a decision is relatively easy. However, some processes can run through several departments. There are two options here:

  • All departments agree on which processes are particularly important and must be implemented. The financial implementation is also within budget.
  • The requirements of the departments involved are very different, so that many processes should ideally find their way into CRM. However, the budget for implementation is limited. In this case, it is up to the next higher level of the company to make a decision as to which process is more important for the company. The decision maker can be the management, but also a superior project manager.

Developing the target state like building a house

Even if the analysis of the actual and the target state on paper are successive processes, they often blur with one another. In order to bring your requirements analysis to a successful conclusion, you have to make adjustments on an ongoing basis. As in building a house, the rule applies here too: “The earlier you make changes, the better and cheaper!” If your catalog of requirements is almost complete and you can think of extensive adjustments, it can be expensive. In the worst case scenario, you might even have to start from scratch.

From requirements analysis to provider selection

After you have defined, validated and consolidated the complete scope and target status of your perfect software solution in the requirements analysis, you can start looking for a supplier. You can then summarize the defined requirements in a specification sheet and send them to various providers. Read a detailed guide on how to create a CRM specification sheet