Subject: Software Engineering

Topic: Matrics for Process & Projects

Difficulty: High

A System Requirements Specification (SRS) is a document or set of documentation that describes the features and behavior of a system or software application. It includes a variety of elements that attempts to define the intended functionality required by the customer to satisfy their different users. In addition to specifying how the system should behave, the specification also defines at a high-level the main business processes that will be supported, what simplifying assumptions have been made and what key performance parameters will need to be met by the system.

Business Model - This section describes the underlying business model of the customer that the system will need to support. This includes such items as the organizational context, current-state and future-state diagrams, business context, key business functions and process flow diagrams.

Functional and System Requirements - This section usually consists of a hierarchical organization of requirements, with the business.

Technical Requirements - This section is used to list any of the "non-functional" requirements that essentially embody the technical environment that the product needs to operate in, and include the technical constraints that it needs to operate under.

System Qualities - This section is used to describe the "non-functional" requirements that define the "quality" of the system. These items are often known as the "utilities" because most of them end in "utility". They included such items as: reliability, availability, serviceability, security, maintainability. Unlike the functional requirements (which are usually narrative in form), the system qualities usually consist of tables of specific metrics that the system must meet to be accepted.

Constraints and Assumptions - This section will outline any design constraints that have been imposed on the design of the system by the customer, thereby removing certain options from being considered by the developers. Also this section will contain any assumptions that have been made by the requirements engineering team when gathering and analyzing the requirements.

Acceptance Criteria - This section will describe the criteria by which the customer will "sign-off" on the final system. Depending on the methodology, this may happen at the end of the testing and quality assurance phase, or in an agile methodology, at the end of each iteration. The criteria will usually refer to the need to complete all user acceptance tests and the rectification of all defects/bugs that meet a pre- determined priority or severity threshold.