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)

   Develop example of POS system (see pp. 84-87)

------------------------------------------
SUPPLEMENTARY SPECIFICATION FOR POS SYSTEM

Introduction


Functionality
 (common across many use cases)
 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
 Human Factors
  The customer will be able to see
  a large-monitor display of the POS.
  Therefore:




  
------------------------------------------
        also think about errors, and that the cashier is doing
        several things that once. 
 
------------------------------------------
Reliability
 Reoverability


------------------------------------------
        ... how to deal failures of external services?

------------------------------------------
Performance


------------------------------------------
        ... influenced by human factors, should be probabalstic

------------------------------------------
Supportability
 Adaptability



 Configurability



------------------------------------------
        ... Deal with customers who have unique business rules
            and different kinds of networks etc.

------------------------------------------
Implementation Constraints


------------------------------------------
        ... might want to use Java to lower costs and improve
        long-term maintenance and portability

        try to avoid these if possible

------------------------------------------
Purchased Components


------------------------------------------
        ... the tax calculator must be purchased, and has to support
        different countries

------------------------------------------
Free Open Source Components


------------------------------------------
        ... might be able to use free Java components, 
            such as JLog logging framework

------------------------------------------
Interfaces
 Noteworthy Hardware and Interfaces





 Software Interfaces



------------------------------------------
        ... touch screen monitor, laser scanner, ... what else?

        ... have to collaborate with tax calculator at least

------------------------------------------
Domain (Business) Rules

 Id Rule              Changeability Source
 =========================================
 1. Require signature Low, but      Credit
    for payment       technology    comp.s
                      will change

 2. Tax rules         High, change  law
                      anually

 3. 







------------------------------------------
        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.

        other examples: 
        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
 Pricing
  Products have an original price, and
  optionally a permanent markdown price.


 Credit and Debit Payment Handline



 Sales Tax



 Item Identifiers



------------------------------------------
        ... credit payments need to be recorded in
        accounts receivable, from the authorization service
        often URLs are given for these

** 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.)

   Division 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  Alias
==========================================
item     A product or service
         for sale.

payment   
authoriz.

UPC

------------------------------------------
        enough to expand the data dictionary JML 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