[In the "System Design Factors" blog series, Blake Deakin will be examining key design attributes and critical decision-making throughout the implementation life cycle. Each entry will dig deeper into specific concepts and introduce practical techniques for assessing and improving upon system design throughout the development life cycle.] Clearly, the perceived functionality of the system from the end user perspective is the most visible, if not the most critical, system design factor. This is the proverbial “reason for the season”; the organization has expended significant resources and taken on risk to achieve a stated objective, typically defined in a project charter and a set of user requirements.
Yet too often functionality is considered only through the lens of atomic requirements satisfaction: does the delivered system meet all of the “must have” requirements? And this approach would be good enough if not for the reality that many URS documents are not created with a degree of craft that truly enables an effective waterfall development cycle and delivery.
At Sparta Systems, we recognize this typical deficiency in the development lifecycle and we mitigate it by following an iterative approach to prototype development which allows the end user community to “see the solution” quickly and with a minimum of effort, and then subsequently provide feedback to guide further development. With that said, however, we still identify missed opportunities due to lack of upfront requirements definition. Some typical problems we encounter are:
1. Lack of business/system process mapping; where does the customer’s business process end and the system begin? How do they integrate to drive an efficient and value-added process?
2. Failure to identify non-functional requirements, such as the expected time to complete an individual operation by an end-user. By way of example, a requirement such as, “The system shall permit for end users to initiate a complaint record within 2 minutes, assuming all data fields must be completed,” is a fantastic, intent-driven requirement which can help inform critical design decisions.
3. Language is non-natural and impenetrable for a typical end user, who is asked to review and comment on the document. Often times the project plan does not account for sufficient review and comment period.
4. Basic requirements documentation, such as a URS or even a project charter, is not developed to at least a draft state prior to the project kick-off.
These issues arise in part because many of our customers treat URS documents as a simple compliance requirement for driving performance qualification instead of treating it as an opportunity to describe “what the system should do” in natural language. Changing the philosophy and treating the URS as an opportunity to create a true “system roadmap,” while more time consuming than more agile methodologies, manages risk and improves the likelihood of a successful development and deployment cycle.
With all that said, once the requirements definition process has sufficiently matured where the URS can be used as a true tool to aid development, reasonable questions around what functionality must be delivered vs. what can or should be delivered can take place. This is where the rubber hits the road and where having a comprehensive view of system design factors becomes critical.
For example, there may be a user requirement that a given system should poll an external database for the existence of a new complaint in a case management system every minute(“nice to have”), but must poll every 10 minutes (“must have”) and initiate a record within TrackWise for investigation and CAPA. However, having that process run every minute could put undue stress on the case management system, negatively impacting performance (Technical Scalability). Based on this, the implementer would make a decision to have the polling mechanism work every 10 minutes. In this way, having a robust view of design factors enables an implementation practitioner to make intelligent, value-driven decisions.