Reference no: EM132083407

Support System (DSS) for clinicians

A newly developed hospital requires an Electronic Decision Support System (DSS) for clinicians. This DSS is required to have all the necessary features to help the practice.

Develop a Software Requirements Specification (SRS) document that identifies all the necessary requirements for the system.

This document must strictly follow the IEEE template uploaded on canvas. However, there may be sections in the template that may not apply to the project, these sections can be eliminated.

Use the template below to answer the above statement.

Software Requirements Specification

1 Introduction

<TO DO: Please provide a brief introduction to your project and a brief overview of what the reader will find in this section.>

1.1 Document Purpose

<Identify the product whose software requirements are specified in this document, including the revision or release number. This should including relevant benefits, objectives, and goals.

TO DO: Write 1-2 paragraphs describing the purpose of this document as explained above.>

1.2 Product Scope

<Provide a short description of the software being specified and its purpose; describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.

TO DO: 1-2 paragraphs describing the scope of the product. Make sure to describe how it is associated with other product or subsystems.>

1.3 Definitions, Acronyms and Abbreviations

<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations.

TO DO: Please provide a list of all abbreviations and acronyms used in this document sorted in alphabetical order.>

1.4 References and Acknowledgments

<List any other documents or Web addresses to which this SRS refers. These may include user interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision and scope document.>

2 Overall Description

2.1 Product Functionality

<Summarize the major functions the product must perform or must let the user perform. Details will be provided in Section 3, so only a high level summary is needed here (user requirement). Organize the functions to make them understandable to any reader of the SRS.

TO DO:

1. Provide a bulleted list of all the major functions of the system.>

2.2 End Users and Characteristics

<Identify the various users that you anticipate will use this product. Users may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience.

TO DO:

1. Describe the characteristics of each user. Certain requirements may affect (relate) only to certain users.

3. Distinguish the most important users for this product from those who are less important to satisfy.>

2.3 System Stakeholders

You should build a list of your system stakeholders. You should define the role of each stakeholder in the big system.

2.4 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist. In this part, make sure to include a simple diagram that shows the major components of the overall system, subsystem interconnections, and external interface

TO DO: in at least one paragraph, describe the environment your system will have to operate in. Make sure to include the minimum platform requirements for your system. >

3 Specific Requirements

3.1 User Interface

<Describe the logical characteristics of each interface between the software product and the users. This should include sample screen images, any GUI standards.

TO DO: The least you can do for this section is to describe in words the different User Interfaces and the different screens that will be available to the user. Those who will be able to provide optional Graphical User Interface screenshots will be rewarded by extra marks.>

3.2 Functional Requirements

<Functional requirements capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. (System Requirements)

TO DO: Break the functional requirements to several functional areas and divide this section into subsections accordingly. Provide a detailed list of all product operations related to these functional areas.

3.3 Use Case Diagram

<A use case defines a goal-oriented set of interactions between external actors and the system under consideration.

TO DO: Provide a use case diagram which will encapsulate the entire system and all possible actors. Do not include detailed use case descriptions, but make sure to include a short description of what every use-case is, who are the actors in your diagram>

4 Non-functional Requirements

4.1 Software Quality Attributes

<Specify any quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: performance, safety, security, adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning. >

5 Other Requirements

<This section is Optional. Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Appendix A - Group Log

<Please include here all the minutes from your group meetings, your group activities, and any other relevant information that will assist the instructor to determine the effort put forth to produce this document>