Due to the huge number of questions: "Where can we find a sample of writing requirements for the system?" - And standard reply: "In runet it is unlikely" - spread the variant description of system requirements.
In general, this documentation is based on a rup template SRS. It's not bad and not good. For some teams it would be easier to see no use cases but user stories, and does not to see the functional requirements in the form of "system must".
Documentation is "working", that means that it was not smarm before the computation. Some of this information has not been filled. It was done intentionally to show the work with the document. A set of parts is also not complete.
Disclaimer. Copyright for this material are fully belong to me. When publishing is not affected the interests of any one firm.
1 Introduction
1.1 Purpose
The purpose of the document "Specification of software requirements" is the definition of product requirements and coordination with the customer.
The document is the basis for a contract with the customer.
1.2 Scope of the document
The document includes a common vision of the product, formal requirements, a description of the system objects and prototypes of user interface. Thus, this document is sufficient for product development.
1.3 Definitions
Precedents (user cases) are options for using of software.
1.4 Abbreviations
CRUD (Create, Read, Update, Delete) is a group of standard precedents (user cases) facility for the creation, viewing, editing and deleting.
MP - The main protagonist
2 General description
2.1 The purpose and prospects of the product
The product is designed as a complete solution for a particular firm customer (hereinafter simply the customer) to manage a geographically distributed group of medical representatives.
he main purpose of the product is the ability to control actions of medical representatives to obtain data for further analysis and planning activities outside of the system being developed.
For the success of the product it must be ensured that:
- Ease of entry of the primary information
- Sufficiency of reports
2.2 Roles
1. Administrator configures customize and control over the system.
2. Medical representative introduces background information, tracks information and receives detailed reports on their partners.
3. Analyst receives summary reports for the whole company.
With further refinement of the system can be introduced the role a regional manager.
4. Manager can enter basic information, receive reports on all partners, and receive detailed reports on medical representative.
For the current version the implementation of this role is a low priority.
2.3 Review of the use-case model
2.3.1 Introduction
System functions are combined into the following groups:
- Working with partners
- Managing partners and medical representatives
- Reports
- Administration
- Working with directories
QATestLab independent testing process provides an unbiased view of the current state and stability of our client’s mission critical applications.