Soft Audit overview・Target 3: Audit the ability to grasp requirements

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

3.  In grasping development technology and requirements, check the status of recognition of requirements with the contractor.

In software development audit, we will confirm the quality of skill from the four viewpoints of development process, test technology ability, requirement grasping ability, and design / mounting ability. In this article, I will introduce the perspective of confirming the third requirement grasping ability.

The first and foremost important technical capability of software development contractors is the technology related to testing, which is the exit of deliverables from the contractors. The next important thing is the technology for grasping the requirements, which is the entrance to the outsourced work . If there is a discrepancy between the consignor and the subcontractor at the stage of grasping this requirement, the software will be out of sync with the request, no matter how firmly the subcontractor makes the software.

Definition of development requirements requires technical capabilities from at least one of the contractors and contractors

Since it is a matter of mutual understanding of the development requirements of the software to be outsourced, in other words, the required specifications, the original form is that the outsourcer writes out the requirements concretely and explains them concretely to the outsourcee. However, clarification of requirements is also an area where software development technology is required, and the contractor does not always have sufficient technology for clarification of requirements. In such a case, if the development contractor has the technical ability to materialize and clearly understand the requirements, it will be saved. However, if both the outsourcer and the outsourcer are inexperienced in the technology for clarifying development requirements, there may be a gap in the requirements somewhere in the finished software.

When outsourcing software development to another company, it is necessary for either the outsourcer or the outsourcer to know the technology in detail in all technical fields necessary for development, not limited to the technology that embodies the requirements. However, if neither the consignor nor the consignee is familiar with the technology, the software cannot be created. It’s not a difficult story, it’s a simple story that software can’t be done without knowing the technology required for development .

The technical ability to grasp the requirements is confirmed by matching the recognition of both the consignor and the consignee.

It’s a bit off the beaten track, let’s get back to the realization of development requirements. In-house development departments that outsource software development include teams with high technical skills to materialize requirements and teams with low technical skills. Development contractors may also have high or low technical capabilities to materialize the requirements. The main purpose of software development audit is to grasp and improve the competence of development contractors, but Gutara’s father is limited to development requirements, and concrete requirements management for both the in-house development department and the contractor, which is the contractor. I was judging the technical capabilities of the company.　

This is because both the contractor and the contractor guide the development project to check the development requirements with great care when the technical ability of requirements management is insufficient. Especially when the contractor is overseas, the recognition of the importance of non-functional requirements called natural quality may be significantly different from that in Japan, so it is necessary to be careful, but even if the development is outsourced to a domestic company, the software is soft. We cannot be relieved because our technical capabilities depend greatly on people.

As a specific method for confirming requirements management in software development audits, as a preliminary preparation for the audit, a checklist for requirements confirmation is sent separately to the development contractor and the development contractor, and the checklist is entered. I asked you to fill in the answer. The checklist contains items that confirm the specific content of non-functional requirements . Ask the outsourcer to be as specific as possible about the requirements they are looking for, and ask the outsourcer to be as specific as possible about the requirements they understand.　

If you compare the answers from both, they should match, but in reality, it’s hard to go and there are rare cases where there is a discrepancy between the consignor and the consignee, sometimes, rather often. I was awake. .. ..

Stability, abnormal recovery, maintainability, and robustness are likely to cause deviations in the requirements.

What kind of requirements do the contractors and contractors actually recognize? Specifically, it is described in detail on the explanation page of the checklist for requirements management, but the items that are likely to be misaligned in the requirements related to products are as follows.

• Stability　　: How long do you need to be able to run continuously, a day, a week, or a year?
• Abnormal recovery : Is the recovery policy from the error state self-reset or waiting for the operator?　
• Maintainability　　: What functions are required for recovery from defects and investigation of the cause?
• Robustness　　: Is it necessary to take measures against hardware failures (for example, failures in the FROM that records programs)?
• Security : What do security tests need?

If the contractor and the contractor discuss and agree on the contents of each item at the initial stage of development, it will not be so difficult for the contractor to design and implement the software. However, if the required specifications remain unclear and the contractor designs and implements according to their own natural quality and the content is different from the contractor’s idea, the basic structure (architecture) of the software will change. Some items are necessary, and it often takes a long time to correct them.

It is necessary to confirm not the requirements of the product itself but the requirements of maintenance service.

I used the term product requirements in the text above, but are there any non-product requirements? In fact, the vendor who provides the product must provide maintenance services for the product at the same time as the product . Maintenance to keep the product comfortable in the market, such as hardware failure, software function improvement version, and bug fix version, is a service provided separately from the product. The service may be provided free of charge or for a fee, but it is the vendor’s responsibility to clarify the content and method of providing the service.

When software development is outsourced to another company, it is necessary to conclude an agreement or maintenance contract with the development outsourcer regarding software maintenance so that the software maintenance service provided by the company can actually be provided to the user. I have. Specifically, it is necessary for the contractor and the contractor to agree on the following items at the same timing as the development requirements.

• Contents of maintenance service : What to provide, such as providing a function-improved version or a defect-fixed version, investigating the cause of a defect, etc.
• Maintenance service price : Free maintenance period / paid maintenance period, and what is the cost of the paid period?
• Demarcation point of responsibility　　　　: Where is the demarcation point of responsibility when a defect occurs in the market?
• Primary Investigator　　　: Who will investigate which responsibility is along the responsibility decomposition point?

These maintenance service requirements may have been forgotten in the early stages of development, so we checked them during the software development audit as well as the product requirements.

So far, we have introduced the requirements that are the entrance to the contractor and the confirmation of the test that is the exit from the contractor, so next is the actual software design and implementation that connects the entrance and exit at the development contractor. This is an introduction to the items to be confirmed regarding technical capabilities.