CPSC 333: ERDs, DDs, and ``Requirements Analysis Principles''

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] ERDs, DDs, and Requirements Analysis Principles


This material was covered during lectures on January 27, 1997.


Requirements Analysis Principles

Previously, several requirements analysis principles and desirable properties of (informal) models of requirements have been stated.

Entity-relationship diagrams and data dictionaries do satisfy at least some of these principles, and meet some of these goals.

It isn't immediately clear that an entity-relationship diagram provides a hierarchical or partitioned view of requirements. However, that it can be argued that a combination of an ERD, list of attributes of every entity (etc.) in the diagram, and complete set of data dictionary definitions does provide this - especially if a reasonably powerful ``CASE Tool'' is used to create, and inspect this information.

A simulation is some of these navigation features is available.

It is also possible to begin construction of this model early on, when few details of system requirements are known. The process of constructing the model helps you to discover which additional information is required. It is then easy to ``extend'' the model by incorporating this additional information as it becomes available.

Unfortunately...

We've had to resort to ``comments'' - or, the use of an informal ``description'' as part of a data dictionary definition - based on a ``natural language'' (English) rather than a formal one (like first order logic) in order to include ``detailed'' or ``unusual'' requirements. Any information specified using a ``natural language'' is inherently ambiguous or imprecise.

It's already been noted, repeatedly, that different authors of ``software engineering'' texts all define entity-relationship diagrams, data dictionaries, etc., in slightly different ways. The more detailed or unusual the requirement is (that you wish to specify), the more likely it becomes that you must use a ``nonstandard'' part of the model in order to document it!

Some developers using these tools have tried to cope with this by developing and documenting their own ``in house'' standards, including conventions for documenting ``unusual'' requirements. However, as more and more of these are added, it becomes more and more difficult to remember what these conventions are, and to follow them correctly.

For this reason (and others) it can be desirable to use different tools that can be used to specify a wider range of types of requirements in a precise way. This is possible (or, at least, plausible) if a tool is based on a formal language, rather than a natural language like English or a set of pictures (or both). These tools will be discussed later in the term.

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] ERDs, DDs, and Requirements Analysis Principles


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca