Just as systems, products, and engagements have life cycles, requirements do as well. It’s easy to look at a requirements traceability matrix and imagine that all requirements spring magically anew from the ether during each engagement.
Let’s look at some considerations that drive requirements creation and reuse.
- Situation-specific requirements are the unique requirements that are identified and managed for the specific, local conditions and needs encountered in each engagement. Even if two different customers end up asking for and needing the exact same thing, the process of eliciting each of their expressed requirements is unique for that engagement. Most other types of requirements can be reused from engagement to engagement and from project to project and from release to release.
- Internal solution requirements are those related to the solution offered by the engagement team. Vendors, consultants and even internal solution providers tend not to develop solutions from a completely blank slate for every engagement. They tend to apply variations on a limited range of solution components from their areas of specialization. For example, I spent most of my career working for vendors and consultants offering particular kinds of solutions, e.g., turnkey thermo-mechanical pulping systems, nuclear power plant simulators, Filenet document imaging solutions, furnaces and control systems for the metals industry, operations research simulations, and so on. Other solution teams will apply different components and solutions for different areas of endeavor. Each of those solution offerings have their own implicit requirements that the customer must understand. My company may include a series of 22,000 horsepower double-disc refiners in its solution, but it’s also understood that the customer has to provide a certain kind of support flooring, drainage, access clearance, electrical power, water for cooling and sealing and lubrication, and so on. So actually, requirements can go in both directions (customer-to-solution team, and solution team-to-customer). Each standard component specified for a solution may carry its own standard (reused) and situation-specific (unique) requirements.
- Implementation tool (programming language, database system, communications protocols) requirements may be specified by customers for compatibility with other systems they operate. The furnace company I worked for provided fairly consistent solutions using similar logic and calculations, but we had to implement our Level One systems using a low-level industrial UI package specified by the customer (e.g., Wonderware or Allen-Bradley), and our Level Two supervisory control systems (my specialty) had to be written in a specified programming language (usually FORTRAN, C, or C++ at that time, and often from a specified vendor, e.g., Microsoft, DEC, or Borland, though I did at least one in Delphi/Pascal when I had the choice). Similarly, our systems had to interface with other systems using customer-specified communications protocols, and also had to interface with the customer’s plantwide DBMS system (e.g., Oracle, though many others were possible).
- Units requirements come into play when systems have to deal with different currencies or systems of measurement. When I used to write simulation-based, supervisory control systems for metals furnaces, the customers would request that some systems use English (e.g., American!) units while the remainder of systems had to use SI (metric) units.
- User Interface and Look and Feel requirements define consistent colors, logos, controls, layouts, and components that ensure an organization’s offerings provide a consistent user experience. This helps build messaging and branding among external users and customers and helps all users by reducing training costs and times.
- Financial requirements relate to Generally Accepted Accounting Principles (GAAP), methods of payment, currencies handled, taxes, payment terms and windows, withholding and escrow, regulations and reporting rules, guidelines for calculating fringe benefits and G&A and overhead, definitions for parameters used in modular/definable business rules, security for account and PII information and communication, storage and logging and backup of transactional data, access control for different personnel and users, and more.
- Methodological requirements may govern the way different phases of an engagement are carried out. This is especially germane to the work of external vendors and consultants. Particularly in cases where I did discovery and data collection at medical offices, airports, and land border ports of entry, our contracts included language describing how we needed to take pictures, record video, obtain drawings and ground plans, and conduct interviews with key personnel. Numerous requirements may be specified about how testing will be conducted and standards of acceptance. One Navy program I supported required that we follow a detailed MILSPEC for performing a full-scale independent VV&A exercise. Methodological requirements are depicted on the the RTM figure above as the items and lines at the bottom.
- Ongoing system requirements come into play when existing systems are maintained and modified. Many requirements for the originally installed system are likely to apply to post-deployment modifications.
- Non-functional requirements for system performance, levels of service, reliability, maintainability, and so on may apply across multiple efforts.
Requirements can come from a lot of places. While my framework addresses the active identification of requirements during an engagement, many of the requirements come implicitly from the knowledge and experience of the participants, and many others come explicitly from contracts governing engagements (at least for external solution teams). Many standard contracts are continuously accreting collections of various kinds of requirements.
What additional classes and sources of requirements can you think of?