Requirements in IT projects

Requirements - from need to effect

Do you work with requirements management in your organization?

"Yes of course", answers some.

"Well, I don’t know" answers some others.

"What’s that?" ...answers some more.

Requirements management is a very broad concept and there are almost as many ways to attack this phenomenon as there are organizations. We have all the requirements, both in working life and in private, but are we always so aware of the requirements we make, and above all why?

Requirements or needs - utility based development

As a requirement manager, you sometimes need to analyze and differentiate between "what the customer wants", "how the buyer wants it" or "what the customer wants to achieve". The difference may be tough, but it may also be so great that it leads to erroneous decisions, investments and investments. Let us make an interpretation of what these different queries can have for consequences:

1. "What do you want?" - Asking a customer / end user what they want may lead to this being creative solution-oriented, i.e. describe the solution they want to deliver in a very concrete way. This means that the person to deliver becomes more passive in his creativity and does not adequately analyze the consequences of the solution.
2. "How do you want it?" - This question is to some extent somewhat less passive from the supplier, as it suggests that you care about how the client / end user wants to experience the solution to be delivered, that is, some kind of acceptance. However, the question still indicates an answer that is solution-oriented.
3. "What do you want to achieve?" - Here you try to get to the bottom of the problem, and requires the client / end user to describe the underlying goals, purposes, and needs that led to a change solution. This leaves an opening for a creative dialogue between clients and suppliers, where both areas of expertise can meet, to work out the best possible solution that gives the greatest benefits.

Requirements that can be followed up

We at NCP of course think that the third option gives the absolute best end result. Not least because it is the only option that allows a meaningful follow-up, as you can only measure the effect of a change if you describe in advance what purpose and the desired usefulness is. A solution-oriented claim allows, unfortunately, that you can only "measure" that you delivered the agreed product or service. Not the benefit of it.

This principle can be used in both large and small contexts. You can always ask the question "Why?" And outline real needs, sketch solutions and analyze consequences. If you forget to ask the question "Why?" The risk is great that at best you do things correctly, but above all you fail to do the right things.

We call these principles for utility-based development. We at NCP want to help our customers achieve!

NCP offers expertise throughout the entire chain of requirements

The requirement strategy - the foundation that everyone can hold on to

In order to carry out collaborative work in a structured way, one should establish a form of requirements strategy. The strategy is used to set the framework and guidelines for when and how to perform the requirements work.
With a common strategy you can achieve benefits such as:

Faster startup of projects - You do not have to invent the "wheel" all over again in any new project. Methods, tools, resource requirements, roles and quality requirements are already specified in the requirements strategy.

Confident employees in both project and the line organization - People who work actively with requirements management can be trained continuously and gain experience in the enterprise's requirements management process - its methodology, tools and accumulated experience.

Personnel from the line organization, who can take the role of claimants and reviewers during development, can be introduced quickly to their commitments.

Project managers know directly how to control, follow up and report the collaborative work in development projects.

Continuity and Recycling - By creating management of both the requirements process / methodology itself and the results of completed projects, you create the conditions for continuous improvement of your workflow and recycling business models (processes, information, IT requirements, etc.) for faster and more secure work.

A claim strategy can define or, in the simple case, demand requirements supporting phenomena such as:

  • Portfolio Management
  • Project Office
  • Enterprise architecture
  • Method Support

Requirements work

Types of Requirements - Overview

  • Application
  • Activity
  • Business Requirements
  • Process Requirements
  • Information requirements
  • Tool Requirements
  • Resource Requirements
  • Functional demands
  • Non-functional requirements
  • Technical platform
  • Technical requirements
  • Person
  • Experience requirements

As the points above show, there are a variety of types of requirements. Different types of requirements also come from different target groups, each of which has its specific perspective on what is going to change.

Stakeholder Analysis

Stakeholder analysis is therefore an important starting point for requirements work. It's easy to forget about important aspects of development work if you do not know which people will use the finished product. You need to know what they know, what they do and what tools they use. Based on this, you can then structure the requirements so that they become clear and useful for development, management and end users.

Agile or traditional - we implement and support

NCP's requirements consultants all have long experience of working in different types of change projects, both with traditional development methods and with modern agile methods. Most of our requirements consultants are also certified Agile / Scrum Masters, and some also have experience in implementing method support and coaching when introducing agile methods or by different requirements management techniques in general.
Examples of work we perform, support and facilitate:

  • Output Mapping
  • Process Modeling
  • Concepts Analysis
  • Information and data modeling
  • Workshops for functional and non-functional requirements
  • Risk Analysis
  • Revenue / cost analysis
  • Priority for development requirements
  • Iteration planning

Own developed or procured

We also handle requirements depending on whether they will be used for procurement or for own development. The basic work is the same, but there may be differences in expression, format and presentation. In addition, procurement often includes some form of market overview where you work with study visits at reference installations, evaluation criteria and customization needs for your own processes.