Requirements change management - your approach/software

Requirements Management = DOORS.

I believe that it has change management built in (at least to some extent).

Good? Hmmm... Not bad I suppose. Sometimes the fields (huge tables) are exported to MS Excel to process and then imported back into DOORS. Which is easy.

TB... just to fully understand ...

CHANGE MANAGEMENT, such as described in... ???

NASA-LLIS-4580 Lessons Learned - Early Implementation of a Change Management Process [ ]???
Abstract
A change management process should be developed at program/project inception and implemented with rigor. An automated system for change management would be best.
Driving Event
In the Constellation Program (CxP), an unstructured change management process drove increased costs and impacted schedules. Because of the change management process immaturity in CxP, unfunded requirements were levied on the Ground Operations Project, and costs were not adequately quantified. Early efforts at Change Management were accomplished by a manual process and not an automated tool, which adds the risks introducing errors.

SAE ARP6109 Electronic Engine Control Hardware Change Management ???
RATIONALE
The reason for this guidance report on change management is to recommend procedures and practices that clarify the
level of risk associated with changes to an engine control system. There are recommendations regarding the engineering
processes that should accompany the various levels of change in order to keep the risk of unforeseen effects as low as is
reasonably possible. Guidance is also provided on the communication amongst relevant parties.
FOREWORD
Changes to engine control systems have traditionally been classified as either minor or major, with the former being
defined as having no change to the form, fit or function of the item to be changed. This method of classification has
proved somewhat awkward with changes to electronic control or protection functions that address obsolescence.
The change might be to a component or function which is complex or which is obviously safety-related (such as the over
speed protection function) while causing no change to form, fit or function. A level of risk may exist with this change which
could warrant the use of a modification process, which may involve all parties to determine if an aircraft modification is
required. This is often referred to as a ‘Full Modification Process.’
...

NOTE. IF I substitute the term TECHNICAL RISK MANAGEMENT for TECHNICAL CHANGE MANAGEMENT is there a similarity or parallelism there?

Regards, Wil Taylor

o Trust - But Verify!
o We believe to be true what we prefer to be true. [Unknown]
o For those who believe, no proof is required; for those who cannot believe, no proof is possible. [variation,Stuart Chase]
o Unfortunately, in science what You 'believe' is irrelevant. ["Orion", Homebuiltairplanes.com forum]

I'm not entirely clear about what you are asking. You stated in the OP that your situation involves test failures and implementing changes to the design and/or requirements documents. The answer to your question depends on many factors. What type of testing is involved (acceptance, qualification, etc)? Who controls the requirement spec that you want to revise (a customer, your company, a vendor, a customer subcontractor, etc)? What type of product and application is involved? As WKTaylor points out, the aerospace industry takes this sort of thing very seriously. Typically, if your test article failed to meet qualification/acceptance requirements imposed by a customer contract, then you would notify the customer of the non-conformance, request how to disposition the non-conforming product, and instructions on what corrective action to take.

There are established and extensively documented procedures for Configuration Management in documents like MIL-HDBK-61. You will likely find answers to many of questions there (including many flow charts), provided you can endure slogging thru all 200 pages.

Good luck to you.

Hi TB2944,
Can I ask you to clarify something?

...I'd be interested in how your companies approach requirements change management. That is, proper control of iterative changes during development, eg, in response to test failures...

Click to expand...

In most cases I am familiar with, failing the test does not change the requirement. It just means you did not meet it. Fix your product and test it again.

Whether you change the product to pass the test, or the goal of the test changes, then I do see how keeping track of the configuration as it evolves is important.
In my organization, we maintain careful control over previous revisions of our products so that we "can turn the clock back" at any time that a comparison is needed between the current design and a previous one.
Control over revisions extends to both the drawings and test procedures that validate the design, because even the test procedure may change, even if the ultimate goal remains the same.
A database to maintain control over the revision status and approval status of all of these documents is all we currently use.

When it comes to keeping track of requirements that change mid-project, this is much more complex. Often there is a chance that some people on the team don't "get the memo" and keep working in the wrong direction.
Usually, though, what hampers most projects that I have done (and there have been many) is that the requirements are not clear from the beginning, and what is designed/built does not completely match the specification or scope of work that was intended. So it is less of a matter of dealing with any requirements that change, but simply managing the process of building what the customer wants.

I have found that groups that share information openly among the members are the best at meeting the requirements with less formal management of the design process. This relies upon all members being generalists, who are invested in the design and having the background to understand how to fulfill these requirements. In that scenario it is more difficult to mix in trainees, specialists, or people hired mid-project. A more typical organization has members with specialties who all contribute to the project as a whole, especially as the project become more complex, and in this case a formal means of planning the project to meet all of the requirements is necessary. This includes developing a matrix or table of these requirements, how to meet them, what documents will be produced to show that they are met, who approves them, and so on. Each requirement should be broken down into small steps and then built back up into the resources needed to get to the end (materials, labour, risks, milestones, etc.). The informal method, on the other hand, does not scale up and is only appropriate for small projects.

I work in the aircraft modification world, so most frequently, requirements I have to meet are specified in the FAR's and the accompanying AC's that we use for guidance. There is no legal way for us to avoid building a "certification program" document that will be examined by Transport Canada (or the FAA/EASA or whoever is your governing regulator). If the customer has other specifications (they always do!) then we get it in writing on a scope of work and sometimes even that evolves into more formal and detailed documents so that we know what performance, capacity, dimensions, limitations are expected. All of these documents will evolve over the life of the project (especially the complex ones). I also expect these documents to have some "cross-talk" where the customer requirements explicitly acknowledge the limitations of airworthiness requirements, for safety, and the certification plan will describe the customer requirements to the regulatory engineers (they are people too!) what the project's goals are.

IMHO, this document should be given to all members of the team that work on the project, however, competition between companies, and outright secrecy, don't always allow that. I frequently discover that the man in the shop building intricate components that I have designed has no idea what they are for, and his superiors won't tell him.


STF

tbuelna ... MIL-HDBK-61... Good call!



Regards, Wil Taylor

o Trust - But Verify!
o We believe to be true what we prefer to be true. [Unknown]
o For those who believe, no proof is required; for those who cannot believe, no proof is possible. [variation,Stuart Chase]
o Unfortunately, in science what You 'believe' is irrelevant. ["Orion", Homebuiltairplanes.com forum]

I recall a few years back working on a high-priority NASA project at Rockwell. The design requirements document (DRD) provided by NASA that we worked to was revised once or twice each week. It was an electronic document file they posted on their website every time a new revision was released. The document included a list of the sections that contained revisions, but no other details were provided. It was up to each engineering group to read the DRD and determine exactly what changes were made. We could request changes to the DRD, which our group did on a few occasions, but I don't recall NASA program management agreeing to any of them. After a while, the number/extent of revisions to the DRD issued by NASA became impossible to keep pace with. Fortunately, the project was terminated before much hardware was built.

The position NASA took with changes to design requirements on this project was they were the customer and contractor Rockwell needed to do whatever they requested. It was a one-way street.

Are you really asking about Engineering Change Requests (or Proposals) (ECRs or ECPs) and Design Decision Records (DDRs)? This is the purview of a strong Systems Engineering oriented organization. Software is simply a tool, and if the engineers decide to use a hammer instead of a screwdriver, no software is going to stop them. That's an organizational discipline problem and comes only with repeated training.

There are lots of resources available on the web:

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert! faq731-376 forum1529