Friday, September 29, 2023
HomeFeatureProceed with request definition that does not fail

Proceed with request definition that does not fail

Introduction 

Request definition is the work of a developer who develops software and a system to embody the outline of the system to be developed based on the request of the client (system ordering party).

There is a lot of software and applications around us, and often the news is about a malfunction in those systems. Why is there a problem that is widely covered? It may be just a human error or a human error during system development, but in reality, the root cause is that there are many cases where development is proceeding on the wrong assumption at the start of system development.

This time, I will introduce the failure of requirement definition and the trouble caused by it, and explain what to do to prevent it.

request definition
request definition

Many of the causes of system development failure are requirement definition failures

At the first stage of system development, the work of clarifying what the user wants from the system is called “requirement definition”.

n other words, in the requirement definition, the client conveys the image of the system they want to create, and the system developer specifically defines the functions and performance required to form that image.

There are many cases where failures at this requirement definition stage will end up in the future, causing various problems. If the requirement definition fails, it can be said that system development has already failed at that stage.

Why requirements definition failures lead to system development failures

Before explaining “why a failure in requirement definition leads to a failure in system development”, let’s explain in detail how system development is carried out in the first place.

Generally, when developing a new system from scratch, the work will proceed according to the following procedure.

  1. Requirement definition … Define the specifications that require the client’s request from the system.
  2. Basic design … Design the basics of the system based on the requirements definition
  3. Detailed design … Design the system in detail based on the basic design
  4. Implementation … Actually develop the system based on the detailed design
  5. Test … test if the developed system works according to the specifications
  6. Start of operation … Start operation when the test is completed successfully

As you can see from this flow, requirement definition is the work that is at the forefront of the system development flow. Therefore, failure at this stage makes it almost impossible to recover in a later process. If you compare it to a building, it is the same as building a building without failing at the stage of building the foundation.

What happens if the request definition fails

So what happens if you fail at the requirements definition stage? There are many possible causes, but the most frightening is security failure.

Failure in the security part will allow unauthorized access from the outside, causing actual damage such as leakage of confidential information and customer information.

In the worst case, it is possible to allow intrusion into the core part of the system, create a backdoor (information loophole) in the system, and information is constantly being extracted from it. There are many cases where the system itself is destroyed.

Even if there is no problem with the security of the system being developed, difficult-to-understand specifications may cause security accidents such as leakage of internal information.

Sometimes it is necessary to reject the client’s request

Why do requirement definition failures occur?
It’s possible that the system engineer isn’t competent enough to do the requirements definition work, but if it isn’t, it’s most likely caused by a lack of client awareness.

In recent years, ICT literacy has permeated society as a whole, but it is not sufficient. This is because there are often cases where the client-side requirements for system development are too “rough”.

Clients who lack awareness of the system, request various requests from the system developer, such as “I want to do something like that” and “I want you to do it this way.” However, because we don’t have an image of the finished system, we sometimes make inconsistent requests.

It is the job of the system developer to manage to put together the client’s requirements, but in reality, the client often does not distinguish between “really necessary functions” and “merely thought-provoking functions” that are related to the fundamentals of the system. .. Therefore, we must start by organizing the necessary functions and those that are not.

As a result of the arrangement, there may be a discrepancy between the function that comes to mind and the function that is important. In such cases, the latter must, of course, be prioritized, and system developers need to gain the client’s understanding of that.

In addition, there is something called “common sense” in system development, and it cannot be ignored. For example, when developing a system that requires high security such as electronic payment, it is now common sense to take strict security measures such as two-step verification. The system developer must suggest if necessary, even if there is no such feature in the client’s request.

When defining requirements in this way, it is natural to make efforts to maximize the requirements, but in some cases, it is necessary to reject the unreasonable requirements of the client or propose functions that are not in the requirements. It doesn’t become.

Clients and system developers are a fateful community

Clients who lack awareness of the system, request various requests from the system developer, such as “I want to do something like that” and “I want you to do it this way.” However, because we don’t have an image of the finished system, we sometimes make inconsistent requests.

It is the job of the system developer to manage to put together the client’s requirements, but in reality, the client often does not distinguish between “really necessary functions” and “merely thought-provoking functions” that are related to the fundamentals of the system. .. Therefore, we must start by organizing the necessary functions and those that are not.

As a result of the arrangement, there may be a discrepancy between the function that comes to mind and the function that is important. In such cases, the latter must, of course, be prioritized, and system developers need to gain the client’s understanding of that.

In addition, there is something called “common sense” in system development, and it cannot be ignored. For example, when developing a system that requires high security such as electronic payment, it is now common sense to take strict security measures such as two-step verification. The system developer must suggest if necessary, even if there is no such feature in the client’s request.

When defining requirements in this way, it is natural to make efforts to maximize the requirements, but in some cases, it is necessary to reject the unreasonable requirements of the client or propose functions that are not in the requirements. It doesn’t become.

Clients and system developers are a fateful community

Even if you reject the request, some clients say, “We will pay you, so make it exactly.”
However, it is very dangerous to swallow it just because the client requested it and implement it as it is.

There is always a user in the system, and in some cases, accepting the unreasonable demands of the client can cause great damage to the user.

For example, in the case of a system such as online banking, if there is a security vulnerability, the information of the customer who is the user may be extracted, and in some cases, the deposit data may be tampered with and the user’s property may be lost. In the event of such a serious accident, the client company loses its social credibility.

It is also for the client to reject the request from time to time.
Also, in the cases mentioned above, the criticism is directed not only to the client but also to the system developer who developed the system according to the request. In short, clients and system developers are a fateful community.

In conclusion

As mentioned above, request definition is not unilaterally listening to a request. To build a truly reliable system, we need to make our clients understand it. And it’s late after entering the requirement definition, and it’s important to make a major premise before entering the actual requirement definition.

The relationship between a system developer and a client is similar to the relationship between a construction company and an owner. No matter how much the customer pays, he cannot accept the order of the person who demands illegal construction.

You can increase the reliability of the system by paying attention to the requirement definition. At the very least, you don’t have to cause “accidents that you wouldn’t normally have to do”. As a result, the quality of the completed system will be high, and it will be possible to create a highly reliable system, which will lead to higher customer satisfaction for the client company.

If you ever want to know about similar things, check out the Facebook page Maga Techs

RELATED ARTICLES
Recommended

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Recent Posts

Most Popular

Recent Comments