Requirement Breakdown Structure (RBS)

We know that to completely and clearly document requirements at the beginning of a project has never really happened. The problem is not with the process. The problem is that the world and our brain are not static. It never has been and never will be. There must be better ways. And there are! So, requirements should be developed such a way that are changeable and manageable. In this post I’ll try to share requirement development technique or Requirement Breakdown Structure, the foundation of all great project management.

Basically in requirement phase we do the following activities:

• Identify the source of requirements
• Take preparation for requirement collection
• Collect the requirements
• Develop the requirements
• Verify and validate the requirements

Requirement breakdown is the part of requirement development activity. But this is a challenge for ensuring that requirement breakdown is good enough or understandable and manageable, because breakdown of the requirements vary person to person.

In my opinion the best way to break the requirements is, keep it small, define the acceptance criteria of each requirement, define the relationship between requirements and then encourage the users to correct, improve and baseline them. Acceptance criterion is the key technique here. Try to write the acceptance criteria for each of the requirement then you will see requirement will be automatically small, understandable and manageable.

Rework effort in SELC

Rework is an ongoing problem in software development. As per SEI (Software Engineering Institute) report it has been indicated that 60-80% of the cost of software development is rework effort. This effort is used to correct defects associated with base-lined work-products. Unfortunately, the reason is a gap between the state of the art and the state of the practice of software engineering.

In SELC (Software Engineering Life Cycle) all out put is treated as work-product. E.g. Project Plan Document, Requirement Specification Document, Source Code, Test Specification, Test Report, Release Note etc. And when a work-product is approved or validated by the relevant stakeholders for using next level users than it called base-lining.

Common causes of re-works in SELC:

1. Requirement Analysis Gap (main root case of rework)
2. Wrong Software design (e.g. performance issue not considered in the design)
3. Poor Code development (e.g. features not developed as is software design)
4. Inadequate Test Case development (e.g. insufficient test cases for each requirement)

Despite successes in reducing rework, it is generally accepted that rework cannot be eliminated entirely. However, rework effort can be reduced by taking process improvement. For example:

• Introduce or improve the formal review process in requirement, design and coding phases. [If formal review is implemented then defect will be identified from the earlier stage of SELC, it will reduce rework significantly.]
• Integrate test cases with requirements [if each test case is mapped with requirements then it will be easier to measure that sufficient test cases is developed/not to test that requirement]
• Conduct Inspection [periodical inspection on work-products and processes implementation helps to identify defects as well as increase the consciousness of project team members to develop quality work-products and follow the processes]

Therefore, to reduce the rework effort it is required the use of disciplined engineering practices by skilled software engineers.

CSQA Examination Overview

The four and a half hour examination consists of four written parts, including multiple-choice and essay questions. A typical CSQA examination is comprised of two parts for Quality Assurance Theory and two parts for Quality Assurance Practice:

Quality Assurance Theory
Part 1 Approximately 50 multiple-choice questions Complete within 45 minutes
Part 2 Approximately 10 essay questions Complete within 1 hour, 15 minutes

Quality assurance theory evaluates your understanding of quality principles, practices, vocabulary and concepts. In other words, do you have a solid foundation in quality basics? For example, can you differentiate between quality assurance and quality control?

Quality Assurance Practice
Part 3 Approximately 50 multiple-choice questions Complete within 45 minutes
Part 4 Approximately 10 essay questions Complete within 1 hour, 15 minutes

Quality assurance practice evaluates whether you can apply quality basics to real-world situations. For example, a question may be: “What methods of quality control would you use to reduce defects for a software system under development? During which phase of development would you use those methods?”


This certification requires candidates to demonstrate skills in the following Categories:

1. Quality Principles and Concepts


2. Quality Leadership


3. Quality Baselines (Assessments and Models


4. Quality Assurance


5. Quality Planning


6. Define, Build, Implement and Improve Work Processes


7. Quality Control Practices


8. Metrics and Measurement


9. Internal Control and Security


10. Outsourcing, COTS and Contracting Quality

For a detailed explanation of each category, please click here

Requirement Quality Measurement

Requirements engineering deal with elicitation, analysis, communication and validation of the requirements. As early as errors are identified it is easy to fix them compared to later identification of errors. It is obvious that the cost of fixing these errors in initial stages is lower than fixing them in later stages of software development. In order to eliminate errors there should be some measurement. Metrics provide a quantitative measurement of certain attributes.

We know the main quality parameters of requirements are: Understandability, Completeness, Testability and Volatility. Metrics of these parameters can give us a quantitative measurement of requirement's quality:

1. Understandability: % of requirements is readable or understandable by the reviewers or next level users. Metrics is (Number of understood requirements) / (Total number of requirements). E.g. if total number of requirement is 40 and 30 requirements are understandable by the stakeholders then understandability of those requirement is 75%.

2. Completeness: % of requirements is complete (no item left to the requirement specification). Metrics is (Number of complete requirements) / (Total number of requirements). E.g. if total number of requirement is 40 and 35 requirements are complete then completeness of those requirement is 87.5%.

3. Testability: % of requirement is testable. Metrics is (Number of testable requirements) / (Total number of requirements). E.g. if total number of requirement is 40 and 38 requirements are testable then testability of those requirement is 95%.

4. Volatility: % of requirement changes. Metrics is (Number of changed requirement) / (Total number of requirements). E.g. if total number of requirement is 42 and 5 requirements are changed then volatility of those requirement is 11.9%.
Note: Change requirement = Modified requirements + New requirements.

Other requirement metrics can be developed as per the company need. GQM (Goal, Question, Metrics) is a popular method for metrics development.

Benefits of becoming a CSQA

(Source CSQA CBOK)

The CSQA program was developed to provide value to the profession, the individual, the employer, and co-workers. The following information is data collected from CSQAs in the IT industry – a real testimonial to the benefits and reasons to make the effort to become a CSQA.

Value Provided to the Profession
Software quality assurance is often viewed as a software project task, even though many individuals are full-time quality assurance professionals. The CSQA program was designed to recognize software quality assurance professionals by providing:

• Common Body of Knowledge (CBOK)
  The Certification Board defines the skills upon which the software quality assurance certification is based. The current CBOK has 10 skill categories.
• Examination Process to Evaluate Competency
  The successful candidate must pass a four-part examination that is based on the CBOK. You must receive a grade of 75%, or greater on each part. Only 31% of the pre-qualified applicants pass the examination the first time, making this a prestigious certification to obtain.
• Code of Ethics
  The successful candidate must agree to abide by a professional Code of Ethics as specified by the Certification Board.

Value Provided to the Individual
The individual obtaining the CSQA certification receives the following values:

• Recognition by Peers of Personal Desire to Improve
  Approximately, eighty percent (80%) of all CSQAs stated that a personal desire for self improvement and peer recognition was the main reason for obtaining the CSQA certification. Fifteen percent (15%) were required by their employer to sit for the examination, and 10% were preparing themselves for an improved quality-related position.
• Increased Confidence in Personal Capabilities
  Eighty-five percent (85%) of the CSQAs stated that passing the examination increased their confidence to perform their job more effectively
• Recognition by IT Management for Professional Achievement
  Most CSQAs stated that their management greatly respects those who put forth the personal effort needed for self-improvement. IT organizations recognize and reward individuals in the following ways:
  - Thirteen percent (13%) received an immediate average one-time bonus of $610, with a range of $250 to $2,500.
  - Twelve percent (12%) received an immediate average salary increase of 10%, with a range of 2% to 50%.
  Within the first 18 months after receipt of the CSQA certification, of the successful candidates:
  - Twenty-seven percent (27%) received an average salary increase of 23%, with a range of 2% to 100%.
  - Twenty-three percent (23%) were promoted, 25% received a better assignment and 13% a new assignment.

Value Provided to the Employer
With the need for increased software quality and reliability, employing CSQAs provides value in these ways:

• Increased Confidence by IT Users and Customers
  IT users and customers expressed confidence in IT to effectively build or acquire software when certified quality assurance practitioners were involved.
• Improved Processes to Build/Acquire/Maintain, Operate and Measure Software
  CSQAs use their knowledge and skills to continuously improve the IT work processes.
  CSQAs know what to measure, how to measure it, and then prepare an analysis to aid in the decision-making process.
• Independent Assessment of Quality Assurance Competencies
  The CSQA program is directed by a Certification Board of independent quality assurance experts. Through examination and recertification, they provide an independent assessment of the CSQA’s quality assurance competencies, based on a continuously strengthening Common Body of Knowledge for quality assurance practitioners.
• Quality Assurance Competencies Maintained Through Recertification
  Yesterday’s quality assurance competencies are inadequate for today’s challenges. CSQA recertification is a process that helps assure the CSQA’s skills remain current. The recertification process requires CSQAs to obtain 40 hours of quality assurance related training per year in topics specified by the Certification Board.
  From an IT director’s perspective, this is employee-initiated quality assurance training. Most, if not all CSQAs, do this training during their personal time. IT organizations gain three benefits from CSQA recertification: 1) employees initiate improvement; 2) quality assurance practitioners obtain competencies in quality assurance methods and techniques; and 3) employees train during personal time.

Value Provided to Co-Workers
The drive for self-improvement is a special trait that manifests itself in providing these values to co-workers:

• Mentoring the Testing Staff
  Forty-five percent (45%) of the CSQAs mentor their testing colleagues by conducting training classes; encouraging staff to become certified; and acting as a resource to the staff on sources of IT quality related information.
• Testing Resource to “IT” Staff
  CSQAs are recognized as experts in quality assurance and are used heavily for advice, counseling, and for recommendations on software construction and testing.
• Role Model for Quality Assurance Practitioners
  CSQAs are the IT role models for individuals with quality responsibilities to become more effective in performing their job responsibilities.
  

QAI, as CSQA program administrators, will assist you in this effort.
See www.qaiworldwide.org for detailed information.

Benefits of Defect Ratio Analysis

Measurement and Analysis is the key of process improvement or taking any decision. And Metrics is the most useful tool for Measurement and Analysis. A single Metrics can give us lot of information for decision making. In this post I have tried to explain the benefits of Defect Ratio analysis.

Defect Ratio is a measure as well as a metrics of defects against product size. If your product size is 500 Use Case Point and total number of defects are 200 then Defect Ratio is (200/500) = 0.4. We can analyze the defect ratios by calculating the defect ratio in different time period of a project.

Lets, one of an objective of our processes is to ensure that our defect ratio will be less then 0.45 and variation of the defect ratios will not be more then 0.1. Then in a project we have used those processes, calculated the defect ratios in different time period and plotted the following graph.

From the graph we can say:

1. The Process is not good enough to achieve the objective of ensuring the defect ratio <= 0.45


2. The Process is not stable or matured enough. Because, the variation of the defect ratio is more then 0.1 (0.54-0.35 = .19)


3. Project team is not skilled enough to make sure the defect ratio <0.45

We can also take decision from the graph to improve our processes or increase the skill level of our project team.

People, Process and Technology

We are always trying to do more in less time; that’s why new technology are inventing, software is one of those technology. Once upon a time it was thought that software development is fully depending on human creativity. But day by day it is proved that it is pure engineering function and that’s why process are being developed to run this engineering function. As a result effort is reducing on Human Resource day by day in software development.

But we are not happy on that, we want to develop good quality software in less time. For this reason we are using different tools to increase our productivity in software development. For example, we are using tools for code generation, code review, testing etc. which activities were fully done by people in early stage.





Now, it is proven concept that to compete and survive in the rapid changing software technology industry we have to use processes and tools to increase the productivity of the professionals. And those companies are doing well who have developed an optimized framework with People, Process and Technology/Tools.

In Bangladesh, we have talents for good code development, but we have shortage of process experts and we are weak in use of technology or tools. So, we have to focus in these two areas then software quality will automatically assure.

CMMI Instead of ISO 9001:2000

When a ISO 9001:2000 certified company goes for CMMI then definitely some questions raise into the practitioners mind, why CMMI instead of ISO 9001? Is CMMI better then ISO 9001?

There are numbers of documents available in the internet to give you clarification theoretically for those questions, but I want to share my own experience to implementing CMMI, where I also manage ISO 9001:2000 compliance processes.

• Primary focus of ISO 9001:2000 is customer satisfaction, whereas CMMI focuses on achieving organization goals. CMMI specifies Process Improvement (PI) should be done to achieve all of the organization goals.
• ISO standard description is very brief, where as CMMI model content is elaborate (better assists for process improvements). ISO requirements only ‘what’ should be done, but CMMI also specifies ‘how’ can be done.
• CMMI model has detailed information for institutionalization of processes compared to ISO contents on institutionalization. ISO is weak in institutionalization compared to CMMI (CMMI models' GGs & GPs assists for institutionalization).
• CMMI is strong in Training function, which is a very important function for any organization. Without continuous improvement of HR skill PI is very difficult. You know integration of People, Process and Technology can make an organization successful. ISO 9001 is not strong in this area.
• CMMI allows tailoring of processes. It is realistic, because for different type and size of the projects or functions same process might not be work.
• ISO requires only direct evidence from the practitioners as per standards which leads to disconnected process development and implementation. But CMMI requires both direct and indirect evidence from practitioners, which leads to develop integrated processes.
• ISO doesn’t deal with the performance of the processes, but CMMI do.
• ISO requires a MR (Management Representative), CMMI requires EPG (Engineering Process Group) which is more effective for PI.

But, for any ISO certified organization, it becomes easy to implement CMMI based process improvements as ISO brings good discipline on process approach.

You also might want to know exact mapping between ISO 9001 and CMMI. I don’t find any mapping document between CMMI V1.2 with ISO 9001. But on the SEI website, there is a document that shows the mapping between CMMI (V1.1 - the prior version) and ISO 9001. Here is the link: http://www.sei.cmu.edu/cmmi/adoption/pdf/iso-mapping.pdf
Another useful document on ISO 9001:2000-CMMI Synergy for Process Improvement is http://www.sei.cmu.edu/cmmi/presentations/sepg03.presentations/cmmi-iso.pdf