08-16-2017, 09:05 PM
[attachment=6080]
Software Requirements Specification for Mercury Tours
Version 1.0 approved
Prepared by Chaite Kaaji
(Business Analyst)
Imagine Software, Inc
<The company who is making software for Mercury Tours)
Introduction 1.1
Purpose
The purpose of this requirement document is to clearly specify the needs of the client for a travel and tour industry so that it will be easier to communicate among the developers, business analysts, test engineers and project managers. This document will be the major document that will be referred by all the team members involved in this project. There is a need to align several groups and many people about what you re trying to accomplish, for whom, and in what envisioned manner. The requirements process provides the discussions and artifacts to enable the communication to the folks who need to provide pieces of the solution. It also introduces a common set of terminology and templates to facilitate the conversations and to make sure a necessary level of due diligence is happening before committing to a potentially major undertaking.
1.2 Document Conventions
The originator of the Requirements is usually the business owner or customer while the originator of the Specs is the technical team. There are different levels of Specs with varying degrees of abstraction and implementation details. The Specs can also contain Project information, such as which resources are required, major milestones and development schedule and cost. In other environments, the Product Spec is the sole document driven from the business owner to a deep level of detail and the development team signs off on it. This requirement document is developed by the business analyst with the help of product manager but with possible help from others such as a product designer, or technical staff. Its purpose is to describe the product-level view of what a user could accomplish with it. It expands the features into more detail to define the entire solution. It identifies the users of the product, the activities they would want to perform, external systems connections, how well the product needs to perform, and what constraints are placed on it. It could also contain UI mockups, personas, use cases, process flows, data flows and any level of technical detail to describe the desired results. The key perspective of this document is that is describes the product from the user s point of view. Depending upon the need, other documents may be developed by a member(s) of the technical team - program manager, technical lead, business analyst, architect or others. Its purpose is to describe the specific functionality the product will provide in response to user and external system interactions. It tells the developers (and testers) what capabilities they need to build and deliver from the system s perspective, and is in effect a translation of the user description into a technical description. It can contain further iteration on use cases, a list of Functional Requirements (responses to user/system actions) and Non-Functional Requirements (qualities and constraints) of the system. As a checkpoint, it also provides feedback on how the requested functionality was understood and defines a specific solution to be able to estimate the effort required to build it.