Deliverables for Requirements Analysis Phase

Goals

The goal of a requirements document is to set out what the system should do
and to define constraints on its operation and implementation. Requirements
can be loosely organized into three types: functional, non-functional, and
domain requirements. Make sure you consider all three kinds of requirements
during your analysis.

Functional requirements set out services the system should (not) provide.
Non-functional requirements constrain the system being developed or the development process
Domain requirements derive from characteristics of the application domain. They may be functional or non-functional.

Requirements for a requirements document

An effective requirements document should:

Specify external system behavior
Specify implementation constraints
Be easy to change
Serve as reference tool for maintenance
Record forethought about the life cycle of the system i.e. predict changes
Characterize responses to unexpected events

Suggested Format

A suggested format for you document follows. Note that I said, "suggested", not "required."
As engineers, I expect you to determine how best to meet the requirements discussed above.

Introduction

Purpose - (purpose of document, audience, system benefits, objectives and goals).
Scope - (software products produced, overview of what software will do/not do)
Definitions, Acronyms and Abbreviations - (as used within the document, data dictionary)
References - (references to other documents used)
Overview - (what is in the remainder of the document, how the software requirement specification is organized

General Description

Product Perspective - (identify the interface between the proposed software and existing system, including a diagram of major system components
Product Function - (summary of major functions)
User Characteristics - (express levels of expertise/training required to use system)
General Considerations - (limitations, including hardware, software language)
Assumptions and Dependencies - (list the factors that will effect the requirements i.e. operating system type).

Specific requirements

User requirements definition - defined as UML use cases and activity diagrams
System models - the domain model represented as UML class diagrams, state diagrams and interaction diagrams

Appendices - any other important material

Other notes

Remember that we want to keep a conceptual perspective at this time. Focus on what the
system does, rather than on how it will be implemented. Stay away from implementation
specific issues such as programming languages, networking protocols, etc.

Each group will turn in one requirements document. In addition to that each student
will prepare a 1-page evaluation of all team member's including him- or herself.

Web Accessibility