Posted on

Horizontal traceability shows relationship among related items such as between requirements itself. It traces dependent items within a development phase. Vertical traceability is a characteristic identifying the source of requirements typically from requirements to design, to the source code and to test cases.

Horizontal traceability is an aspect identifying non hierarchical similarities, mutual properties, interactions, etc. among requirements and work products. For example assume we want to implement a login function in four different types of browsers. There are four sub teams to do this. Here the functional requirement remains the same. If any change in requirement happens, then it needs to be reflected across all the four browsers. These kind of dependent requirements are easily traceable if

Continue reading→

Posted on

Requirements are the basis for design. Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as requirements levied on the project by the organization.

In CMMI Requirements Management (REQM) Process Area provides traceability of requirements from customer requirements to product requirements to product component requirements. Requirements Development (RD) Process Area describes Customer requirements, Product and Product component requirements.

This post is a consolidation of different types of requirements as described in CMMI, starting from Customer requirements to Derived requirements.

Requirements 1

Customer requirements

Customer needs and constraints are analyzed and elaborated to obtain prioritized customer requirements. In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated.

 Contractual requirements

Customer requirements are further refined and made suitable to be included in the contractual documents or supplier agreements. Contractual requirements include both technical and nontechnical requirements necessary for the acquisition of a product or service.

 Product and product component requirements

The customer functional and quality attribute requirements are usually expressed in the customer’s terms and can be nontechnical descriptions. A translation of requirements from customer’s language to developer’s language gives rise to product requirements. Or rather the product requirements are the expression of the customer requirements in technical terms that can be used for design decisions. An example of this translation is found in the first House of Quality Function Deployment, which maps customer desires into technical parameters. For instance, “solid sounding door” may be mapped to size, weight, fit, dampening, and resonant frequencies.

The product architecture provides the basis for allocating product requirements to product components. The developer uses product requirements to guide the design and building of the product or service. Product component requirements are a complete specification of a product or service component, including fit, form, function, performance, and any other requirement.

In short, product and product component requirements are the refined Customer requirements. This refinement of customer requirements converts implicit requirements into explicit derived requirements such as interface requirements.

Derived Requirements

Derived Requirements are those requirements which are not explicitly stated in customer requirements but are inferred from contextual requirements (e.g., applicable standards, laws, policies, common practices, management decisions) or from requirements needed to specify a product or service component. Derived requirements can also arise during analysis and design of components of the product or service. Derived requirements also address the needs of other lifecycle phases (e.g., production, operations, and disposal) to the extent compatible with business objectives.

Interface requirements

As internal components are developed, additional interfaces are defined and interface requirements are established. Interfaces between functions (or between objects or other logical entities) are identified. Interface requirements between products or product components identified in the product architecture are defined. They are controlled as part of product and product component integration and are an integral part of the architecture definition. Before integration, each product component should be confirmed to be compliant with its interface requirements. Interfaces can drive the development of alternative solutions described in the Technical Solution process area.

The blog won’t be complete if the below kinds of requirements are not touched

  • Allocated requirement

Requirements are said to be allocated when the higher level requirements are levied on a lower level architectural element or design components.

More generally, requirements can be allocated to other logical or physical components including people, consumables, delivery increments, or the architecture as a whole, depending on what best enables the product or service to achieve the requirements.

  • Service requirements

Service requirements are the complete set of requirements that affect service delivery and service system development. Service requirements include both technical and nontechnical requirements.

  • Technical requirements

Technical requirements are the properties (i.e., attributes) of products or services to be acquired or developed

  • Nontechnical requirements

Nontechnical requirements are the requirements affecting product and service acquisition or development that are not properties of the product or service.

Examples include numbers of products or services to be delivered, data rights for delivered COTS and non- developmental items, delivery dates, and milestones with exit criteria. Other nontechnical requirements may include additional conditions and commitments identified by agreements, needed capabilities, conditions derived from business objectives and work constraints associated with training, site provisions, and deployment schedules etc.

Posted on
Organizations and companies often go for certifications/assessment like ISO 9001 or ISO 27001 or CMMI. A company may decide to seek certification for many reasons, as certification can:

  • Meet Customer Requirements
  • Result in more revenue and business from new customers
  • Improve Company and Product Quality

Assessment process is a continuous cycle. There are some stages/steps in this continuous cycle leading to certification and sustenance.  For organizations that are new to the implementation process, attaining certification can be a little bit troublesome activity. This article helps to make the implementation stress-free through the ten points explained below. Assessment

1. Determine scope of registration

Determine whether the entire organization or a part of the organization is going for certification. Sometimes only a particular product in the organization is seeking for certification.

2. Get quotes from accredited third-party certifying bodies

The certifying bodies must be accredited to conduct audits. After evaluating several certification bodies (Transition partners in case of CMMI) based on their quotes and many other factors, the best suited certification body is selected by the organization. Once the quote is accepted by both parties – client and certification body, an auditor contacts the client to schedule the assessment audits. It’s vital to clarify and check for other hidden costs such as ‘registration’ and travel fees when obtaining quotes from the certification bodies.

3. Study of standard/model requirements

The first step in any certification/assessment process is ‘to have a clear understanding of the standard/model’. If people are not comfortable with the new standard, perhaps the first step in any implementation could be training on the new standard/model from experts in the industry. If required, organization can opt external consultancy to get help in implementation strategy. A good consultant can increase the value of the process.

4. Gap Analysis

It has to be evaluated how far away is the present management system or the product compliance from the new standard. Gap analysis, Pre-assessment, Internal audits etc. can be used for this evaluation. For more details on gap analysis, please refer Performing gap analysis. The Gap analysis documentation provides the input to the sub sequent phases.

5. Establish an implementation plan

An implementation team, work division, milestones of activities etc. need to be set up. Training has to be to be provided to the implementation team. Implementing the new management system needs to be an organization-wide target developed by senior management. (‘organization’ refers to the entire organization, a part of the organization or a project team as per the scope defined)

6. Ensure the implementation as per plan

The steps include preparation and review of procedures, manuals, other supporting documents, training to the affected parties on the new/changed system and deploying new/changed system.

7. Practice and live with the new system

During this period, observe and evaluate the new/changed system for its effectiveness. Audits need to be conducted to evaluate the changed system. Auditors must be trained to conduct the audits. Existing loop holes, inefficiencies, etc. are corrected and corrective actions are deployed. This leads to continuous improvement of the system. After a few months, the new system and the organization should be ready for the registration audit.

8. Third party Assessment/ certification

The number of auditors needed, and the time involved to conduct a registration audit may vary according to the size and complexity of the organization. Pre-assessments/Stage1 audits are conducted before the final assessment. During the pre-assessments, auditor reviews the existing systems and provides a report identifying further actions required to meet the standard requirements. Once the organization is ready and has fixed the gaps reported in the pre-assessment, the auditor performs the registration/final audit. The final audit is held in accordance with the audit plan. Upon completion of the audit, the auditor generates an audit report identifying non-conformances, if any are there. The client resolves these non-conformances. Once the auditor approves the closure of non-conformances, organization (or client) is recommended for certification. The auditor’s report is then verified via an approval process and if no anomalies are identified, certification is officially granted. Then the auditor works with the client to set up subsequent surveillance audits/health checks to ensure continuous adherence to the standard.

9. Sustaining the standard/model

Attaining a certification is not a one time job. The sustenance of the same is also equally important. So proper attention must be paid to ensure that level of certification is not degraded. To achieve the benefits of improvement from the new/changed system, an organization has to be committed in maintaining and amending the system over time to best suit its requirements. The tough work really starts with the maintenance of the new/changed system. And hence continued buy-in from everyone is important for the implementation to succeed, and for the organization to obtain the true advantages of becoming certified. So proper training needs to be carried out regularly to ensure on-going awareness. In addition, internal audits must be conducted to ensure the compliance to the requirements of the standard/model.

10. Get Buy-In

Getting full support from management and employees is crucial for the success of any certification/assessment program. The company executives need to be well clear on the advantages, requirements and costs etc. It’s also important that the employees are confident on the new system.

Posted on

Baselines are created for the core “value-generating” processes of the business in the organizations. From the observed measurement data, an organization comes up with various process performance baselines (PPB) periodically. In a software industry, there can be PPBs for coding speed, defect density, productivity, testing speed, review effectiveness etc. Then measurable improvement targets (process performance objectives) are set for the selected processes. Say for example an objective could be to increase the coding speed by 10 % (Definitely some improvement initiatives need to be there to achieve the targets which are above to the current performance). Even, there can be an objective to maintain the performance at current level itself instead of improving upon the same. The process performance objectives are based on

    • the organization’s business objectives
    • the past performance of projects
    • customer requirements

In all these cases organization needs to have a reference value as baseline to know where it is right now. (Otherwise goals will be subjective) Baselines show the current performance measures of an organization. Now assume a case where an organization has just started to collect measurement data. Definitely there won’t be a baseline initially. In this scenario, how the organization will be setting objectives, without a reference baselines

They can have different options as below.

  1. Industry bench marks
  2. The organization can look in to the industry benchmarks. If the organization is performing a similar nature of work as per the contextual information of the industry benchmarks, they can use those values as references for setting targets.
  3. Expert discussions and brainstorming
  4. There might be employees in the organization who are much skilled to come up with some reference values on the critical processes for setting the targets.
  5. Collecting information from similar organization.
  6. The organization can refer baselines of other similar organization via employee contacts and use it as reference values.
  7. Process Performance Models (PPMs)
  8. If there are some prediction models defined, suitable to the requirements of the organization, dependent parameters (y values) can be predicted, assuming organization have some knowledge on the values of the independent parameters(x values)

When a reference value is obtained, organization can build targets upon the same. Once the organization has collected enough data over a period of time, PPBs can be built. Then those PPBs can be used to set targets for coming year. In this way process is continued and baselines are revised on a periodical manner, say on a yearly basis or so.

Add your points if you have got some other methods ‘to set objectives when there is no baseline’

Posted on

Quality Management resulted mainly from the work of the quality gurus and their theories. There have been three groups of gurus since the 1940’s:

1. Early 1950’s Americans who took the messages of quality to Japan: Joseph Juran, W Edwards Deming, and Armand Feigenbum

2. Late 1950’s Japanese who developed new concepts in response to the Americans: Kaoru Ishikawa, Genichi Taguchi, and Shigeo Shingo

3. 1970’s-1980’s Western gurus who further extended the Quality Management concepts after the Japanese successes: Philip Crosby and Tom PetersThere are many other management “gurus” whose philosophies and ideas fill whole books on their own, and several of these are important to quality management. The ones included in this section are those whose reputation is primarily for their work in quality and excellence.

  • Taylor: An industrial (efficiency) engineer, manager, and consultant, Frederick Taylor is known as the Father of Scientific Management. In 1911, he published “The Principles of Scientific Management”

  • Walter Andrew Shewhart: sometimes known as the father of statistical quality control. A statistician who worked at Western Electric, Bell Laboratories, Dr. Walter A. Shewhart used statistics to explain process variability. It was Dr. W. Edward Deming who publicized the usefulness of control charts, as well as the Shewhart Cycle. However, Deming rightfully credited Shewhart with the development of theories of process control as well as the Shewhart transformation process on which the Deming PDCA (Plan-Do-Check or Study-Act) Cycle is based.

  • Deming : A prominent consultant, teacher, and author on the subject of quality. After sharing his expertise in statistical quality control to help the U.S. war effort during World War II, the War Department sent Deming to Japan in 1946 to help that nation recover from its Wartime losses. Deming published more than 200 works, including the well-known books Quality, Productivity, and Competitive Position and Out of the Crisis. His fourteen point plan is a complete philosophy of management that can be applied to small or large organisations in the public, private or service sectors: Deming also encouraged a systematic approach to problem solving and promoted the widely known Plan, Do, Check, Act (PDCA) cycle. The PDCA cycle is also known as the Deming cycle, although it was developed by a colleague of Deming, Dr Shewhart.

  • Juran: Seen by many as the “father” of quality, and the man who “taught quality to the Japanese.” The former chairman emeritus of the Juran Institute And an ASQ Honorary member. Since 1924, Juran has pursued a varied career in management as an engineer, executive, government administrator, University professor, labor arbitrator, corporate director, and consultant. Specializing in managing for quality, he has authored hundreds of papers and 12 books, including Juran’s Quality Control Handbook, Quality Planning and Analysis (with F. M. Gryna), and Juran on Leadership for Quality. Juran developed the quality trilogy – quality planning, quality control and quality He has defined Pareto principle.

  • Armand V Feigenbaum is an American quality control expert and businessman. He devised the concept of Total Quality Control, later known as Total Quality Management (TQM).

  • Ishikawa : Most noteworthy contribution is his total quality viewpoint, companywide quality control, his emphasis on the human side of quality, the Ishikawa diagram and the assembly and use of the “seven basic tools of quality”:

  • Taguchi, Genichi : The executive director of the American Supplier Institute, the director of the Japan Industrial Technology Institute, and an honorary professor at Nanjing Institute of Technology in China. Taguchi is well-known for developing a methodology to improve quality and reduce costs, which is referred to as the Taguchi Methods. He also developed the quality loss function.

  • Yoji Akao : is a Japanese planning specialist recognized as the developer of Hoshin Kanri (a strategic planning methodology). With the late Shigeru Mizuno, he developed Quality Function Deployment (a group decision making technique).

  • Shigeo Shingo is strongly associated with Just-in-Time manufacturing, and was the inventor of the single minute exchange of die (SMED) system, in which set up times are reduced from hours to minutes, and the Poka-Yoke (mistake proofing) system.

  • Crosby, Philip: The founder and chairman of the board of Career IV, an executive management consulting firm. Crosby also founded Philip Crosby Associates, Inc. and the Quality College. He has written many books, including Quality Is Free, Quality Without Tears, Let’s Talk Quality, and Leading: The Art of Becoming an Executive. He is known for the concepts of

  • Tom Peters identified leadership as being central to the quality improvement process, discarding the word “Management” for “Leadership”. The new role is of a facilitator, and the basis is Managing by walking about” (MBWA), enabling the leader to keep in touch with customers, innovation and people. Fortune calls Tom Peters the Ur-guru (guru of gurus) of management. The Economist tags him the Uber-guru, and his unconventional views led Business Week to describe Tom as “business’ best friend and worst nightmare.”

Posted on

I am comfortable as long as you are not intruding into my private space

Well, then what about hackers..? They are supposed to intrude into your space.

After all, that’s what they are supposed to do. So how can you ensure that your environment is less vulnerable?

The answer lies in security testing. With this form of testing, we are checking the real functionalities only but with a deeper objective. And ensuring that your product can’t be easily attacked by hackers.

The alarm system in your car for unauthorised access is an example of security measures. So in a security testing, you will be ensuring whether the alarm system is working properly. You might be simulating unexpected scenarios for the same.

Now coming to software security testing, let us take an example of user login form. Suppose you entered some user information and password and tried to access the system. And you received a message as incorrect password. Ah, there is smile on the hacker’s face as 50 % of his problem is solved. Yes, he understood that user information is correct and only password is wrong. In this way security testing is continued.

In a security testing a tester is acting as a bad guy to find your weakness.

Ensure that security testing is done with permission only; or else you will fall under the category of hackers.

So in short, security testing is the process of identifying vulnerabilities or weakness in the system

Posted on

How will you answer to a common man’s question upon your profession?

Suppose, you are a Quality engineer. But if a person who is not at all related to IT world asks you about your job, how will you answer?

I thought about the same in many dimensions.

Hmm.. It is easy to have a complex definition.. but It is pretty difficult to make it a simpler one

So coming back to the Question, “Who is a Process Engineer/Process consultant/Quality Engineer”?

QA

We all are working based on certain discipline.

Companies are also not at all an exception. They are abiding to some standards. Sometimes they make their own standards and follow the policies inline to those standards.

Otherwise they seek compliance to industry wide accepted standards and models like ISO, CMMI, ASPICE, TL 9000, FDA, AS 9100 etc.

Sometimes they even go for certification or assessment against these standards, so that they can proudly claim that “we are compliant to ISO xxx etc” and definitely which will be an added value in front of the clients.

Now who will be monitoring the compliance on a long run? Disciplines are to be ensured life long, right?

Similarly companies need to ensure that the defined policies are implemented and updated on a regular basis. If the responsibility is shared among each and every employee, it will end nowhere and ultimately everything is diluted.

So companies keep a separate group known as process consultant or QA engineers.

  • They mainly help the organization to comply with these standards.

  • They train the employees on the implementation part.

  • They write policies and procedures and ensure that it is shared to relevant people.

  • They ensure that these policies are practiced inside the projects through proper audits.

  • They escalate the issues and update the status to senior management.

  • They initiate corrective actions and preventive actions whenever required.

  • The job does not end here. If the company had gone for certification/assessment this team plays a main role for an easy go.

So this is the bare minimum responsibility of a QA engineer. And depending upon the organization, tasks vary. There are consultants who do data analysis and come up with interesting facts about the organization.

So in short, QA team is the team who ensures process compliance within an organization.