phase of the project was an updated VOC document.
Afterward, we started the functionality analysis activity, in which the major functionalities were broken down into sub-functionalities and operational scenarios were analyzed. Use cases were derived from this sub-functionalities document, and the system use case specification document was created. The requirements-in the form of product understanding, business functions, feature specifications, external interfaces (software, hardware, UI, and communication), operational sequences, use cases, and non-functional requirements-were captured in the PRD. This was further refined as more information and requirements became available.
Around the same time, a parallel activity began wherein a core team of senior developers began looking through the source code to understand the logical flow as well as the layout in terms of classes and function calls. The customer had shared the source code of the current system that it intended to upgrade. This code analysis activity helped to bring forth a picture of the machine that was hitherto not clear to everybody. As a result of the code analysis and operational sequences study, the team could now create UML sequences diagrams using Rational Rose and detailed design documents. Using a traceability matrix, these sequence diagram IDs were then traced to class names or code segments to ensure bi-directional traceability.
We couldn't do all this without an eye for quality. Requirements were captured following the quality standards compliance requirements guidelines stated by the ISO standards, viz ISO 9126, EN 50128, and IEC 60158. During the requirements specification phase, a few of the ISO 50128 standard techniques were considered after a detailed analysis of the sixty-eight-odd recommended techniques. The ISO 50128 standard techniques we used are listed below:
- Cause consequence diagrams (B.6)-fault tree analysis (FTA)
- Data flow diagrams (B.12)
- Hazard and operability study (B.34)
- Impact analysis (B.35)
- Performance requirements (B.46)
- Prototyping /animation (B.49)
After a detailed review of relevant Six Sigma tools that the project could leverage, it was decided to use VOC, quality function deployment (QFD), failure mode and effect analysis (FMEA), requirements analysis matrix (RAM), orthogonal array (OA), cause and effect analysis (C-E), design structure matrix (DSM), and Pugh matrix.
Requirements management posed a challenge as we were never sure in what form the requirements would finally emerge from the customer design team. To preempt that risk, the project team defined its own demand specification template and got the customer to provide requirements in the prescribed format. The change impact analysis process was clearly defined and communicated to the customer as well as to the project team. High-level steps included:
1. Get requirements in the demand specification template
2. Expand the demand statement using VOC analysis (who, what, when, where, why, and how)
3. Analyze engineering impacts
a. The "how's" yield clues around impacted features
b. Using the QFD, identify associated functionality and design parameters (These design parameters were the engineering items that were scrutinized
to determine their impact.)
4. Review meeting to analyze if a problem requires only a hardware/machine tweak or if it requires a software change
5. Analyze software impacts
a. Using the QFD, identify all the functionalities (use cases) that are impacted
b. For each use case, analyze GUI and controller change required using a detailed functional traceability mapping (referred to as the X-Y map)
c. Conduct risk analysis based on FMEA so the potential regressive damage due to the change is minimized
6. Create the change request impact analysis document and review with customer
7. On approval, implement the change. Also, make the necessary modifications to related artifacts: PRD, UML diagrams, QFD, G-Spec, etc.
Testable requirements are a key ingredient to a project's success,