Posts in Requirements Management

cGMP – Medical Equipment Calibration – How it affect our success – ISO 13485:2016

June 17th, 2019 Posted by e-GMP, Requirements Management, Validation and Verification 0 thoughts on “cGMP – Medical Equipment Calibration – How it affect our success – ISO 13485:2016”

Calibration is considered as an essential procedure for any equipment and device, in order to maintain and improve its accuracy and precision. Calibration is the process, in which equipment under test is compared with some other standard equipment, in order to understand the accuracy of the one being produced. The calibration of medical equipment is also based on the same principle.

Medical equipment calibration is essential to the success of the product, the demand for calibration planning system is increasing, owing to various factors, such as rising number of hospitals, increasing environmental regulations, and rising customer focus towards quality and precision. The purpose of this article is to help identify both the current and future of calibration in the medical device market.

Medical device calibration has two sections, the service types, and the equipment types. The equipment types have a market in the following segments;

 

  • Infusion pumps
  • Fetal monitors
  • Ventilators
  • Imaging equipment
  • Vital sign monitors
  • Cardiovascular monitors etc.

 

Meanwhile, the service types have three major markets namely;

  • In-house Calibration: The Professional personnel of the company will perform the calibration. The staffs are mainly from the production line.
  • Third Party Calibration Services: Other professionals outside the company will perform the calibration for a fee.
  • OEM Calibration Services: The owner of the service will need to set up plans and notification ahead of time.

 

Out of the all above devices, The medical device producers of imaging equipment requires calibration services are the largest demand. Although, there are expectations that cardiovascular monitors will keep growing at the highest growth rate to match demands.

Increasing focus of customers on the quality, rising growing need for more control on the calibration planning and documentation due to strict compliance environment which are key factors expected to drive the growth of this demand.

The critical factors in driving the demands for cardiovascular monitors include:

  1. Customers are focusing on quality.
  2. The need to control calibration planning.
  3. Strict compliance requires documentation.
  4. A rise in product recall.

 

Reports from the FDA in the US show that in the past decade, product recalls has grown from 763 to 3202 between 2009 and 2017.

These recalls were observed due to software design failure, component and material issues and packaging and labeling. Hence, such frequent product recall affects the company’s reputation and thus, the companies are offering a strong emphasis on the calibration of their products before and after commercialization.

This fact is considered as an important growth propeller of this demand by the medical device manufacturers market. In addition, rising demand for third party and in-house calibration services is another important driver for the need of calibration planning system such as Orcanos eQMS.

What could affect the implementation of Calibration system?

Some of the crucial factors include;

  • High Capital
  • The use of modular instrumentation
  • Regional and local companies dominating the market

 

Medical equipment calibration services are segmented in areas such as North America, Europe, Asia-Pacific and Rest of the World (RoW).

Presently, we see the European region is the largest market in the world, owing to extensive R&D practices by the industry, a large number of local and regional players and rapidly growing medical and healthcare infrastructure.

However, Asia-Pacific region is expected to be the fastest growing market during the forecast period 2019 – 2025. This growth is driven by rising demand for good quality services, steadily increasing medical infrastructure and rising government regulations.

The purpose of this article is to help identify both the current and future of calibration in the medical device market.

Orcanos provide for these players a greater potential by collaborating with the vendor directly over Orcanos eQMS cloud system to plan and execute the calibration program.

Some of the global service players include Fluke Biomedical, Tektronix, Inc., JPen Medical Ltd., NS Medical Systems and Biomed Technologies, Inc. amongst others. However, these companies have to face stiff competition from various players operating at the regional level and hence; collaboration or acquisition of cloud system is considered as an important strategy for the players to grow in this market.

cGMP – Design and Development Outputs (SwRS-MecRS-HwRS-FwRS) – ISO 13485:2016 (8) Clause 7

June 16th, 2019 Posted by e-GMP, Requirements Management, Validation and Verification 0 thoughts on “cGMP – Design and Development Outputs (SwRS-MecRS-HwRS-FwRS) – ISO 13485:2016 (8) Clause 7”

In the same manner that we have design and development input. We also have design and development output. The result of satisfying the criteria for design input is the design output.  The output will possess risk assessment for the following ;

  • Assembly drawings
  • The specification for raw materials and components
  • Design and process
  • Instruction for installation and service
  • Guideline for the assembly process
  • Specification for labeling and packaging
  • Source code and technical files
  • Biocompatibility studies
  • Results of verification activity
  • Validation activities such as sterility, reliability testing or shelf-life studies and shipping.

 

The design and development output is also known as the first realized product. Depending on the type of product. It could be the first of several lines of assemblies or the first batch of products manufactured. The initial set of the first realized product must undergo evaluation checks. The checks will ensure that the design output requirement is met. Likewise, there will be serial number checks to ensure there is consistency in the process.

Orcanos ALM provides all the tools you need for complete coverage of the design outputs both from the product definition but as well from the change control as risk management according to ISO 14971:2012 with full traceability and impacts analysis tools, all in the same tool.

 

 

Related Links

cGMP – Design Inputs (URS-FRS-MRS-ERS) – ISO 13485:2016 (7) Clause 7

May 30th, 2019 Posted by e-GMP, Requirements Management, Standards and Regulations 0 thoughts on “cGMP – Design Inputs (URS-FRS-MRS-ERS) – ISO 13485:2016 (7) Clause 7”

We expect that the Design & Development Plan be a written and reviewed document. Similarly, the Design Inputs also needs to be a controlled document. In practice, the design input document is created alongside the DDP simultaneously. However, before we start to analyze the design input, we should take a look at User Requirement Specifications (URS) or Customer Related Processes (see ISO 13485:2016 Chapter 7.2).

The focus of the URS should be on the customer experience. In other words, it should be a list of what the user desires rather than a list of requirements. Also, the list should not have solutions alongside it unless the solution satisfies the requirement of what the user wants to achieve using the product. Likewise, the URS should also include answers on what the customer experiences. In the medical device industry, the demands of the users should be considered from two perspectives namely;

  1.      As a patient.
  2.      As the device operator.

The moment the needs of the user is identified, the device designers have to translate those needs into the design input forms. Although the job is primarily that of the device engineer, inputs from crucial personnel in production, marketing, service, and others should be added as needed. Design engineers should strive to eliminate ambiguity in the design input process to reduce the level if inaccurate assumption. One of the effective ways to avoid false assumptions is to exclude design solutions from the design inputs unless the solution is part of the design. For example, let say a user requirement is; the device must have a foot switch to trigger operation. A suitable alternative would be not to specify a foot switch, rather have the requirement stipulate the need for a hand free operation for the device.

Design Input Categories

Using the User Requirement Specification, one can easily generate several input requirements documents. Input Requirements often fall into three categories namely;

  • The Functional Requirements (FRS): This requirement specifies the capabilities of the devices, its operations as well as its input and output characteristics.
  • Performance Requirement (PR): It covers the device behavior during use, and some of the behaviors can include; precision, ranges of quantitation accuracy, operational environmental ranges, and other performances.
  • Interface Requirement (IR): All interface requirements should be specified. Interface requirements can be either external or internal. However, all specifics relating to the interface should be listed.  External interfaces can be in the form of patient/product interface, external communication interface, and operation/product interface. Meanwhile, the internal interface can be software/hardware and communication interface. Each interface requires a review to ensure that the system works well together.

The documentation for each requirement often depends on the product and the organization. Although, almost all organization have functional requirement documentation or documentation that directly addresses design input requirements (DIR). Sometimes there are separate documents to capture specific requirements of the document such as a Mechanical Requirement Specification (MRS). Another example is the Electrical Requirement Specification (ERS) that are created within the sections or either the DIR or FRS documentation, Orcanos ALM system support over 58 different types of requirements and can be expended to more as needed.

Other requirements that deserve consideration are safety and regulatory requirement. We mustn’t forget the requirements for applicable risk management inputs.

Adequate Time

There should always be enough time to allow for the development of the Design Input Requirement (DIR). Each requirement should be ;

  •         Unambiguous
  •         Quantitative
  •         Contain expected tolerance.

The environmental conditions for optimal performance of the medical device and environmental specification for storage of the device should be stated. As much as is possible, organizations should try to capitalize on the standards set by the industry for each product. Nevertheless, the standards should be reviewed to ensure they cover and satisfy the design input requirements. A popular example is the referencing of ASTM D40169 for performance testing of shipping containers and systems as it relates to verifying the method of testing and packaging conditions. The standard sometimes might not cover the acceptance criteria like in this instance, and if such provision is left out of the DIR, the design input requirement will be incomplete.

It is expected that over the corse of product development, the design input requirement will change. For this reason, the change control will play a vital role in ensuring that the changes are reviewed based on their impact on other design input requirements, Orcanos traceability tools also includes integrated suspicious indication feature which proactively alerts on such possible impact. It is not unusual that a change in one requirement would affect another design input requirement. For more information see related links

Related Links

cGMP – Design & Development Plan (General ) – ISO 13485:2016 (5) Clause 7

May 23rd, 2019 Posted by e-GMP, Requirements Management, Standards and Regulations 0 thoughts on “cGMP – Design & Development Plan (General ) – ISO 13485:2016 (5) Clause 7”

Most device manufacturers find the concept of design control confusing. However, design control is better understood now as a result of better structure. The foundation for every product quality is the design process. Similar to a building, the better the foundation, the lesser the risk of collapse. In terms of design, the final product is dependent on the design process.

The design control process can be implemented for medical devices, manufacturing equipment, and operation, and software systems can make use of a similar process.

Below is a diagram of the waterfall system of design.

Waterfall Design System

 

The diagram depicts a simplistic version of an approved FDA control guidance. The design is typically more complicated due to several elements developing at the same rate. However, the waterfall diagram does serve the purpose of aiding understanding of the operations of the design process.

Common Mistakes in Design Development

One of the prominent mistakes to make is to assume that design control is the same thing as the development process. Although, the development process is a vital part of design control, a more accurate description for design control is to envision it as a lifecycle.

By picturing design control as a lifecycle doesn’t mean that design control will cover requirement for feasibility or marketing. While these processes are vital to the product development process, regulations are in place to monitor product design rather than concern itself with the success of the product in the market. Regulations are more about the safety of the design product instead of the general welfare of the business.

It is important to differentiate between the design input requirement and the marketing requirement and feasibility studies. The design input requirement is also known as the product concept document.

Document Approval

A common problem that most organization face is the approval of documents. There is always a reluctance to approve product design documents as they have to create a room for change and improvement on the document. However, by maintaining control over the document, the approval process tends to become tedious. The goal of control is not to restrict flexibility but to ensure that every phase of the design process is sync, especially when dealing with cross-functional teams.

Typically, approval can be given for revision 1 of a document with To-Be-Determined (TBD) values in certain sections. Meanwhile, teams can start preliminary drafts for the second revision of the document. Subsequent sections will address the core elements of the design control process. However, implementation of the process will depend on the following;

  • The maturity of the company.
  • Product complexity.

It is worth noting that most organizations prefer to breakdown these processes into individual (SOPs). But, it is possible to have a document that covers all the requirement of several elements of the design and development control process.

Related Links

המהפכה הדיגיטלית – רגולציה של תוכנה רפואית, סייבר סקיוריטי

March 18th, 2015 Posted by ALM 2.0, Requirements Management 0 thoughts on “המהפכה הדיגיטלית – רגולציה של תוכנה רפואית, סייבר סקיוריטי”

Seminar-agenda-2015(F)

Loss The Documents and Spreadsheets (White Paper)

November 8th, 2014 Posted by Distributed development, Requirements Management 0 thoughts on “Loss The Documents and Spreadsheets (White Paper)”

Manage all ALM requirements types efficiently and more accurately with Orcanos QPack Requirements Next Generation tools. By Rami Azulay VP Marketing and Sales at Orcanos.

 

Introduction

It is well known by now that poor requirements management is among the most affecting contributing factors in the failure of a project. Misleading requirements management can put your organizational compas on the wrong direction and lead to unfocused teams, rework time, regulation violations, out-of-control costs and unhappy customers. If you use documents, spreadsheets, emails, homegrown tools and other tools to keep track of your business, customer or product requirements, you could be starting on the wrong foot and put your project at risk. Have you ever forgotten to notify all the people that needed to know about an update? And if you did notify, how sure your are that it was well understood? Have you ever been seeking for the correct version of a document before going into Design Review (DR) meeting? How much time are you spending on getting everyone comments into single document or had to take time to listen to people who were giving the same feedback?

 

This is a fact, Managing requirements is difficult with conventional office and productivity tools because they lack some key capabilities. It is not enough that we have a way to describe the requirement over and text editor a successful requirements management should also includes the ability to capture relationships between requirements that are part of the traceability requirements by any quality standard such as ISO 9001 or IEC 62304 or ISO 13485 and manage dependencies. For example, based on the level of concern related to your product there are level of depth required by the traceability used in your documents, you should be able to show how features that are being built relate to capabilities that customers have requested.

When different time zones are involved in your project that may bring another level of complexity to the communication on requirements. Each change requires a full audit trace according to the CFR 21 Part 11 if you are under such regulation restriction so that by itself will force you to maintain an history audit change on every change made to the document, never ending work and in some cases the that part of the document could be as big as the spec itself, so handling versioning and change management is crucial. When you try to manage requirements without these capabilities, the results can be low productivity, latency at project timeline and increase in costs. Using typical productivity tools, to manage requirements is like using a hammer to open a bottle. It gets the job done, but at what cost?

 

On the other hand, Orcanos© QPack Requirements™ Next Generation offers effective requirements management capabilities.

 

After 10 years in the market we can tell that these capabilities have helped Orcanos clients:

  • Reduce development costs by 52 percent.

  • Accelerate the time to market by 25 percent.

  • Reduce cost of quality by 62 percent.

 

This paper identifies five key benefits of the requirements management capabilities provided by  QPack Requirements™ NG that address what cannot be done with documents, emails and spreadsheets. These capabilities include requirements capture, online chat discussions, sharing, elaboration and management. Another key capability is collaboration between teams, whether they are local or globally distributed.

 

The benefits are:

  • Clear Understanding of a change

  • Consistency in development

  • Full V&V Traceability

  • Online – Real Time collaboration

  • Pro Active Alerts making your data work for you

 

Orcanos Software

With QPack Requirements™ NG your teams can collaborate more easily. After a document is ready for interested parties to review, stakeholders can use QPack Requirements™ NG to discuss and collaborate by commenting directly in the preview mode document. Important decisions can be finalized using the work item workflow and discussions are being logged by the chat feature available to the team. Now you can stop chasing down emails or making, consolidating and responding to similar comments, saving all that common wasted time. With  QPack Requirements™ NG, chat comments can be directed to team members and classified as private or public to avoid unnecessary noise between stakeholders, so the important things can be handled directly by the right person. As people make comments, QPack Requirements™ NG can send SMART email notifications, including a recent history change log as well hyperlink that enables users access to just the information they need. Review cycles are shortened and collaboration is improved even when different time zones are involved. Keeping stakeholders informed and engaged is critical. With QPack Requirements™ NG, the flexible notification mechanism can identify the team automatically and keep them in the loop of changes. Along with email notifications, QPack Requirements™ NG has improved dashboards so users exposed to  the most important information as soon as they log in to this pure HTML5 web-based application. Dashboards can have presentation of endless data dimensions, project timelines, changes that have been made in the scope of the change itself of the document that the change was discovered in along with any ongoing reviews and comments.  QPack Requirements™ NG acts as an “Absolute source of facts” and enables interested parties to access the latest information automatically. Customers don’t lie Orcanos clients have used  QPack Requirements™ NG software to reduce development costs by 52 percent and costs of quality by 62 percent, while accelerating the time to market by 25 percent.

 

Benefit 1: Live collaboration over documents, spreadsheets or email can cause never ending  headaches when you work with others, distance can be as short as working on the same building, and especially if you are part of a globally distributed team. Most vendors of requirement management tools will create what we call “information islands” that make it difficult to find, relate and use this information. Colleges spend too much time searching for the latest information, reviewing documents and consolidating changes. In many cases you might think you have the most up-to-date information data, unmeasured lost of time gathering everyone inputs, reviewing and combining it. As a result, requirements might be weeks out of date from the point where it started as business idea to the finish line when it is delivered. With productivity tools such as office and excel, multi-user editing is difficult and almost impossible to manage. Consequently, several versions of the document might circulate throughout the team. For that Orcanos not just giving you Next Generation tools but also accommodate them with complementary tools that will allow you to make the working habits much easier, that comes with QPack DMS™. The owners of these documents must consolidate changes, maintain an updated copy and inform teams about the changes using QPack DMS as centralized tool that both meet the regulation standard ISO 13485 sec. 4.2 as well give simple easy to adopt tool, can do all that work for you.  QPack Requirements™ NG, by contrast, offers automated requirements freezing mechanism. By that more than one person can work at the same time on the same information and collaborate wherever they are located. The latest information is available for the team to access via the web or mobile application coming all from the same house of vendor Orcanos.

 

Since you never rest assure that you are all in sync, team members undertake heroic measures to consolidate, understand and monitor status of their requirement. Then, decision is taken based on this information. Unfortunately, if the data is error prone, it cannot be trusted and the project is put at risk. With QPack Requirements™ NG, each member of the team can access the latest information when he needs it. The template format of the original document is preserved. If required, for each traceable requirement working item annotations, such as priority, risk, status and category, can be displayed in grid report. The contents and chant annotations can be searched, sorted and filtered. You can also save views, which enables you to do MASS change on the perspective of your data quickly and display just the  information you need. Drill down analysis is quicker and the presented data used by you is more consistent and accurate.

 

Benefit 2: Getting Project data in consistency can be very complex. Teams members have a need for filtering relevant information and to organize it in logical manner. With  QPack Requirements™ NG, a project admin can set up different templates for each unique type of document such as MRD, PRD, SysRS, SRS, SDD, STP, STD, STR, Risk etc. That outline templated can be the basic structure of the information to be placed into the documents using traceable items. For example, a system requirements template can include boilerplate text for the introduction and areas for functional and nonfunctional requirements. In addition, each

work item type of can be “templated” with the appropriate annotations that must be collected by the author of that particular work item. For example, system requirements are kept in a product requirements specification that includes all related product components annotations, such as cost, risk or priority, along with any additional information they might need. On the other hand looking back on traditional document tools, it is not possible annotate requirements specifications without adversely affecting the original structure and context. In addition sorting or filtering documents based on any type of information and determining which requirements are missing is not possible. At the end of the day, someone must clean up the documents and remove the annotations in a very precautions way. Then once you got the document finalize the common practice of word processing users is often to copy the requirements from their documents into spreadsheets (keeping some level of traceability) and then adding separate columns to filter by them. When the documents are updated, the users must manually synchronize the changes for all documents and spreadsheets. These manual processes are often time consuming, they don’t scale and they can introduce errors into the process.

 

Relationships between artifacts can be displayed in columns, along with the requirements and annotations, which increases the visibility on the project status. As an outcome you improved quality and better project management. Filters can be saved and broadcast via proactive alerts, which enables the team or single member which is assigned to a task to once again quickly change the perspective of the data to fit the needs of the stakeholder.

 

The real value of traceability provided by QPack Requirements™ NG is evident when a project team must respond to an audit request by any notify body or must understand the impact of a change on existing features. If you use spreadsheet you may struggle to maintain the traceability and later interpret the connections between different levels of requirements that are found in multiple documents and are related by yet another document in the form of a spreadsheet, and that can go on and on. The guidance regarding the compliance of the project activities to user requirements or assessing the impact of change becomes challenging and uncomfort. With QPack Requirements™ NG, these challenges are avoided and almost does not exist. You can record multiple relationships with many to many ratio as you see them and use rich analysis tool to view details about the related work item from your actual current preview document without having the need to navigate away. When necessary, the relationships are traversable, which enables teams to quickly navigate from one document tree to the other. You can split your screen to create the traceability between 2 documents and use the multi selection tree view mode to perform faster. The way QPack Requirements™ NG display related information in columns can highlight the gaps and find inconsistency in the document whereby user requirements were left orphaned or are missing downstream interpretation to lower level requirements or upstream to final product. Such Pre-Audit alerts which can be built into your organization process, does not leave the worst for last and just let you handle it when something needs your attention. They can help identify scope creep, whereby functionality missing project goals or business needs as described by the marketing people, which uses up valuable time. Because you can see the requirements and multiple levels of relationships graphically, you can more easily and quickly assess the impact of change. And, during design reviews (DR) when required, you can demonstrate what is needed also during an audit without having to search for multiple documents and team members. Knowledge is being preserved throughout the years and not dependency exist over people who left you company. Traceability in QPack Requirements™ NG is dynamic. As soon as someone else makes changes in the tool, an update is immediately created. If a downstream requirement changes, it automatically shows up in traceability columns for the upstream requirements. Users have access to an up-to-date traceability matrix whenever it is needed and can also see what impact the change has.

 

Benefit 3: The use of spreadsheets for traceability are often used to add an additional dimension to requirements documents by storing needed annotations. Additional spreadsheets are used to capture relationships for the V&V, between requirements and tests. Verification matrixes,

compliance matrixes and traceability matrixes then must be maintained separately. These manual processes do not scale and are prone to user errors. In  QPack Requirements™ NG, users can “trace as they think.” Even they can start the relations from the QPack Service Center™ They can create relationships between new Service Call to the asset RISK which is required by the IEC 60601 requirements and respond to that RISK by mitigation proofed with traceability to the mitigation method.

 

QPack Requirements™ NG supports automation of the creation and maintenance of the relationships throughout the application lifecycle development. This includes relationships between requirements, work items, architecture, design and test plans. It removes the “air gaps” between “information islands” that are the result of using different tools. Removing these possible gaps reduces user errors.

 

Benefit 4: One of the unavoidable events in a normal project lifecycle will be the introduction of a change after project kick started, the effort understanding A change create turbulent period in a project once it comes after the initial requirements have been written and agreed on. At the PDR and CDR (Critical Design Review) All parties are happy and go on their merry way to work on the initial set of requirements. Than changes occur. Customers change needs to change their business strategy or replace low priority requirement with high priority requirement. A supplier is unable to meet an original target for cost or performance. An engineer or test reveals that what was planned is not possible. Or, more simply, a requirement already acted on developed and even test, is corrected. Managing changes as effectively as possible is imperative.

 

Before making a change it is recommended to follow those two main steps:

  • One, analyze the impact of the change before it is made

  • Second ensuring that all impacted areas have been revised as necessary

 

If you are using documents and spreadsheets above guidance can not easily achieved when spread over pieces of information. It become even worse If that information had to come from a failed test or reported a defect that was raised or if a client issues an updated specification, a document or spreadsheet cannot analyze the impact. That leaves the individual responsible personnel usually to spend weeks trying to understand the impact of change. With QPack Requirements™ NG, a user can create a perspective or view of their data. That view shows allows them to do drill down quickly to any direction they wish to follow. The user of V-Module when implemented makes that work even easier. In accordance to the V&V module each requirement should be trace down to the lowest implementation details design and even to the code if software was involved or engineering drawings and then from there to other steps of the development process, such as test. Users can also explore graphically the complex map of information that can be used to understand the impact of change that spans multiple levels and even components. This information is not static, using QPack Requirements™ NG you build your solution in a way that you can share features between several products so one change can affect more than one product. It can be updated as soon as someone else makes changes in the tool. If a downstream requirement changes, it automatically shows up so users can see what impact the change might have. Doing that with traditional tools huge effort will be placed to communicate these changes among everyone that is concerned and ensuring that all

impacted areas are addressed. From upper management to production floor all stakeholders and others want and can know what changed, how it changed and if they must act on the change. With QPack Requirements™ NG, a full history is maintained every time a requirement changes and that is also according to the CFR 21 Part 11 requirement for electronic records management. The team member can refer to the history and determine what changed, who changed it and when it changed and most important on what release it was changed. Change that was introduced into older release now needs to be observed twice: once into the older release and second to the new one. QPack Requirements™ NG also takes advantage of the relationships between information. Suspicion profiles alert users of a change with additional information regarding the actual document affected by the change. Users can review and act accordingly. This event will occur on every other change, a new suspicion is raised. With a minimum of effort, changes propagate down the levels of linked information in the project.

QPack Requirements™ NG helps your whole team assess the impact of change before it happen, using existing relationships and other meta data.

 

Benefit 5: In order to improve the ways your can look at your data you can limited doing that if you are using documents and spreadsheet. For example, you will need to present the data in different structure based on the audience intending to review it. Your customer might want their requirements structured as a document to simplify the review process. On the other hand, the looking at the same requirements from a finance perspective may required a table layout so they can estimate how much each requirement might cost. Using spreadsheets, these alternative perspectives on the same data require creating separate versions of documents. You must then maintain them or extract and consolidate them from a variety of sources every time reports are needed. QPack Requirements™ NG stores information in a central location and presents it in the format of a document. Users can add attributes to individual statements without changing the original structure, and they can filter and sort information based on the supporting characteristics. QPack Requirements™ NG automatically maintains cross references and relationships between information so you don’t have to. It also tracks change and alerts people of change that they might need to act on.

 

Best practices for writing clear, unambiguous requirements that can be tested can help reduce project complexity. To align all participants on the same terms used it is recommended  to include glossaries. With QPack Requirements™ NG, the glossary is accessed from a document. You can search or update terms and even update the glossary from the

document when they are introduced.

 

Conclusion

One of the most difficult decision about tool selection is to select the right tool for the job. It is organizational decision and not individual so you need the maturity to start going in that path. With QPack Requirements™ NG you can work smarter rather than harder. Putting the right people to view the right perspectives of the data for their roles at the right time. Avoid spending weeks to manipulate many documents and spreadsheets to see clear things in a way you want can be a practice of the past. Now you can spend time working on the more important details of your project, and let the tool relief from you time-consuming and repetitive tasks. QPack Requirements™ NG enables you to control your project. You can focus on important tasks, such as building and testing, without having to manually recording every change in multiple documents and spreadsheets. You can respond quickly and work faster with while increasing  traceability for better impact analysis. Notifications are automatic and immediate so your can respond with near real time to the point of the event. Now collaboration across locations can be assess before the change happens, to create a strategy for change and to act on a required change. Open the door to success. Orcanos QPack Requirements™ NG is your solution to a smarter project. Orcanos clients have used  QPack Requirements™ NG to enable effective requirements management that helped them reduce development costs and cost of quality, while accelerating the time to market. You could be next.

 

For more information

To learn more about Orcanos  QPack Requirements™ NG , contact your Orcanos representative or Orcanos Business Partner, or visit the following website: www.orcanos.com

 

© Copyright Orcanos Corporation 2014

Orcanos LTD

QPack Web – making it work with distributed teams

October 9th, 2014 Posted by ALM 2.0, Collaboration, Distributed development, IEC 62304, Requirements Management, Test Management 0 thoughts on “QPack Web – making it work with distributed teams”

Recently, I get lots of queries regarding “How QPack can help us managing distributed teams?”

Well, QPack has all it takes for managing and control a distributed development project.

In this post I will describe in short what are the main QPack tools that are used for distributed development.

Later on, I will give you our best practice and some tips of how to start and how to make it work.

So,

whether you are a Project manager, product owner, project manager, software manager, tester or developer – you can use QPack collaborative tools and methodology for creating productive, distributed development teams using .

qpack_dashbaord

Web based system

For first, in order to implement a good collaborative environment, QPack web interface should be used, at least for the end users.

QPack Web is HTML5 based, and accessible using any browser and any operating system, thus making it accessible anywhere anytime.

Integrated ALM system with one repository

QPack in it’s nature is an integrated ALM system. QPack suite offers all modules required to manage a project, from market requirements definitions, to system and software requirements, detail design, test plan, test cases and test execution with defect tracking and task management, so every participant in the process has his own interface and everyone shares one central repository.

Full permissions and personalization

In QPack Web admin interface it is very easy to setup user profiles, and admin can decide with just few clicks who will see what and who can do what.

Instant messaging

A unique and integrated instant messaging allows every participant in the process to share his ideas, ask questions and provide information.

the uniqueness of QPack instant messaging is in that every discussion is saved as audit log of the specific work items history (such as customer requirements or a defect). Users can later on go back and track decisions taken. It actually replaces conversations, emails, and uncontrolled documents

Queries, Alerts and notifications

by defining queries and alerts its very easy to track information and get notifications in “Push” mode, where QPack sends alerts containing activities to perform based on predefined rules.

Dashboards

Whether you are a developer, tester, or manager, you can personalize your dashboard accordingly.

You can setup any type of report

 

QPack Medical Webinar, October 2012

November 11th, 2012 Posted by IEC 62304, ISO 13485, ISO 14971, Requirements Management, Risk Management, Software Lifecycle Management, Test Management, Validation and Verification 0 thoughts on “QPack Medical Webinar, October 2012”

Requirements management in medical device

May 10th, 2012 Posted by Requirements Management 0 thoughts on “Requirements management in medical device”

Medical device industry

The medical device industry is a rapid-growing industry, and so is the complexity of device technology. Medical device corporate chemical and biological ingredients and can also combine a complex mechanisms and electronic systems. Operating such systems requires complex software.

The challenge in developing medical device

Many questions are raised planning and developing such software: What should it do? How can we validate its operation? How can we predict the required effort estimation and how can we track its progress as time pass? The medical device must operate in high-level accuracy of thousandths of an inch, and measured in nanoseconds.

Market requirements

The goal of this module is to gather all the requirements of the device. The process of gathering requirements for a new device, or application is one of the most important phases in the development process. In order to meet company goals, these requirements must reflect customers and end users needs as well as company requirements. Market requirements come from multiple sources, such as company documentations, competitors, domain experts, marketing department and prospective users.

Gathering data from multiple resources demands a systematic process. QPack Medical MRD provides a structured system for collecting data from them, synthesizing, and then rationalizing and reducing the data. This last step is needed to remove conflicting or redundant requirements, and eliminate or annotate those requirements that are impractical based on current technology, cost constraints, or market factors.

Last stage in this process is to trace these requirements and verify they are delivered.

QPack requirements management

QPack requirements management creates a central information repository, which includes all requirements data, such as description, attributes, status information, and other information. Requirements and their associated attributes can evolve, be adapted, and be reused for subsequent development projects, lowering the overall development cost. This repository not only defines the specifics of what the system should do, it assists managers in set priorities and effort estimation, and provides up-to-date information of project progress.

QPack systematic approach allows organizing, documenting, and managing both the initial and the changing requirements of a system. A primary result of this effort is the development of one or more requirements specifications that define and document the complete behavior of the system. It allows better definition and management of the labeling claims, allows better control of the project, improve quality by combining the validation phase into the process and allows each participant in the process to understand what he should deliver. By improving team communication, and provide professional tools, Project cost is reduce significantly.

Orcanos

Contact

8Beit Oved Street
Tel Aviv, Israel
+972-3-5372561
info@orcanos.com

Copyright © Orcanos, All rights reserved. | Privacy policy | Terms of use