The Requirements Are the Most Important

During my work, I noticed that the requirements are a big problem. The difficulty is not to write them down. It is difficult to articulate them. I omit the turbulence associated with the purpose of the conversion or construction of the system. You do not always need to know why the system changes. I joked :-). You need to know. Today, however, not about it. I want to write about sensible requirements engineering.

I would like to share some important principles that I hope will help establish an effective basis for modeling requirements. I will try to make it correct :-).

Start with the business model

Draw a business process. If you are doing a small change, go down to the system level. If larger (eg: replace the system), raise the level of abstraction. Add requirements to the process activity. Specify in them what the system must do to support this step of the business process. If you have a system-level model then you start creating requirements for the system. If you have added requirements at a higher level of abstraction, you may be creating business requirements. The important thing is that you begin to narrow down the perspective of looking at the system and you are slowly refining details.

Business representatives are needed

Project stakeholders should communicate their requirements, prioritize them and make a decision in a timely manner. It is important that project stakeholders understand this concept and are involved from the beginning of the project. It’s nice how the business process has its owner. Then he becomes a key stakeholder. Project stakeholders are the only source of requirements. Yes, developers can suggest requirements, but stakeholders must accept these suggestions.

Software without requirements is a waste of time

If there are no requirements, there is nothing to build. The goal of Software Development is to build a working software that meets the requirements of the project’s shareholders. If you do not know these needs, you cannot succeed. Your system must be based on requirements, as a whole, on requirements, and nothing else as required. You can define the requirements using use cases, BPMN diagrams (at various levels of abstraction), screen mockups, descriptions, etc. You have to force / persuade business representatives to say what they want to have. They have to do it in such a way that it becomes clear to all parties why we do it.

The goal is mutual understanding, not documentation

The primary goal of the requirements gathering process is to understand what stakeholders want. Whether you create detailed documentation describing these requirements, or perhaps only a collection of handwritten sketches or notes, is a completely different matter. What counts is understanding.

Models are for everyone

If you build requirements models, show them publicly. Models are an important part of communication channels, but they only work when people see and understand them. I deeply believe in the concept of public disclosure of models so that everyone can access them and be able to work with them, even if they are only sketches or hand-drawn mock-ups. That’s why…

Modeling makes more sense when models describe the system from multiple perspectives

Requirements relating to the system are usually complex, as they quite often cover many issues. As each model has its strengths and weaknesses, no single model is enough; therefore, you will need several types of models to be able to do your job. It is worth assigning requirements to elements on models. You can combine the requirement (except use cases) with the business process activity, screen, class, component. You can bind requirements with each other. Please note that …

Excess mappings are also harmful

Keep moderation. You need several types of mappings. When you repair something at home, you use only a few of your tools, such as a screwdriver and a wrench. The next time you fix something, you can use other tools. Even though you have many tools, you do not use them all at once. The same is with Software Development: Although you have several techniques in your “intellectual toolbox”, you only use the project for a given project.

Use simple, general tools and techniques

It is possible, and even desirable, active participation of people interested in modeling. Nevertheless, project stakeholders do not usually know modeling techniques or complex modeling tools (eg Enterprise Architect). One option is to devote a few months to training stakeholders on modeling techniques and tools, but a much better approach is to use simple tools such as white boards and sheets of paper, and simple modeling techniques. Simple tools and techniques are easy to learn, which is why they are general – everyone can work with them. Do not scare people with technology if there is no need. After agreeing the shape and scope of the change / system, you can use Case tools and create a system specification in them. At the stage of creating requirements, tools such as Enterprise Architect are just a dead-end.

Requirements change over time

People often do not know what they want – and if they know, they usually do not know how to pass it on. What’s more, people change their minds – quite often you can hear the shareholders say “Now when I thought about it …” or “That’s not what I meant”. What is worse, the external environment is also changing – maybe your competition has announced a new strategy, or the government has passed a new law. Unfortunately this is the case. If you have requirements mapped to other elements, you will quickly “cover” the scope of the change.

Most requirements should be independent of technology

I shudder when I hear terms such as “object-oriented”, “structural” or “component-based” requirements. All these terms are categories of implementation technology and therefore reflect architectural and design issues. The requirements should specify what (what functions) we expect from the system. They must be written in the language used by business. Nevertheless, we do not create software in a vacuum. It is important to be aware that some requirements, such as technical constraints stating that your system must use standard J2EE technologies and the relational database used in your organization, are really depending on the technology. Your shareholders must understand when it is applicable and why.

I hope that these 10 tips will make your requirements management process more user-friendly. Good luck 🙂

More from my site

  • User Stories vs Requirements When writing any specification of requirements and the product register and sprint register, non-functional requirements should be included in this specification. While the user's […]
  • Requirements Documentation Requirements specification is a systematic representation of a set of requirements for a system or component that meets specific criteria. Requirements are like contract. All […]
  • Business Requirements vs System Requirements There is a lot of talk about the need to identify project goals, organization goals and the need to identify business and system requirements. All in order to better understand the […]
  • Requirements Documentation Based on Use Cases Use cases are used to document the functionality of the system and are based on two commonly used concepts: Use case diagrams Specifications of use […]
  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]

Leave a Comment

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

Scroll to Top