meeting -*- Outline -*- * Identifying Other Requirements (Larman, Ch. 7) Use cases aren't sufficient, need supplemental specification for non-functional requirements. Also need vision to sell the project, and clarify stakeholder's view. Glossary helps capture terms. ** Supplementary Specification (7.2-7.3) See also the example of the POS system (see Larman, pp. 84-87) ------------------------------------------ SUPPLEMENTARY SPECIFICATION FOR POS SYSTEM Introduction This document is the repository of all StickSync project requirements that are not captured in the use cases. Functionality (common across many use cases) ------------------------------------------ ...The system shall run on Macintosh and Windows computers and shall support synchronization between any combination of two such computers (for example, two Macs or one Mac and one Windows computer). The system shall support synchronizing sets of files whose total size exceeds the capacity of the PMSD, as long as the total size of the changed files does not exceed the capacity (with some margin for additional data). In the POS system this is: Logging and Error Handling log all errors to persistent storage Pluggable Business Rules the various other places several years cases allow the customer to customize the system with rules that execute Security ... ------------------------------------------ Usability ------------------------------------------ ... Users expect a graphical user interface. Power users and other tools would benefit from a command-line interface. There should be user-level help and documentation for all system functions. In the POS system: Human Factors The customer will be able to see a large-monitor display of the POS. also think about errors, and that the cashier is doing several things that once. ------------------------------------------ Reliability Recoverability ------------------------------------------ ... Race conditions should be prevented to ensure data is not corrupt. For example, multiple instances of the system should not be allowed to run and corrupting the data structures. If a PMSD that has been used by the system fails it should be easy for the user to synchronize the computers using another PMSD. Often this includes: how to deal failures of external services? ------------------------------------------ Performance ------------------------------------------ ...File transfers should run at a rate limited by the hardware. Often this is influenced by human factors, should be probabilistic (e.g., 90% of credit card authorizations within 1 minute). ------------------------------------------ Supportability ------------------------------------------ ... Future support for computers running Linux is desirable. The system should support future internationalization. For the POS system: ... Deal with customers who have unique business rules and different kinds of networks etc. ------------------------------------------ Implementation Constraints ------------------------------------------ ... must use Java (to lower costs and improve long-term maintenance and portability) try to avoid these if possible ------------------------------------------ Free Open Source Components ------------------------------------------ ... might be able to use free Java components, such as JLog logging framework ------------------------------------------ Interfaces Noteworthy Hardware and Interfaces Software Interfaces ------------------------------------------ ... the PMSD appears as a disk drive For the POS system, there is a software interface to the tax calculator (and perhaps other systems: accounting, inventory...) ------------------------------------------ Domain (Business) Rules ------------------------------------------ These are often called business rules, but can also be dictated by physics, chemistry, government, etc. Need to identify those that influence the requirements, but don't record system features as rules Domain rules should describe how the domain works, not the application. The PMSD must contain a table giving the modification date for every synchronized file on both synchronization partners. POS examples: Id Rule Changeability Source ========================================= 1. Require signature Low, but Credit for payment technology comp.s will change 2. Tax rules High, change law annually 3. credit for reversals may only be paid as a credit, not as cash 4. various customers have discounts (employees, seniors,...) 5. sale pricing 6. product discounts ------------------------------------------ Legal Issues ------------------------------------------ e.g., licensing of open source software following the tax laws ------------------------------------------ Information in Domains of Interest ------------------------------------------ Information about PMSDs with links For The POS System, information about pricing, credit and debit payment handling, sales taxes, item identifiers, etc. ** vision (7.4-7.5) The goal is to ensure that all the stakeholders are solving the same problem and that they are solving the right problem. Try to make sure that the problem themselves really will achieve the user's goals. (Sometimes the suggested solution isn't the best way.) The vision contains a summary of the user-level goals, and the system features. These are abstraction of the use cases (avoid duplication). suggestion: don't list more than 50 features This can be refined after writing the first batch of use cases. ** glossary or data dictionary (7.6-7.7) Larman suggests starting this early. ------------------------------------------ GLOSSARY (DATA DICTIONARY) Term Definition and information ========================================== local computer: the computer on which the user is currently working merge: to combine two sets of changes... PMSD: portable mass storage device, ------------------------------------------ enough to expand the data dictionary during elaboration. may need to also consider units (e.g. for money, temperature, etc.) can also put compound terms in the glossary ** recommendation Keep everything on a web site, hyperlinks are helpful. For example, terms can be hyperlinked to the glossary when first mentioned in other documents