|
The level of detail required in this step will depend on the complexity of the system. If the system being sought is likely to be extremely complex and you need lots of special features, this exercise should be extensive. If it is a relatively generic type of system e.g. an accounting system, or stock reporting system, the level of detail can be less.
The Functional Decomposition can be selectively expanded where requirements may be variable from vendors. For example, registering customers is going to be relatively generic. Calculating commissions in a multi-currency, multi-tiered organisation with several distribution networks is probably going to be complex. If you would expect that your requirements are not going to be met by many vendors, expand the functionality. Basically you are asking "Can you handle something that we do that is unique or at least unusual?"
The data model is similar. Don't try to list every attribute. Concentrate on the unusual. If the system is replacing an existing system, you might use your existing model as a starting point. Add in the attributes that you have always wanted to add. If you never had a field to log the birthday of your customers, make sure that is included with the data model.
The Business Processes may or may not need updating. Think of the model from a Vendor's perspective. Is there something about your business processes that needs explaining? For example, issuing invoices sounds like a simple process. If you split the invoices into state batches, then transport them to branches where, depending on a field on the invoice, some are mailed and some delivered by hand, it is worth documenting the business process.
|
