Structured Analysis is a method for identifying and representing those features of an information system that are particularly important to the client. A functional specification produced by Structured Analysis is represented using dataflow diagrams, process specifications, and a data dictionary. The standards listed below are designed to assist with producing a satisfactory specification.

You are required to represent assignments, when applicable, in conformance with these standards. Failure to do so will result in a loss of points.

This standard applies to both individual assignments and team project materials.

A dataflow diagram (DFD) is a network representation of a system’s functional requirements. A hierarchy of DFDs can be created to model the requirements for a system in terms of functional components.

DFD.1) Diagram Format

DFD.1.a) A diagram must contain between one and seven processes.

DFD.1.b) A diagram of a decomposed process must contain the PID and name

of the decomposed process along the top edge of the diagram.

DFD.2) Processes

DFD.2.a) A process must represent an activity or periodic function.

DFD.2.b) A process is drawn as a box with rounded corners.

DFD.2.c) A process must be named with a verb phrase followed by an object clause.

DFD.2.d) A process must be identified with a unique number called a process

identification number (PID). A PID begins with the letter P.

DFD.2.e) The PID of a child process must contain the parent process’s PID. For

example, P2.3.1 is a child of P2.3

DFD.2.f) The PID of a primitive process must end with the character *. This

denotes that a process is primitive and aids with understandability of a

DFD.

DFD.3) Flows

DFD.3.a) A flow must represent the transfer of one or more data items from a source

to a destination. A data item is a piece of information.

DFD.3.b) A flow is drawn as an arc with an arrow indicating the direction of

information flow.

DFD.3.c) A flow must be named with a noun phrase. Multiple names, separated by

comma are permitted.

DFD.3.d) The output flows from a process can not be given the same names as the

input flows.

DFD.4) Stores

DFD.4.a) A store must represent a set of one or more data items.

DFD.4.b) A store is drawn as a rectangle, open on the right side, and contains a

dividing line that partitions the rectangle into two areas.

DFD.4.c) A store must be named with a noun phrase. (Often a plural form of a

noun phrase is used.) The name is written in the right hand side of the

rectangle denoting the store.

DFD.4.d) A store must be identified with a unique number called a store

identification number (SID). A SID begins with the letter D. The SID is

written in the left hand side of the rectangle denoting the store.

DFD.5) Terminators (External Entities)

DFD.5.a) A terminator must represent an entity outside the context of the system.

DFD.5.b) A terminator is drawn as a double square.

DFD.5.c) A terminator must be named with a noun phrase.

DFD.5.d) A terminator must be assigned a unique letter by which it can be

identified. The identification letter must be written in the upper left hand

corner of the square.

DFD.6) Process Decomposition (Expansion or explosion)

DFD.6.a) A process must either be decomposed into two or more sub-processes or

described by a process specification.

DFD.6.b) A process expansion is drawn as a large box with rounded corners

containing a DFD.

DFD.6.c) Stores and terminators that are connected to the parent process by flows

must be drawn outside the expansion box.

DFD.6.d) All flows that enter or leave the parent process must cross the boundary of

the expansion box.

A process specification (pspec) must be written for every primitive process in a dataflow diagram. A primitive process is defined as a process that is not decomposed into sub-processes. A pspec must describe how its output flows are produced from input data flows.

PS.1) Pspec Entries

PS.1.a) Any process shown in the DFD hierarchy that is not decomposed must be

defined by a pspec.

PS.1.b) All pspecs are to be listed by PSPEC ID in ascending order.

PS.2.) Pspec Information

PS.2.a) A pspec must contain a PSPEC ID field that contains a process specification

identification number that is the same as the PID of the process appearing in

the DFD hierarchy.

PS.2.b) A pspec must contain a PROCESS NAME field that contains the name of

the process described. The name must be the same as the name used in the

DFD hierarchy.

PS.2.c) A pspec must contain a INPUT FLOWS field that contains a comma

separated list of input data flow names. These are the names of the data

items that are used by the process.

PS.2.d) A pspec must contain an OUTPUT FLOWS field that contains a comma

separated list of output data flow names. These are the names of the data

items produced by the process.

PS.2.e) A pspec must contain a SPECIFICATION field that describes how process

inputs are transformed into process outputs. A specification can be written

using structured English, decision trees, decision tables, or other recognized

means of expression.

PS.2.f) A pspec may contain an optional COMMENT field that contains an

explanatory comment about the process. It is useful to briefly explain the

intent or purpose of a process.

PS.3) Pspec Format

A pspec must present fields in the following order:

PSPEC ID:

PROCESS NAME:

INPUT FLOWS:

OUTPUT FLOWS:

SPECIFICATION:

COMMENTS:

The data dictionary (DD) is an ordered list of data item and store names, each with a definition in terms of its components and structure. Every data item and store must be defined in the dictionary down to its primitive elements. An entry in a DD is called an entity. An entity is either a primitive entity or is a group composed of other group and/or primitive entities. A primitive entity is a single indivisible data item.

DD.1) Entities

DD.1.a) A name used to label a flow or store must be defined in the data dictionary.

DD.1.b) All entities are to be listed in alphabetical order.

DD.2) General Entity Information

DD.2.a) An entity description must contain a TYPE field that identifies the entity as

either a group or primitive entity.

DD.2.b) An entity description must contain a NAME field that gives the name of

the entity. The name given must be the same as the name used in a DFD.

DD.2.c) An entity description must contain a USED IN field that gives a list of

DFDs in which the entity name appears.

DD.2.d) An entity description must contain a MEMBER OF field that gives a list

of other entities of which this entity is a member.

DD.2.e) An entity description can contain a COMMENTS field that gives

additional information about the entity. It is useful to give a brief

explanation about what data the entity represents.

DD.3) Group Entity Information

DD.3.a) An entity of type group must contain a DEFINITION field that defines the

structure of the group.

DD.3.b) The DEFINITION field must be of the following form:

Name of Entity = expression

where expression is based on the notation given below. (Note: X, Y

denote either other group or primitive entities in the dictionary, or they

can be strings or numeric constants.)

Notation Explanation____________________________________

X + Y X and Y occur together

(X) X is optional (may be present or absent)

A{X}Z X will occur at least A times and as many as Z times

(iteration). If A is omitted, X occurs at least once. If Z is

omitted, there is no upper limit on re-occurrences of X.

[Xê Y] X or Y occurs. (selection)

@ identifier (key field) for a store

DD.4) Primitive Entity Information

DD.4.a) An entity description of type primitive may contain a UNITS field that

states the physical units of measure, such as pounds, yards, joules, etc.

relevant to the entity. If there is no relevant unit, this field can be omitted.

DD.4.b) An entity description of type primitive may contain a RANGE field that

states the minimum and maximum limits to the range of valid values the

entity can process. This field is only relevant if the entity has a continuous

range of values. The RANGE can be stated as in a comment of the form

*comment*.

DD.4.c) An entity description of type primitive may contain a field VALUE

NAMES if the entity has a finite number of discrete values. This field

lists each possible valid value.

DD.4.d) An entity description of type primitive must contain a NUMBER OF

VALUES field if the entity also contains a VALUE NAMES field. The

NUMBER OF VALUES field states the number of discrete values the

entity possesses.

DD.4.e) A primitive entity must have a value in either its RANGE or VALUE

NAMES field, but not both.

DD.5) Data Dictionary Format

DD.5.a) Fields for an entity of type group must be presented in the following

order:

NAME:

TYPE: group

DEFINITION:

USED IN:

MEMBER OF:

COMMENTS:

DD.5.b) Fields for an entity of type primitive must be presented in the following

order:

NAME:

TYPE: primitive

UNITS:

RANGE:

VALUES:

NUMBER OF VALUES:

USED IN:

MEMBER OF:

COMMENTS:

The Software Requirements Specification (SRS) is produced as part of the requirements analysis phase. An SRS presents a complete description of the external behavior of the software system. A well-written SRS serves three purposes (1) communication among

customers, users, analysts, and designers, (2) supports system-testing activities, and (3)

controls the evolution of the system. When writing the SRS keep this question in mind:

could another team of people design and implement the system that you have envisioned?

The SRS must be a complete description of the external behavior of the system.

The SRS¹ will consist of the following sections:

Title Page

Table of Contents

1) Introduction

1.1) Purpose of SRS

1.2) Scope of Product

1.3) Definitions, Acronyms, and Abbreviations

1.4) References

1.5) SRS Document Overview

2) General Description

2.1) Product Perspective (System Model)

2.2) System Functionality

2.3) User Characteristics

2.4) General Constraints

2.5) Assumptions and Dependencies

3) Specific Requirements

3.1) Functional Requirements

3.2) External Interface Requirements

3.2.1) User Interfaces

3.2.2) Hardware Interfaces

3.2.3) Software Interfaces

3.3) Non-Functional Requirements

3.4) Database Requirements

4) Possible Product Evolution

Appendixes (Optional)

Index (Optional)

The front of the SRS will consist of a title page. The title page will (1) identify the document as an SRS, and give (2) the name of the project/system, (3) the team number, (4) the names of team members, (5) the document version number, and (6) the date of publication.

This will be a standard table of contents. It will list the chapters and sections contained in the document and the page number on which each item begins.

The introduction to the SRS is intended to provide an overview of both the system to be built and the SRS document itself. The introduction contains the following sections:

1.1) Purpose of SRS

This subsection focuses on two issues. First, explain the purpose of the SRS, i.e. Why was this SRS written? What can be learned by reading the SRS?, etc. Second, describe the intended audience for the SRS, i.e Who is expected to read this document?. Possible audience includes the client, potential users, other analysis, designers, future maintainers of the system, product testers, etc.

1.2) Scope of Product

The purpose of this subsection is to introduce the system. This is accomplished by (1) identifying the software product(s) (i.e the system) to be produced. Give the actual name of the product. (The product name may or may not be the same as the executable program name.) (2) Explain in general terms what the features and capabilities of the system will be. (It may be useful to present the features in a list.) If appropriate, explain what the system will not do. (3) Identify and explain the benefits to be gained by using the system, and the objectives and goals of the project.

1.3) Definitions, Acronyms, and Abbreviations

This subsection will contain a list of terms, acronyms, and abbreviations required to understand the material presented in the SRS. A definition for each term, acronym, and abbreviation must be given.

1.4) References

This subsection will identify any other documents or material of which the reader of the SRS should be aware. This may include other documents produced as part of the current project, documents referenced in any section of the SRS, documents for entities with which the system will interact, or documents that help define or describe the application domain (background material).

1.5) SRS Document Overview

This subsection will provide a description of the contents of this document. Each chapter should be described in a separate paragraph. What information is contained in a chapter? What will the reader learn by reading a particular chapter?

This section of the SRS will describe the general factors that affect the system and its requirements. The purpose of this chapter is not to present detailed requirements, but rather to present material that will make the specific requirements easier to understand.

2.1) Product Perspective (System Model)

This subsection will describe the relationships between the proposed system and its environment. Any system has an environment, separated from the system by a boundary - users, data files, other programs, devices, operating system, etc. Identify external entities and describe them in general terms. The description should represent real-world entities that will interact with the system. This description establishes a system context where the relationships between the system being specified and other humans and computers systems are documented. The description should include system inputs and outputs, but not data local to the system.

The system model is primarily a textual description of the environment in which the purposed system will operate. (However, a good diagram that shows the major external entities and the system can be quite helpful.) Describe the pieces of that environment and how they interact with each other and with the system. Be sure to include the system as part of the system model. Describe the model at a conceptual level. Avoid specific details. Don’t tell how to invoke and operate the system.

This subsection will provide a summary of the functionality that the software system is to perform. The discussion of the functionality and capabilities of the system should be organized in a way that makes the list of features understandable to anyone reading this document for the first time. This subsection does not give specific requirements, but it will provide information that makes it easier to understand the specific requirements when they are given later. Keep the discussion abstract, explain the major functional areas of the system.

2.3) User Characteristics

This subsection will describe characteristics and knowledge of eventual users of the system. Who will be the users of this system? How often are they likely to use this system? What is the background of expected users? Many different people are likely to use a system during its lifetime. Certain characteristics of these people, such as educational level, experience, and technical expertise can impose constraints on a system’s functionality.

2.4) General Constraints

This subsection will provide a general description of any other items that may constrain the system’s requirements or design. Possibilities include: (1) Hardware limitations, (2) Interfaces with other applications, (3) Parallel operations, (4) Protocols, (5) Criticality of the application, and (6) Safety and security considerations. These are factors to be considered when examining the specific requirements for the system.

2.5) Assumptions and Dependencies

This subsection will provide a list of assumptions on which the current requirements are based. These assumptions are not constraints on the system, but rather represent things that if changed, will cause changes to the system requirements. For example, an assumption may be that a system will run under a particular operating system. If the OS is changed in the future, the requirements for the system may change.

This section of the SRS will contain a complete description of the external behavior of the software system. It will contain sufficient information and detail necessary to create a design for the system. This section is typically the largest and the most important in the document.

3.1) Functional Requirements

This subsection will specify the requirements of the system, that is, the services/tasks to be provided and characteristics of the system’s input and output. The exact organization and information content of this section is dependent on the requirements methodology used.

Structured Analysis

If Structured Analysis is used to model and express the functional requirements then section 3.1 of the SRS will contain the following subsections.

3.1.1) Dataflow Diagram Hierarchy

The dataflow diagram section will present a hierarchy of dataflow diagrams to model the flow of information and processing that occurs within the system. The dataflow diagrams must conform with the SA - Dataflow Diagram Standard.

3.1.2 Process Specifications

The process specifications (pspec) section will contain a pspec for each primitive process mentioned in the dataflow diagram hierarchy. All pspecs must conform with the SA - Process Specification Standard.

3.1.3 Data Dictionary

The data dictionary section will contain an entry for each dataflow and store mentioned in the dataflow diagram hierarchy. The data dictionary entries must conform with the SA - Data Dictionary Standard.

3.2) External Interface Requirements

This subsection focuses on specific requirements related to interfaces that the system will use to interact with entities outside of the system.

3.2.1 User Interfaces

Interfaces between the system and humans who use the system are defined in detail in this section. This includes: the exact text of menus, window layouts, exact text of error messages, etc. Requirements related to the format or content of information that is passed into the system is also defined here.

3.2.2) Hardware Interfaces

Interfaces between the system and any hardware device with which the system will interact are defined in detail in this section. This will specify the logical characteristics of each interface, which includes appropriate protocols, or modes of operation.

3.2.3) Software Interfaces

Interfaces between the system and any other applications with which the system will interact are defined in detail in this section. This includes the operating system, any database management system, any programs accessed on the host computer or elsewhere via a network. Software interfaces can either be via system calls, special libraries of routines, or shared files.

For each software product with which the system will interact the following information should be given: (1) name, (2) mnemonic, and (3) version number. Discuss the purpose of the interfacing software as related to the system. Also define the interface in terms of message content and format.

3.3) Non-Functional Requirements

Requirements that do not relate directly to functionality are presented here. Such requirements can impose constraints on the design or implementation. These can also be restrictions under which the software must operate or goals for which the solution should strive. Possible non-functional requirements include: (1) conformance to specific standards, (2) performance constraints, (3) hardware limitations, (4) maintainability, (5) reliability, (6) testability, etc.

Each requirement will be expressed in a separate paragraph. Each requirement must be numbered.

Be careful not to put functional requirements in this section. If a requirement describes something the system must do, it is a functional requirement. Restrictions on inputs to the system are also functional requirements.

3.4) Database Requirements

The database requirements section will present the logical organization of the data used by the system and interrelationships among data items. Entity-Relationship (ER) diagrams or other data modeling notations are to be used.

This section is only necessary if the system’s data is to be stored in a DBMS, or if there are complex relationships between the system’s data that can be clarified or clearly expressed by a data model.

This section of the SRS will describe what features or capabilities are expected to be changed or added in the future. These are expected extensions and changes owing to hardware evolution, changing user needs, etc. Each possible change should be briefly described. This information will be used to create a system design that will simplify the task of incorporating these expected changes into the system in the future.

Each possible extension must be numbered and contained in a separate paragraph.

APPENDIXES (optional)

If the writers of the SRS feel it is necessary, additional information relevant to the system, its requirements, or its interfaces can be presented in one of more appendixes.

INDEX (optional)

The index will contain a set of important terms and phases and list the pages in the document where each occurred.

The team project is an important component of this course. The purpose of a team project is to provide each student with an opportunity to gain experience with working as part of a group to achieve a specified team objective. The success or failure of a team to satisfactorily achieve that objective rests with the entire team rather than just one or two members of the team.

Each team is responsible for satisfactorily completing team assignments and submitting the appropriate material for grading. Material must be submitted by the established deadline.

Each team should carefully review their own material for quality and correctness prior to submission for grading. Be sure that submitted material conforms to the relevant course standards and specifications.

Team materials submitted for grading must be computer generated. The only exception is for diagrams, which may be hand drawn. In the case of hand drawn diagrams, copies may be turned into the instructor and the team can keep the originals.

Each team member is to behave in a professional manner when interacting with other team members.

Each team member is responsible for performing tasks assigned to that member. Tasks must be performed to the best ability of the team member. Assigned tasks must be completed by the deadline determined by the team.

Each team member is expected to contribute their fair share to the overall team effort.

Each team member must attend scheduled team meetings.

Each team member must contribute to any costs incurred to produce team materials.

Team material will not be accepted after the established deadline.

A student’s team grade has two components. The first component is based on the grade earned by team project material. All members of a team share the grade earned by the project material the team submits for grading. If a team earns a B, each team member receives a B for this component of the team grade. The second component is based on a student’s contribution to the team. Each student’s contribution is determined by his/her team members and reported to the instructor via a peer review.

Disagreements: Occasionally disagreements might occur within a team that can not be settled. In such a situation, the disagreement can be brought to the instructor. Team members representing both sides of the dispute must come to the instructor together for the disagreement to be heard.

Non-performing team members: If the members of a team feel that they have a team member who is disruptive or not performing the responsibilities of a team member, the team may bring a complaint against that member to the instructor. The team member will be give a chance to present his/her side also. If necessary a member can be removed from a team. In this case, the removed team member may either be assigned to another team or assigned a term paper. A student assigned a term paper can not receive a grade for that paper higher than the lowest team grade.