Architecturally Significant Requirements in Practice: One Case Where ASRs Get Overlooked

In this article I will describe one case in practice where Architecturally Significant Requirements (ASRs) are so important but being overlooked. As a consequence, it brings down product quality and meanwhile increases costs of follow-up projects. The lessons learned include: it is very important to specify and emphasize ASRs in the requirements specification early to ensure the right Architectural Design Decisions (ADDs) be made.

Here is some background information for the case. The company has a Web-Based Application One (WBA1) for indirect customers (resellers and distributors) to quote and order the company’s products and services. WBA1 generates WBA1 Quote and indirect customers can quote with Special bids, Promotions and Programs which is implemented in the Special Bids Application (SBA) and Promotions and Programs Application (PPA). There is another Web-Based Application Two (WBA2) which is recently developed for indirect customers to quote and order the company’s Cloud Services particularly.

Now, there is a new project to enhance the WBA2 for enabling indirect customers to quote with Special Bids, Promotions and Programs. However, WBA2 currently generates its own type of quote which is different from the type of quote generated by WBA1. So WBA2 cannot directly and simply reuse the existing applications SBA and PPA because of its incompatible type of quote. But then, it is also too costly to write another application to deal with them. Besides, duplicating the same functionality will result in difficulties for maintenance. Consequently for the new project, the BA has to explicitly specify and emphasize that all quotes that WBA2 generates must be changed to WBA1 Quote type even though nothing will be changed by this requirement from the user’s perspective. This change of quote type shall also take place in scenarios when changing existing WBA2 Quotes or renewing existing WBA2 orders.

Therefore, this new project contains some rework for a previously-made wrong design decision. To some extent, it is a fix to an “error” made in a previous project. This rework or error could be avoided if the earlier project(s) for WBA2 could specify that “WBA2 shall be able to reuse existing SBA and PPA functionality in future releases” or “WBA2 shall allow indirect customers to quote with Special Bids, Promotions and Programs in future releases”. Thus, by considering this requirement, the solution architect would have had made much better decisions, i.e. “Generate WBA1 Quote for every quote created in WBA2”, at the very beginning.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>