Soft audit practice・Audit day 8: Requirements management check points

28/01/202121/10/2021Audit for soft-Develop..

 Requirements management confirms whether the development contractor and the development contractor are aware of each other.

In this article, following the previous article, I will introduce the points when auditing using the checklist for requirements management , which is the second of the four checklists for software development auditing . As with the development process checklist, for each check item, software audit practice / checklist No. 8: Development technology / requirements management (general management) Software audit practice / checklist No. 8: Development technology / requirements management (management) Since it is introduced in the article ( general) , if you are interested in specific items, please see that article first.

Below is an example of the checklist, so please read the article while also looking at it.

The requirements management checklist has a different purpose than the other three

Among the software development audit checklists, the requirements management checklist has a slightly different purpose than the other three. The other three checklists are aimed at understanding the software development capabilities of the audited company. Regarding requirements management, there is also the purpose of grasping the ability to grasp the requirements specifications of the audited company (requirements management ability), but there is a higher priority purpose than that. It is to confirm whether our company and the development contractor agree on the required specifications (whether the requirements management is done properly) .

Such a thing will not be carried out by software development audit, but will be carried out by the company’s design department that outsources development with the development outsourcer! It seems to be said, but, yes, that’s exactly what it is. However, if the development contractor is overseas, it often happens that there is a discrepancy in the recognition of both parties unless the non-functional requirements are carefully confirmed. There is no problem with organizations that are accustomed to outsourcing software development to overseas companies, but since the organization that my father Gutara was working on had little experience, there was a considerable gap in recognition and I had a hard time.　

Therefore, the item called requirement specifications is included in the confirmation items of the software development audit. Those who are accustomed to outsourcing software development to overseas companies should skip this part, but those who are not so should read it to the extent that there is such a thing. ..

Why is there a difference in recognition of required specifications from overseas companies?

It’s a little sideways, but why is there a discrepancy in recognition of non-functional requirements in requirement specifications with overseas companies? This is because the environment in which the product is used varies from country to country and region, so there is a discrepancy in the common sense about how to use the product, saying , " This is the natural way to use it."

Here’s one easy-to-understand example that Father Gutara experienced. A few years ago, I went to an overseas company that outsources the development and manufacture of modem terminals for a software development audit. When I was checking the contents of the test, I was checking the specifications of the long-time energization test to check the stability of the modem terminal . There are various acceleration conditions for the stability confirmation test by energization, but the simplest is the test that keeps energizing for a week or a month under normal usage conditions.

At that time, Gutara’s father decided on his own criteria that the energization test should take at least 7 days, and proceeded with the software development audit. However, neither the test leader of the audited company nor the software development leader understands the necessity of the 7-day energization test at all. They ask me over and over again, " Why do you need such a test? “

Through it until the confirmation of the exchange of audit checklist, they never testing and software development does not mean low skill We know that. We also know that we have strong aspirations, such as actively incorporating the opinions of others in order to improve our products . They didn’t understand the need for a 7-day energization test and had been discussing for more than 10 minutes. While discussing, Father Gutara had a feeling that something was wrong or something was wrong, but due to the language barrier, it was difficult to find that difference.

However, at a certain timing, the development reader said, “The modem will be turned on when it is used and turned off when it is finished. This modem is designed for personal use at home, so it seems that the power has been turned on for more than a day. There is no way to use it, and it starts from the startup process every time, so a long-time energization test is meaningless, is n’t it? " As Gutara’s father, he lost the word, “What ???"

Natural quality varies from country to country

That’s right, in Japan, at that time, the Internet was always connected normally , and the modem was left alone after turning on the power at the time of installation , and it continued to operate normally and stably in one corner of the room 24 hours a day, 365 days a year. The usage was very normal. Since such usage is common sense, products that hang in a few days after turning on the power are not accepted as products in the first place. It is, rightly it is the product have called modem continues to move much more stable Once turn common sense quality Re also is thinking is. In the world of quality, it is an area called " natural quality “.

However , even in Japan, going back a little, there was an era of pay-as- you- go communication , and at that time it was natural for both personal computers and modems to “turn on the power only when using it and turn it off when it is finished ." In such a case, the “natural quality" is that it keeps operating stably for several hours from when the power is turned on until when the power is turned off . And the communication situation in the country of the development contractor at that time was exactly that situation.

In other words, what the test reader and development leader said was correct in the modem usage environment of that country, and what Father Gutara said was correct in the Japanese modem usage environment. In both cases, I couldn’t think of the communication situation in the other country, so I decided on my own common sense and searched for the optimal answer, so even after 10 minutes of discussion, I was following parallel lines.　

It’s a funny story once you understand it, but everyone has a habit of thinking about things within the framework of common sense in the world in which they live . And, if you don’t pay attention to common sense, you won’t bother to write it out in the specifications. Here, the pitfalls of recognizing the required specifications are sometimes open.

Since that happened, I decided to add a requirements management checklist to the software development audit checklist after that to check if there is any discrepancy in recognition of non-functional requirements.

How to use requirements management checklist

The side street has become quite long, but I hope you understand the purpose of the checklist for confirming the required specifications. In short, it is necessary to confirm whether the quality that is commonplace in the market where the product is used is clearly stated in the requirements specification as a non-functional requirement, and whether the content is recognized by us and the development contractor. Is the purpose of the requirements management checklist.

That is, as a major premise, it is necessary that the non-functional requirements are properly written in the requirement specifications etc. created by the department of our development contractor . Regarding the non-functional requirements written there, we will confirm in order that our company and the development contractor agree. I want it to be, but I wish it was … It’s not! !! !!

Unfortunately, the company that Gutara’s father worked for had little experience in outsourcing software development to overseas companies, so it was often the case that non-functional requirements were not fully written out. With this, it is not possible to take the method of confirming the difference in mutual consciousness based on the items written in the requirement specifications.

Since there is no help for it, in the checklist of requirement materials, list items that are non-functional requirements and are likely to be forgotten to be specified, and at the same time as sending the checklist to the audited company at the audit preparation stage, development consignment We also sent it to the original development department of our company and asked both parties to describe their respective perceptions of the checklist items.

Ask the development department of your company to write “what specifications do you expect the product to be completed" for the items on the checklist, and ask the development contractor “what specifications do you plan to make the product with?" I got it written. By comparing the contents submitted by both parties one by one and identifying the parts with different recognition, the method was to check for omissions and recognition deviations in non-functional requirements items.

Precautions for checking requirement specifications using the requirements management checklist

As you can see from the explanation so far, in the confirmation using the requirements management checklist , both the contents written by the development contractor department of the company and the contents written by the development contractor are compared . I will check if there is a difference in recognition.　

For the items described in the requirement specifications provided by our company, we will ask you to explain how the development contractor implements the items and what kind of test will be used to confirm them. Compare the content of the explanation with the content described in the requirement specifications to confirm whether the development contractor correctly understands our requirement specifications.

Since the software engineer who wrote the requirement specifications is the person who outsourced the development of the company, it is not so much for the auditor who is an employee of the same company to understand what kind of thing is required by reading the sentence. It’s not difficult. However, engineers at the outsourced company may misunderstand the content based on different common sense . Therefore, listen to the specific implementation and test contents and check if the contents are different from the contents of the requirement specifications.

For items that are not described in the requirement specifications provided by us, there is a possibility that the specifications have not been specifically communicated to the development contractor, or in most cases they have not been properly communicated. In such a case, it depends on the form of the development consignment contract, but in many cases the development consignee is proceeding with the implementation based on its own standards . In this case, there may be a discrepancy between the specifications expected by the development contractor and the specifications implemented by the development contractor, so it is necessary to confirm that.

Check each required specification as specifically as possible

First, explain the contents of the audit checklist by the development consignment department to the development consignee as specifically as possible. And, although the development contractor requests such specifications, is there any discrepancy between the implementation content and recognition of the development contractor ? I ask. If there seems to be some kind of misunderstanding, we will ask you to discuss the item carefully with the development contractor and eliminate the misunderstanding.

Functional requirements and non-functional requirements are described in the requirement specifications, but there are almost no omissions in the functional requirements. However, non-functional requirements include 　several sub-categories such as performance, stability, abnormal recovery, maintainability, high load tolerance, maintainability, and availability , and these may be omitted. If you do not recognize the items that are missing, various problems will occur after the product software is completed. Although it is slightly different from the purpose of software development audit, it is important to eliminate the recognition deviation of specifications as much as possible at the time of audit.

Next to requirements management is confirmation of test technology

These are the points that Father Gutara was careful about when auditing requirements management. The software development audit work confirms the specific rules and actual work one by one according to the software audit checklist, and summarizes what viewpoints were taken into consideration when proceeding with the confirmation work. We hope that it will be helpful when you evaluate software development contractors.　

In the next article, I will introduce the points to note when auditing test technology in software development audit.