2.2 ISDN Case Study Requirements

---

2.2 ISDN Case Study Requirements

Requirements are the conditions one must create to do justice to project scope. Another way of looking at requirements is to say they are the descriptors of "target state." In the ISDN case study in Chapter 1, we listed some of the desired features of target state. Let us restate them in a way that more properly supports the concept of requirements gathering. Please note that, for the sake of brevity, some detail has been omitted. If system design or telecom provisioning do not happen to be your cup of tea, instead of focusing on the detail, make note of the liberal use of declarative sentences.

• Sales order entry module

  • Customer service representative (CSR) can interact with the customer and the system "real time."

  • CSR can validate the customer account, credit worthiness, and site address upon entry of customer-supplied name, address, or telephone number.

  • CSR can ascertain availability of ISDN to customer site.

  • CSR can provide the customer with future availability of ISDN at the customer site, based on system forecast.

  • CSR can provide technical details on types of ISDN ^[1] offered at that time, and commensurate charges.

  • CSR can initiate an order based on the customer acceptance of prospective installation date, charges, and the specific ISDN service to be installed.

• Construction module

  • Request to provide service not currently available is routed to outside plant engineering (OSP) assigned to the central office serving the customer for that order.

  • OSP uses the system to issue construction order to legacy workforce system.

  • OSP uses the system to track each project.

  • CSR can access the construction module to provide customer updates as required.

• Provisioning module

  • Upon automated validation of service availability, the system shall send appropriate codes to the central office switch to program assigned port with customer-selected ISDN service features.

  • Any error codes on provisioning failure will be sent to legacy switch maintenance queue.

  • Successful provisioning causes notification to the billing system that the service is turned up for that customer account.

• Customer site dispatch module

  • System will initiate dispatch record in legacy workforce system to dispatch an ISDN technician to customer site for final installation.

  • System will receive updates from the legacy workforce system so the sales CSR can status site installation as required.

• Reporting module

  • All data generated by this system shall be available for canned reports and ad hoc queries showing detailed and summarized reports of sales and construction activity that can be broken down by ISDN service types, serving the central office, and other means to be determined.

2.2.1 What These Requirements Show

• Detail. In a perfect world, a requirements document should tell you exactly what the target state looks like. Put another way, we should know exactly what we are trying to accomplish. We do that by carefully building a detailed requirements document.

• Workflow. Requirements are descriptors of target state. In this case, project scope dictates the creation of an automated toolset, so it makes sense to describe each task the system must enable the end user to perform.

• Key features. Phrases such as "legacy system" are used to indicate that the new system shall interact with existing systems or processes. Phrases such as "real time" and "automatically" indicate whether or not the user has to initiate certain system events, as well as the availability of data sets.

• Reserved requirements. Requirements for the reporting module has both specificity as well as the dreaded "TBD" (to be determined). Although it is not a welcome term in a requirements document, "TBD" is acceptable only to the degree that it is unavoidable.

2.2.2 What These Requirements Do Not Show

• System design and architecture. Nothing is mentioned about which hardware and software platform will be used. In 1996, the mainframe or client server would have been the likely candidates, but from a requirements perspective, that was not important, nor was the method for linking to legacy systems, even though required links were defined.

• Timelines. Timelines were not mentioned because they were not critical to requirement. In many projects, milestone dates could merit inclusion. In the Y2K project world, for instance, one particular date was essentially the key requirement.

• Product identification. Many projects are product-based. In the ISDN project, there was no need to mention any, but in others it may be appropriate to name names. For instance, if the scope is to upgrade the local area network (LAN) operating system on 500 file servers, chances are the change is to the incumbent manufacturer's latest release, rather than a migration to a competing product. Common sense must prevail when articulating requirements. If Product X must be used, say so.

• Rationale and other rhetoric. Requirements are requirements. Why they are significant, and how they evolved, can be important for any number of reasons, but those stories normally do not warrant inclusion in your requirements document.

^[1]At the time, the plan was to implement 6 of the 72 ISDN "flavors."

---