| Project: | PROJECT-NAME |
|---|---|
| Internal Release Number: | X.Y.Z |
| Attached worksheets: |
SRS > Use case suite
SRS > Feature set
|
| Related Documents: |
LINKS-TO-RELEVANT-STANDARDS
LINKS-TO-OTHER-DOCUMENTS
|
Our main usability requirement is minimizing the difficulty of performing each high-frequency use case. Difficulty depends on the number of steps, the knowledge that a user must have at each step, the decisions that a user must make at each step, and the mechanics of each step (e.g., typing a book title exactly is hard, whereas selecting a title from a list is easy).
The user interface should be as familiar as possible to users who have used other web applications and Windows desktop applications. E.g., we will follow the UI guidelines for naming menus, buttons, and dialog boxes whenever possible.
The type of user most sensitive to first-time usability is the consumer. Business consumer users are more concerned about UI efficiency. Our product must also provide highly usable administrative features that help visualize traffic and sales information to support decision-making by department managers.
Details:
Our main requirements for reliability are that the system should continue normal operations for as long as possible without exhausting server resources (e.g., a memory leak or runaway process) or requiring routine administrator maintenance, and that the system should limit the impact of any errors and continue processing new requests.
It must be possible to operate the system over long periods of time with minimal scheduled down-time. System backups must be done without halting the system. System software upgrades must be possible with less than one hour of downtime.
The software product must support automatic fail-over among identical machines within the local server cluster. Local fail-over must occur without loss of any completed transactions. Local fail-over must be safely testable.
The software product must support operator-initiated catastrophic fail-over from one server cluster to a completely independent cluster of similar machines at a remote location. Catastrophe recovery must not take more than four hours and must not lose more than 30 minutes worth of completed transactions.
Details:
The main security requirements are user authentication and authorization, encryption of communications, and rejection of malicious input.
The system must prevent hackers or malicious users from abusing the system from the outside, and provide a few key limits on access to sensitive information by insiders.
Details:
Our main performance requirement is that the system maintain interactive response times. In no case should users perceive that the server is slow or hung, and they should never see a server timeout message.
Our main scalability requirements are the ability to host the server software on a cluster of machines that can be upgraded over time, and the ability to add new auxiliary software components without substantially slowing the main functions of the server.
Details:
Maintainability is our ability to make changes to the product over time. We need strong maintainability in order to retain our early customers. We will address this by anticipating several types of change, and by carefully documenting our design and implementation.
Upgradeability is our ability to cost-effectively deploy new versions of the product to customers with minimal downtime or disruption. A key feature supporting this goal is automatic download of patches and upgrade of the end-user's machine. Also, we shall use data file formats that include enough meta-data to allow us to reliably transform existing customer data during an upgrade.
Details:
Our main integration requirement is to allow a third-party systems integration firm to perform an integration that covers four areas:
Our main customization requirement is to allow a systems integration firm or customer system administrator to customize the appearance and behavior of the system through extensive configuration files.
Our main internationalization requirement is to allow a third-party system integration firm or reseller to localize the product to a new market without any changes to the core product engine.
Details:
Supportability is our ability to provide cost effective technical support. Our goal is to limit our support costs to only 12% of annual licensing fees. The product's automatic upgrade feature will help us easily deploy defect fixes to end-users. The user guide and product website will include a troubleshooting guide and checklist of information to gather before contacting technical support.
Details:
The business life-cycle of a product includes everything that happens to that product over a period of several years, from initial purchase decision and deployment, through important but infrequent use cases, until product retirement. Key life-cycle requirements are listed below.
Details:
Our minimum hardware requirement is a low-end server machine.
To use FEATURE-NAME, we also require DESCRIPTION-OF-DEVICE connected through DESCRIPTION-OF-INTERFACE.
Details:
| System Processor: | 800MHz PROCESSOR-TYPE |
|---|---|
| System Memory: | 256MB |
| Free Disk Space: | 10MB |
| Operating System: | Windows 2000, Windows XP, Mac OS X, Linux (kernel 2.4) |
| Networking: | Internet access |
We expect the software environment to include specific software on the server-side and client-side.
Details:
Our main API requirement is to implement STANDARD-API-NAME. We will also interoperate over PROTOCOL-NAME.
It is important for us to provide a plug-in API for third-party developers building add-ons to our product.
Details:
Our main data compatibility requirements are to work with past versions of our own product, export to STANDARD-FORMAT, and import from COMPETING-PRODUCT.
Details: