Page 112 -

System information and/or diagrams
This section should contain a summary of any notes that describe functionality that
must be implemented, existing or planned organizational workflow, specific user inter-
actions, information about the environment in which the software will be used, calcula-
tions that must be performed, and any other functionality that must be implemented.
This will probably be the longest section in the discussion summary.
Assumptions and dependencies
During elicitation meetings, many assumptions and dependencies will be brought up.
They should be summarized in this section. (See Chapter 3 for an explanation of how
assumptions affect software development.) Many of these assumptions may already be
in the vision and scope document, or in the results of a Wideband Delphi estimation
session; it is often sufficient to reference that document, rather than reproduce them in
the discussion summary.
Design and implementation constraints
Many times there are constraints that must be placed on the software: known input or
output data formats; tools, code libraries, visual controls, programming languages, or
APIs that must be used; visual or GUI design standards that must be adhered to; and
performance or quality requirements and other known nonfunctional requirements.
These should be listed in this section in detail.
The “Risks” section summarizes any risks identified during the elicitation process that are
not already included in the vision and scope document or the project plan.

The “Known future enhancements” section lists expected future enhancements. Often,
during elicitation, there are feature requests from users or stakeholders that will not be
included in the software. Those requests should be described, in order to make sure every-
one knows that they are not going to be implemented.

The “References” section should include any internal or external documents needed to
understand the software project—for example, any existing system documentation, screen
shots, or original system requirements.

The “Open, unresolved, or TBD [to be determined] issues” section is the last part of the dis-

cussion summary. There are usually issues that remain unaddressed at the time the discus-
sion summary is distributed for review. Open issues may be under active discussion with
users or stakeholders. Some problems may await resolution. And the requirements analyst
may not yet have raised some issues. All of these issues should be summarized here.

Once the discussion summary is complete, it should be distributed for a deskcheck (see
Chapter 5). Minimally, it should be reviewed by the lead users and stakeholders (who are
usually listed in the vision and scope document). But ideally, everyone who contributed
to the discussion summary should have a chance to review it and give feedback. The wider
the audience, the more likely it is that defects will be caught early. When the reviewers
return their comments, the discussion summary does not need to be updated. However,
those comments should be archived along with the discussion summary, and should be
taken into account in later requirements activities.

104 CHAPTER SIX