In part one of this article we began a description of the Business Requirements Analysis (BRA) process and work products of QED Software Ltd. of New Zealand.   The process originates from traditional structured techniques, but has been heavily influenced by the latest object oriented techniques -- in particular, the Unified Modeling Language (UML).

The process itself represents the second phase in QED's System Development Life Cycle (SDLC), following the Business Needs Analysis phase and is itself followed by the traditional Design, Build, Testing, and Implementation phases.

To recap, the BRA process involves the following steps:

1.	The project owner identifies which business processes are targeted for automated support.   Based on this, and initial input from key business users, the Analyst drafts the Scope document.
2.	The Scope document is reviewed and signed off.
3.	Analyst(s) conduct BRA sessions with key user participants.
	3.1	For each business process identified to be in scope:
		3.1.1	Critical Workflows and/or Use Cases are modeled as UML Action Diagrams.
		3.1.2	Analyst documents Action Diagrams.
		3.1.3	Stakeholders review documented Action Diagrams.
		3.1.4	Use Cases identified in Action Diagrams are further analyzed.
	3.2	Analyst documents Use Cases, [Entity] Class model, and Business Rules.
	3.3	Required interfaces and reports are identified and documented.
	3.4	Analyst drafts Administration Use Cases.
	3.5	[Ongoing] Review of documented elements by participants.
4.	Functional Specification (FS) is drafted (combined results of Step 3) and reviewed by stakeholders.
5.	FS is revised and prepared for signoff.
6.	FS is signed off.
7.	Scope document is revised to serve as an 'Introduction' to the system.

The first part of this article took us midway through BRA Step 3.2, having presented an example use case diagram (included here as Figure 1) and the textual description of its main use case.   We will continue in this article by presenting the rest of this use case's documentation of alternate use cases, exceptional conditions, and an example of one of its scenarios.   Following this, we will discuss other work products of the BRA process, including the Entity Class model, Business Rules, and specifications for Reports and system Interfaces.

The final work product of BRA is produced in Step 7 -- a revised Scope document.   The scope itself is not revised at this point but rather its documentation is given the benefit of all of the analysis that has gone on since the Scope document was originally drafted in Step 1 and signed off.   This is similar to updating or correcting a design document based on errors discovered or adjustments required during the build phase.

BRA Step 3.2a -- Document the Use Cases (continued)

The use case diagram in Figure 1 was originally presented in part one of this article.   This use case was identified (i.e., discovered) as a task within a workflow in which the worker/actor gains value by interacting with the new STS application.   That workflow (presented in Part one) was analyzed as part of the BRA detail of one of the business processes identified to be in scope.

Figure 1: Example Use Case Diagram

The Main Flow of this use case, described previously, goes into field-by-field detail of the user interacting with the application in the most common type of situation (be it good or bad).   We are now ready to investigate "Alternate flows."   An Alternate flow represents the same business task being carried out but reflects circumstances dictating that the interaction with the application is not the same as the Main Flow.   Ideally these differences are only temporary sidetracks.   Or it may be that in special cases, slightly different information needs to be dealt with.

An example of this is a banking withdrawal transaction in which, when everything goes normally, the customer ends up with the cash requested.   An alternative flow (hopefully the exception rather than the rule) describes the case where there are insufficient funds for the amount requested.   One alternate flow results in the customer leaving with a lesser amount.   Another alternative covers the case where the customer leaves empty handed.   A third alternative might describe invoking a separate use case in which the customer transfers funds from one account to another.   All of these are variations on the initial main use case theme.   From within the context of the main use case, each alternate flow only requires a description of those interactions that differ.

When a use case describes a 'transaction' type of task (such as a sale), the main use case typically involves creating an instance of the transaction, with a possible alternate use case that allows the user to modify an existing transaction.   Conversely, when the use case involves a type of information that supports a transaction (e.g., maintaining customer details, maintaining product details), the more typical situation involves the actor updating the information, with the less frequent situation involving the need to add an item treated as an alternate flow.   In cases where both the add and update are particularly complex, they are defined as two completely separate use cases (each with its own possible alternate flows).   A simple rule of thumb is "If an alternate flow has alternatives of its own, it's probably best to promote it to a main use case."

The main use case described previously (and shown in Figure 1) has two alternate flows that are described as follows:

Alternate Flow A-1 -- Enter additional application for same caregiver: This alternate flow applies when the same caregiver has submitted more than one transport assistance application (i.e., the "Submitting other sibling" field was ticked.   When the user selects "Next" after entering the details of the first application, the new application screen presented has the values in all the fields from the current application retained.

Alternate Flow A-2 -- Similar Students Exist in STS: This alternate flow applies when an application being submitted involves a student whose name is a near match to one or more other students already on the database (but not an exact match of both name and date of birth).

As part of the 'Save' process, before a student record is created, STS performs a lookup for possible matches (see UC062 -- Lookup Student Name).   When one or more non-exact matches are found, the user is presented with a list from which he/she can choose a specific one (or none).   The result is either: the selected student is associated with the application being saved, or else (when none selected) a new student is created and associated with the application being saved.

The main use case and the alternate flows are all ways for the actor to complete the task at hand in some acceptable manner, as far as the business is concerned.   However, any given task has the potential for user error.   The possible types of error need to be identified and documented.

These errors can be as simple as information entered of the wrong data type (e.g., non-dates in date fields, non-numeric characters in amount fields) or other domain-related errors.   Another common error is information that is mandatory not being provided at a particular point in time, either initially, or when an item is about to enter a particular status.   And then there are potential cross-field errors, such as an end date mistakenly given that is earlier than its associated begin date.

Within use cases, the simple business rules that need to be enforced are listed under the heading "Exceptional conditions."   What needs to be described is anything from a business perspective that can prevent the use case from completing successfully unless corrective action is taken by the actor.

The use case we have been presenting has made reference to two exceptional conditions:

Alternate Flow (Exception) E-1: If any input fields contain data that is of an invalid format (e.g., dates) or any mandatory fields are left blank user is advised.

Alternate Flow (Exception) E-2: If the dates occur in the future, the user is advised.

The objective in documenting exceptional conditions is to describe just enough detail to give the business users reviewing the spec the confidence that the application to be delivered will maintain integrity.   At the same time these descriptions must provide the application designers sufficient details to specify the integrity mechanisms to be invoked, based on the eventual technology employed (e.g., client/server, ultra-thin client).

Use Case Scenarios

*/ ?>

Use cases describe the user (actor) interacting with the application in terms of types of information (i.e., named attributes).   For many years the concept of testing designs prior to building has been talked about.   Use cases include this concept.

Each use case (main flow and alternate flows) is tested on paper by documenting what are called scenarios.   There should be at least one scenario per use case and alternate flow.   However, if time and resources permit, additional scenarios that test a variety of data situations should be included, particularly in critical use cases.

Sidebar 1 gives an example of a scenario for the main use case in our running example, "Enter Transport Assistance Application."   In this use case, the main flow describes the 'bulk entry' of applications, so the user begins with the use case already logged on and positioned at a screen representing a 'new' record waiting for data to be filled in, based on a paper-base application that had been submitted.

While documenting scenarios might seem like a lot of work (which, in reality is the case), the effort is justified because it serves three separate and valuable purposes.   As mentioned earlier, scenarios act to prove the use case by 'walking through' them on paper.   Second, the real-world values they contain are very helpful when actual screens are being designed in the next development phase.   Instead of producing designs that simply show empty fields, or fields filled with generic Xs for characters and 9s for numerics, the designer has access to sample data, allowing the screen designs to look more like the intended end result.   And finally, the scenarios support application testing.   While the sample values may not be the ones used in test cases, the scenarios themselves are well on their way to being test scripts.   Typically there is never enough time in the test phase of a project.   Any pre-work that can be done to support that effort will be of great benefit to the project overall.

BRA Step 3.2b -- Document the Entity Class Model

*/ ?>

Developed in parallel with the use cases is a UML static Entity Class model.   It is made up of the relevant entity classes, including all relevant relationships and attributes.^[1]

Use cases describe the creating of entity class instances (e.g., capturing a new customer order), updating them (e.g., changing the quantity of a particular order line item), and referencing them (e.g., inquiring on an order's status or an account balance).   Because of this, the static Entity Class model acts as an additional source (or check) of required use cases.

All primary information concepts will require tailored use cases and possibly several, depending on the business workflows relating to them.   Some entity classes, like those representing simple coding schemes, need not be individually documented as use cases.   Many of these can be accounted for in a generic 'Administration' business function in a special section of the Functional Spec (described later in this article).

In QED's BRA process, the static Entity Class model is a work product, but it is neither included in the Functional Spec document nor is it signed off by users.   Use cases are all about 'views' of the static model.   They represent information from one or more entity classes being presented on a screen or other interface device.   Business users need not be concerned with either the entity classes or their eventual physical database structure.   Asking users to review both the use cases and the entity classes they are based on would be redundant.   Since the use cases are much more user [review/signoff] friendly, this is what is presented.

The Entity Class model is used by the analyst as a detailed Glossary.   It contains the agreed names of both entity classes and attributes, and it records their definitions.   These names are used consistently by the analyst in documenting all use cases, thereby avoiding any possible name-related ambiguity typically found in textual descriptions.

While use cases are being documented, the analyst is responsible for making sure that every field involved is accounted for in an entity class or derivable from entity class attributes.   The Primary Information Concepts from the Scoping document are intended to be a starter set of entity classes.   Additional entity classes are named and defined as the analysis continues.   Together, they become homes for attributes and connection points for relationships.   Values that are derived (e.g., totals and other derivable values) are either represented as attributes in the appropriate entity class or else there is a Business Rule (see below) describing their derivation.   Any derivable attribute in the static Entity Class model is identified as such.

While the overall Entity Class model is not presented to users, a number of simplified entity class 'views' are included in the Functional Spec as part of the overview to each Business Function sub-section (see Figure 2).

Figure 2: Non-Special Ed Student Entity Class Model View

These simplified entity class views are a useful visual aid during BRA sessions between the analyst and participating users.   What adds value to these diagrams in the Functional Specification document is a textual description, based on the context of the business process the veiw is supporting.   Sidebar 2 presents an example of this kind of view description (matching the diagram shown as Figure 2).

Each entity class significant enough to be shown in one or more of those views has its definition included in the FS Glossary (along with other useful business terms and abbreviations).   QED maintains the Entity Class model in a CASE tool, allowing reports and diagrams to be produced, as required, and supporting eventual database design.

BRA Step 3.2c -- Document the Business Rules

There are three general types of business rule of interest during the BRA process:

• Data validation
• Data derivation
• Triggered Process(es)

Use cases directly address data validation through the description of exceptional conditions, as shown in previous examples.   This includes the concepts of datatype (e.g., integer, dates), explicit limits of values in terms of numeric size or string length, and cases where field values are mandatory.

Data derivation rules, when simple (e.g., deriving Age based on date of birth and current system date) are dealt with by including a description of the derivation as part of the attribute's definition.   More complex derivations – such as those that involve multiple references to different attributes (e.g., the calculation of the price of a given item, taking into account discounts that are customer-specific) -- need to be documented as explicit business rules, that can be reviewed and 'signed off' by users.   These business rules are not use cases.   They do not describe an actor interacting with the application.   Instead, they describe what will eventually be an algorithm within the application that is invoked at appropriate times.   Sidebar 3 presents an example of a critical business rule work product from the STS Functional Specification.   This example was a 'behind the scenes' derivation rule.

Note that similar to use cases having scenarios, business rule descriptions should include examples.   These examples serve the same purpose of scenarios in that they prove the rule on paper and provide guidance for later testing.

There are also no use cases for 'triggered' processes.   As with simple derivations, when these triggered processes are simple (i.e., the next step in the workflow), there may be no need for an explicit business rule.   However, when the required steps are significant, they are worth documenting for review and signoff.   Sidebar 4 presents an example of a process that derives not just one data value, but is responsible for creating a whole set of (derived) records.

NOTE:   As with use cases, the terminology used in a business rule description is consistent, and based on the behind-the-scenes Entity Class model.

UML supports certain Entity Class model rules explicitly with graphics and/or fielded information (e.g., domain constraints and constraints between relationships).   It also provides for constraint annotations to be attached to artifacts within the models.   However, because QED does not expect business users to be able to read or understand these graphical notations,   BRA includes business rule work products such as the two examples presented here as part of the Functional Specification document.   As with use cases, these rules are individually numbered and, as such, are considered as part of the agreed deliverable.   Changes to business rules, as with all other agreed work products, are subject to change control following signoff.

BRA Step 3.3 -- Document Reports and Interfaces

Report Specifications

*/ ?>

No one would argue that 'killing trees' is bad.   Wherever possible, information required by users of an application should be presented 'on-line' and only printed when necessary.   Actors requiring specific information from the database in performing their normal tasks should be covered by individual use cases for those tasks.   But in cases where the persons needing the information are not actors (i.e., have no direct access to the application) we may need to resort to specifying reports.^[2]

As with business rules, reports are not really use cases.   While an actor may interact with the application to request the report, this kind of interaction is typically generic -- such as, "Go through the menu structure to the 'reports' area and select the desired report (providing any selection criteria values).  " There is little value in describing this for each type of report.   Part of the user interface design should simply specify how reports are requested.   An acceptable 'look and feel' (i.e., a design issue) is required to make requesting reports truly user friendly.

However, as with use cases, we want to gather details on required reports to the 'field' level, while stopping short of actually 'laying out' a given report.   If the report that is needed by the new application is based on one that currently exists (i.e., is produced by an existing application but will continue to be produced by the future application) then simply 'referencing' that report is sufficient.   Otherwise, the report should be described in terms of what records are to be included (i.e., selection criteria, sorting and grouping criteria) and columns (i.e., specific fields).

As with the user interfaces described in use cases, the fields presented in reports (fully described or simply referenced) need to be part of the Entity Class model, either as stored values, derived values, or in exception cases, business rule derivation descriptions.   Sidebar 5 presents an example of a report specification as a work product of BRA, included in a Functional Specification in a special 'Reports' section.

Note that even at this point it is still possible to save a tree.   We have not specified that this is a 'printed' report.   We have only stated that it is information in the 'style' of a report (i.e., has explicit selection criteria, etc.).   Thanks to electronic communication, the actual output might be made available via the Web or possibly sent to the recipient electronically.   It is then up to the viewer(s) to make a paper-based copy if needed.

System Interfaces

*/ ?>

When the Scope diagram includes actors that represent other systems that this application interfaces with, those interfaces need to be described.   As with business rules and reports, these interfaces are not covered by use cases.^[3]    They are either triggered automatically (e.g., based on the system clock initiating a periodic batch process) or else as the result of some actor 'initiating a function' (e.g., pushing a specific button).

System interfaces typically involve a significant amount of technical detail best left to design.   However, as part of BRA we need to at least describe the specific types of information that pass through the interface in one direction or the other.   As with reports, this detail is at the field level, again based on the Entity Class model and/or derivation business rules.

The original Scope diagram only identified that there was an interface.   There may actually be a number of different transfers of types of data, or different transfers between the two systems.   Each of these is identified and described in terms of frequency, selection of records for transfer, and specific fields.   Sidebar 6 presents an example of an Interface Description work product.

BRA Step 3.4 -- Document Administration Use Cases

Administration tasks for an application affect 'business' actors indirectly.   These include:

• Maintaining Security Profiles
• Adding and removing Users
• Maintaining simple 'code' tables
• Maintaining application parameters

While it is possible to utilize use cases to describe the tasks above, we avoid doing so to reduce both documentation effort and user review time.   The reasons this is possible are (a) these tasks are typically assigned to one or two specific individuals and (b) they are so generic that they are reused from application to application and therefore require neither designing nor building.

In any case the first two tasks would require little or no input from business users during BRA.   QED has a standard technique for handling security, which includes table-driven 'Roles' linked to 'Functions,' which are also table-driven.   As users are added they are associated with the roles they require, which in turn gives them access to appropriate functions for each of the roles.

The latter two tasks (maintaining simple codes and parameters) do require user input during BRA and become part of the Functional Spec.   As different code types are discovered, they are added to a list, along with sample values (or a complete set of values, if possible and of manageable length).   Also recorded is which actor should normally be responsible for authorizing new values.

Similarly, as individual 'global' values are identified they are documented in a simple list (e.g., the day and month marking the start of the organization's financial year).   These are typically common values that 'almost never' change.   While this stability may be true, experience has shown that (a) things do change and (b) when they do, if that change was not planned for, it is a very expensive change to make.

But planning for this possibility at the beginning of a project is both cheap and easy.   It simply involves recording each such 'stand alone' attribute in a list of parameters, describing it in a sentence or two, and recording its 'current' value.   These parameter 'names' (as with entity class and attribute names) can then be used consistently when they come up in use case descriptions, business rules, etc.   Eventually a simple 'maintenance' function will be designed and delivered (or ideally reused from already-developed applications).   A single function handles the whole list of parameters.

The ability to change values once the application is up and running is typically highly restricted -- usually to one or two individuals assigned a 'system administration' role.

BRA Step 4 - The Functional Specification Document

During the weeks of Business Requirements Analysis, there has been an ongoing cycle of sessions with users followed by documenting those sessions as work products (i.e., use cases, entity classes, business rules, etc.), followed by review and feedback of those work products by the users who were involved in the sessions.

When this cycle comes to an end (as we know it will, thanks to the Scope document that has been guiding the process), the results are combined into a single document for final sign off.   Within the QED SDLC this document is called a Functional Specification (FS).   It contains the following sections:

1. Executive Summary
2. Business Functions
3. Standard Reports
4. System Interfaces
5. Business Rules
6. Glossary

The Business Functions section is further broken down into sub-sections, one for each Business Process identified in the Scope document.   Each sub-section contains the specific use cases identified in the workflow diagrams and/or other detailed analysis related to that particular business process.   And in this section, there are two additional sub-sections.   One is for 'Shared' [business] Functions.   This section holds 'reusable' use cases that appeared in multiple workflows and/or use case diagrams.   The second is for the 'Administration' tasks just described.

BRA Step 5 - Preparation for FS Signoff

By the time the Functional Spec is assembled, each of its component parts has been individually seen and reviewed by the user participants.   Each of these individuals has had a chance to provide feedback.   In some cases, review sessions are held where the results of particular BRA sessions are presented to users and/or discussed.   Based on this feedback the analyst has made corrections or added clarifications.   Thus, when it comes time for actual signoff of the entire document (that typically runs well over 250 pages), there should be no surprises or any significant outstanding issues.

No one wants to remain in the analysis phase forever.^[4]    At the same time, it would be nice to know that the results of the analysis phase are 100% complete and correct.   Unfortunately, as the 80/20 rule tells us, getting those last few bits exactly right becomes increasingly costly and time consuming.

The alternative offered by the QED SDLC process is to do everything possible to minimize the risks.   This is why the business requirements analysis phase does/did the following:

• Used a top-down methodology to ensure that no 'big' pieces have been missed
• Modeled critical business workflows, ensuring that how the business operates/will operate is reasonable and understood
• Described individual use cases, ensuring that the proposed application will support selected workflow tasks and other business interactions with the application
• Recorded use case scenarios, thereby proving the use cases with actual business data
• Recorded and reviewed business rules, thus documenting critical aspects of the business that must be supported by the new application.
• Involved the best possible business user resources, both to contribute to the analysis and review the results

BRA Step 6 -- User Signoff of Functional Spec

The Functional Specification document is signed off by:

• Its author(s) -- confirming responsibility for the content (with appropriate acknowledgements to contributions by business users)
• Representatives of QED management -- indicating that they accept responsibility for work done by staff on behalf of their company
• Client representatives (Project Owner and Manager) -- indicating that the descriptions of the use cases, business rules, interfaces and reports represent the basis for further design and development of the application the require.

While the actual project owner responsible for signoff is unlikely to have had time to participate in either the sessions or the review of early drafts, he/she should be able to rely on the designated user representatives who were involved to attest to the correctness and completeness of their sections of the document.   The owner will certainly want to read it before signing.

However, a functional specification is in no way like a novel.   It is made up of many detailed sections and a great deal of content.   The whole idea of the BRA process is to develop and review these sections individually, avoiding the need for any one individual to be responsible for knowing or being responsible for all details.   That is the nature of delegation.

Note that none of the signatories is asked to commit to the results being 100% complete and correct.   Life does not work that way, and it's no use pretending that it does.^[5]

While the QED SDLC has the general look and feel of a 'waterfall' lifecycle, in truth it is not limited to flow in only one direction (i.e., down).   The first evidence of this is that the last step in the analysis phase is to revisit the Scope document (which itself was signed off at Step 2).   The original version is updated (see below) to reflect the improved understanding brought about by detailed analysis.   Similarly, as the design phase progresses, some aspects of the analysis (hopefully very few) that prove to have been incomplete or incorrect will result in changes to the FS (under version control and with appropriate agreement with the client).

BRA Step 7 -- The Scope document, revisited

During detailed business requirements analysis, the Scope document (as summarized by the Scope diagram) is used to guide the analysis effort.   While the FS is expected to be on the order of 95+% complete and correct, the original Scope was done much more quickly, targeting only identifying the scope with something like 80%.   It is normal for the names of some things to change as those things are better understood.   While nothing major should have been missed, certain supporting information, processes, or actors may be identified and need adding (or conversely, what seemed significant at the start can turn out, on closer examination, to be not a major issue).

All such changes are potentially a change of scope and should be reviewed and approved by the project owner.   Fortunately, during BRA any such changes are only changes to the scope of the analysis.   There is always the opportunity to limit what goes forward to design and/or prioritize analysis results into phased deliverables.^[6]

Figure 3: Revised STS Scope Diagram

Figure 3 shows the post-analysis version of the original example Scope diagram for the STS project.   A comparison of Figure 3 and the original (Figure 2 in part 1 of this article) reveals the following:

• The business process originally called "Management Reports" has become "Monitor Service Agents."
• Three new primary information concepts have appeared.
• A additional 'system' actor has been added.

More importantly, thanks to the analysis results documented in the FS, we no longer have to rely on a bulleted list of tasks as a description for each of the business processes.   Each of these processes has now been described in detail in the introduction to its sub-section in the FS document.   These descriptions typically run anywhere from one to three pages and can include one or two workflows (Figure 3 in part 1 of this article) and/or simplified Entity Class diagrams (Figure 2 in this article).   These overview sections, in their entirety, are perfect for replacing the original business process description in the Scope document.^[7]

The original document was a fair representation of the original scope.   The post-analysis version is an equally fair representation of the application as it moves forward into the design phase.   This revised version of the Scope document requires no signoff.   It simply provides an introduction and overview of the application to designers, testers, and the eventual business users who will be trained to use the delivered application.

Onward to the Design Phase

The functional specification contains a mixture of text and diagrams.   Among the text are portions that are purely descriptive (e.g., the executive summary, overviews of each section).   These are necessary to give a context for the specific items that are 'required' to be delivered within the application.   Those items that are to be designed and delivered are explicitly 'numbered' within the FS.   These are use cases, business rules, interfaces, and reports.

Use cases typically have screens designed that allow actors to carry out the interactions described.   Business rules are designed as functions that either maintain integrity, derive values, or control processes.   Reports require both explicit layout of the report itself, plus some user interface for requesting the report and specifying run-time parameters (e.g., selection criteria).   Interfaces to other systems (when they involve single transactions) can become part of on-line functions.   Those that involve the transfer of numbers of records are usually designed as batch functions.

The fully-attributed Entity Class model undergoes the necessary transformation to a physical database design.   This usually involves applying physical naming standards for both tables and fields.   Field sizes and types appropriate to the database system are finalized.   Primary keys and indexes are identified.   As design proceeds, additional process-related fields are added and redundant data values added where required for performance reasons (along with whatever functionality is required to maintain their integrity).

As 'business'-related issues come up during the design phase, the FS is revisited.   Because of the considerably higher-level of accuracy it has than did the Scope document, only minor changes should be required.   Again, if these changes represent significant variations in the delivery effort from what was agreed at signoff time, the changes must be authorized and factored into the project plan.

Conclusion

There is no shortage of tools and techniques that support the process of delivering information systems.   Thanks to UML, there is at least a reduced modeling 'vocabulary.'   This pair of articles has presented examples of work products from QED's Business Requirements Analysis phase of its Software Development Life Cycle.   Some of these work products are standard UML artifacts.   Others are not, or variations on a theme.

This BRA process has evolved over time.   While we are happy that our clients are satisfied with both our process and our work products, we are always looking for ways to improve them.   We hope that having provided others with examples of what we produce will help improve the IT industry as a whole.

Notes

[1]  Objects, unlike [relational] entities, are not required to be normalized (i.e., attributes can be multi-valued).   However, it is advisable that the entity classes follow basic fact-based normalization principles in order to avoid insert, update, and delete anomalies.

[2]  Thanks to e-mail there is still a chance that trees can be spared.   Wherever possible, 'soft copies' of reports could be produced and sent.   It is then at the discretion of the receiver whether or not to produce a hard copy of the report.

[3]  UML does offer -- in addition to Entity Classes -- the concept of a Boundary Class.   However, as with the Entity Classes, QED does not expect business users to read and review these directly.   Therefore they are 'described' as a specific work product and listed in their own section in the Functional Specification.

[4]  Even analysts (whose job it is to do analysis) don't want to analyse the same application forever.   They want to end one project and move on to the next.

[5]  Even in the world of accounting, which attempts to be accurate to the last cent, when an accounting audit takes place, the auditors don't attest that the figures in the company's books are 100% correct.   What they sign off on is that "… the accounting practices followed by this organization are in accordance with accepted accounting practices."

[6]  This is a project management issue and outside the scope of this article.

[7]  Why have them in both?   Simple.   Someone reading the FS typically does not want to have to reference a separate document (particularly when reading a hard copy version).   Conversely, someone interested in getting a good overview of an application does not want to have to navigate a 250-page document to pick out the 10 critical pages.

# # #