Requirements Engineering: Our Best Practices

[article]

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,

About the author

Bonney Joseph's picture Bonney Joseph

Bonney Joseph has been in the IT industry for over ten years and has experience across the IT Solution Delivery lifecycle, with specialized skills in Agile, RUP and CMMI. His areas of focus include testing, requirements, process, quality and project management. He is currently engaged in process excellence consulting for a major European financial services customer being part of their CMMI ML3 journey and involved in an enterprise wide RUP roll-out. His paper on Software Test Diagnostic Model (STDM) was selected for presentation at the QAI and PSQT international testing conferences. For questions or comments on the published article, the author can be reached at bonney.joseph@wipro.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01