Building quality into a system means much more than only having a quality plan. Usually, the quality plan describes in details the degree to which our software suite possesses a desired collection of quality attributes. Your organization need to reach alignment around what top ten quality objectives you need to have and what they mean in your context. This way, you will be able to focus your efforts toward the right quality attributes.

A lot has been written on how to gather requirements, bring more details to these, transform them into specifications and then execute on these in one or multiple product development teams. Teams work based on a plan and follow usually Lean Agile or other methodologies. Common to all methodologies is that we can increase team productivity and ensure more compliance between what is requested and what is delivered. Anyway, many teams are still struggling with both system quality (call it number of bugs in the software), its maintainability and changeability. Many also struggle with the system matching to the market needs. They struggle with other words with the «built-in quality» of the product.

If you are interested in the quality attributes mentioned above, one good source of information is this page: Architecture Requirements are Ilities

The big question is: But, how can I ensure the built-in quality of my product is sufficient? The answer to this question lays in the knowledge we have gathered during many years of Software Product Development. 

The golden rule is: You need to be sure that you and your team understand and agree on the overarching guidelines for your Software product. The guidelines must at least cover:

• Product objectives: Describe the purpose of the product, why it should be developed and maintained, what benefits it brings to the market and business and how it will realize the benefits it promises.
• Architectural objectives: A good architecture is one that is good enough. That means it enables you to create your product, adds value to the end users and enables further enhancements and changes with the lowest cost possible. Such architectural vision must be modelled in both:

1. Business: how to categorize and componentize different functional areas. How do these interact with each other and in what order
2. Software: If the business architecture is done in a good way, the technical part should be an easy exercise to design and implement. All the major non-functional requirements should be enlisted here so there are no surprises on the way. Of course things may change, but if we have given this a thought before we start going, we might be able to change faster and in the right direction instead of firefighting most of the time. Someone has said «If you are firefighting all the time, you may feel you are living in hell». Avoid that!

• Constraints: As for architectural objectives, we also need to think about and categorize the constraints we may face.

1. Business: What are the frames we need to operate within and what limitations do we have? The constraints here should be derived from the Product Objectives in a clear and transparent way.
2. Technical: Technologies, Interfaces and systems to interact with, network topology, etc.

• People & Competency: This is usually the factor that gets very little attention but affects the quality of the products we develop enormously . We need to ask ourselves: What kind of team is available to create the product? Where are the team members located? How do we make sure they are not just a group of people working together, but become a team that pulls the wagon in the right and same direction? How do we build and improve the team knowledge both within the domain and the technologies to be used? Have we made sure we have an innovation buffer in our plans?

So far you can ensure that the preparation for product development is correctly set up. Let us now look on how to ensure it stays correct while you go the way! To ensure the built in quality is still in tact, you need to INSPECT everything. That means, the higher risk something has the more inspection should be applied so we reduce the risk. I believe it is impossible to identify all the unknowns. We have to expect changes, failures and just plan to deal with them. The plan should cover how to identify both risks related to business and technology and how mitigate them.

The inspections should cover:

1. Requirements: Product manager must ensure the relevance of the requirements all the time. This is valid for each development increment and iteration. The inspection should be done in cooperation with the some representatives from the market e.g. sales or real customers.
2. Specifications: Everybody believes “The devil resides in the details” and that is true. We need to rely on more than one source when translating requirements into detailed specifications. which means that the selection of user segments to interview is an exercise we need to pay attention to and make sure it results in correct understanding of the final results. I usually include end users in the inspection of the specifications together with the development team.
3. Architecture: There is a saying stating “All models are wrong”. Changes happen and models must follow and change accordingly. I usually, revise the models both from business and technical perspective before and after each iteration. Some of these inspections take minutes while others can take days. Anyway, the benefit is that we are sure we still deliver the value promised in the objectives of the product.
4. Code: Needless to say that we need to ensure the correctness, compliance and maintainability of the code all the time. Two heads are thinking better than one and four eyes covers a lot more than two eyes.
5. Testing: Testing should include both manual and automated testing and enables us to validate the compliance between expected and produced results from the software product. Test scripts should be handled as code and product documentation and should be inspected in the same way with the same seriousness.