A Two-Way Requirements Verification Process during Design Phase

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction

Software bugs and defects, the primary reason for delay of many projects, can be caused by many factors. Some of the factors include misunderstanding of requirements, incorrect analysis of functional design and mismanaged scope creep. These conditions can happen even with the adoption of a proven methodology.

Several methodologies such as Rational Unified Process (RUP), Extreme Programming (XP) or any agile development do their best to mitigate the risk at each phase of the development but still the problem does not go away completely. In fact, if poorly implemented, these methodologies even will contribute to the failure of a project.

Any Project Methodology is typically a one way process, though sometimes iterative, moves from one phase to the next when project’s stake holders, at each phase of the project, sign off on required deliverables.

This article will demonstrate a simple technique, “A Two- Way Requirements verification process”, which reinforces the most critical connection point of any methodology: the transition between functional design or requirement sign off and the beginning of the technical design by the technical team. It is also a concept, which enhances the communication between business users and technical team.

Process Description

Any agile methodology expects the organization to employ the right resources that are trained in the specific areas such as business analysis. Yet, many projects suffer from too many defects in the Q&A stage due to coding errors or misunderstood requirements, which often result in more work. The latter sometimes can even kill the project as this process can be caught in a vicious loop. One of the primary reasons for such failures is often due to lack of proper communication between the two most important groups of resources of any project; business users who would use the software product for their day-to-day business processes and the development resources who produce such product. The tips suggested in this article will help architects, business analysts or other senior resources, who act as the bridge between these two groups, to improve and enrich the process at each phase.

Figure 1, shown below, depicts a typical process with deliverables at each phase of the methodology and the required resources to produce the artifacts. The improved process is depicted shaded in green. This example is demonstrated using the Rational Unified Process (RUP). Any agile methodology or home-grown SDLC can utilize the concept demonstrated here.

Development Phases and Processes:

Key Improvements

1. 2a – Detail Requirement or Functional Design: Verify the
   functional design by using Activity Diagrams, which will be
   derived from Use Case Flows. The review needs to be done not
   only with business analysts but also with the business
   users. The discussion can be facilitated by Business
   Analysts.
   
   
   
   • a. The purpose is to review with the business from
     technical perspective without technical language.
   
   
   
   


2. 2b – Candidate Architecture and Technical Design: This
   is the key area where critical 2-way requirements
   verification needs to happen in an iterative way.
   • a. Using the Activity Diagrams developed in the previous
     phase, review the functional flow for the following
     conditions. Hint: Technical team needs to ask questions as
     if they are writing code.
   
   
   • i. Error Conditions for functional or business logic
     failures, technical failures and the relevant user
     experience expected under such conditions.
   
   
   • ii. Try to get the severe defects that occurred in all
     the business areas in production and use them to shape the
     questions. It also, forces business users to bring similar
     information to the table.
     Example: While designing a
     retail banking site or any transaction site for credit card
     payments, try to see what kind of problems other functional
     areas of the bank had faced and what other banks are doing.
     This type of forum can also present an opportunity to quiz
     or offer suggestions to business users about different or
     better options from ever changing compliance, regulations
     and/or from security perspective.
   
   
   • iii. Repeat the process while doing the technical
     design.
   
   
   • iv. Make sure Business Analysts and Business Users will
     review final artifacts and sign off.
   
   
   
   
   • b. Technical team needs to lead the discussion. The best
     results can be obtained if this is done as a Joint
     Application Development (JAD) process.
     
   
   
   
   
3. 2c – Detail Technical Design: While finishing up the
   technical design, complete the Unit Tests with some business
   scenarios as much as possible. Review them with business
   analysts and business users.
• a. Take advantage of QA groups and involve QA resource
  at this stage to develop the unit tests.


4. 3- Construction: Code Development and Unit Testing:
   Since it is common to do a mini Elaboration Phase at the
   beginning of the construction phase, make sure the above
   points are discussed at each of these mini elaboration
   phases.

Conclusion

This is a simple yet powerful technique if used properly.
This is not a silver bullet for all the problems but would
certainly help to minimize the risk and defects and puts the
focus on key aspects of any software solution
development.