Requirements Engineering: Our Best Practices


This article focuses on a methodology adopted during a requirements and functional specification phase of a project. The chosen model for requirements engineering was founded on a combination of six sigma techniques and a set of best practices adopted from within the organization.

The whole requirements engineering process might seem daunting at first considering the uncertainties and unknowns involved, but the trick is to adopt a process that fits your need and is recognizable and repeatable across your domain. Even though it's often ignored or done in a hurry, the requirement management phase is easily the most important phase in your development lifecycle. Why is requirements management so important?

  • Requirements traceability to design and code unaccomplished
  • Requirements churn and leads to scope creep
  • Modules don't integrate
  • Code is hard to maintain
  • Poor performance under load
  • Build-and-release issues
  • Ultimately, user or business needs are not met

Problem Statement/Our Project Scenario
The client wanted to roll out his next-generation, factory-automation equipment ahead of a competitor. This called for enhancing features in the existing product, making changes to the controller configuration, and releasing a product that was superior in performance and efficiency. The challenges for the software team included adapting to ever-changing customer priorities, trying to hit on a development model that would fit the bill, implementing an effective change management process, and coming up with a test strategy and infrastructure to ensure as smooth a high-quality release as our committed schedules would allow.

The Methodology
The SDLC model chosen was a combination of the iterative and V-models. Even though we had chosen our model, we had to wait for the requirements, which arrived late and incomplete. We assumed it would be futile to wait for all the requirements to come in and then start planning for testing, validation, and verification activities.

Development started on tasks such as high-level design, non-functional requirements analysis, risk analysis, and code analysis. Thus, we were prepared by the time the enhancement requests for the new product were delivered by the customer. The hybrid model adopted called for just the RS phase and an incremental iterative implementation cycle for the coding and testing phase of the V-model, as shown in figure 1.

Figure 1: SDLC phases and activities.

This article focuses on the methodology adopted in the requirements and functional specification phases. The chosen model for requirements engineering was founded on a set of ten best practices adopted from within the organization:

Best Practice 1: Study of product features
Best Practice 2: Detailed analysis of product features
Best Practice 3: Functionality analysis
Best Practice 4: Code analysis (parallel bottom-up approach)
Best Practice 5: Product requirement document (PRD)
Best Practice 6: Sequence diagrams and detailed design documents
Best Practice 7: Quality standards compliance
Best Practice 8: Unified change management process and tools
Best Practice 9: Hardware soft simulators
Best Practice 10: Six Sigma methodology

We first started with the study of product features activity. The objective was to study the features offered by existing product variants so we could compile a list of anticipated features in the target product. In addition, this exercise also provided the onsite and offshore teams an opportunity to identify with the target machine to be built based on existing feature inventory. The deliverable that came out of this activity was the G-Spec document (generic specification).

Then we completed a detailed analysis of product features . The primary objectives of this exercise were to expand each feature in detail to the design specification level based on the customer's input. The Voice of the Customer (VOC) a proven six sigma tool was adopted for this purpose in which the interviews with requirement providers focused on a Who, What, Why, When, Where, and How questioning style. This exercise also revealed gaps in our understanding of the product and helped improve knowledge in the industrial automation domain. The deliverable from this

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.