forked from Silvermoonnbeam/physio_mist
-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathsrs.tex
178 lines (131 loc) · 9.66 KB
/
srs.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
\documentclass{article}
\usepackage{url}
\usepackage[spacing,kerning]{microtype}
\usepackage[letterpaper]{geometry}
\usepackage{tocvsec2}
\settocdepth{subsection}
\usepackage{color}
\newcommand{\todo}[1]{\colorbox{red}{\begin{minipage}{\textwidth}{#1}\end{minipage}}}
\title{Software Requirements Specification\\
\bigskip
{\large for}\\
\bigskip
PhysioMIST}
\author{Mark Caral, Sara Cummins, BarbaraJoy Jones, Joshua Lee}
\date{September 23, 2009\\{\sc Eecs} 393}
\begin{document}
\begin{titlepage}
\maketitle\thispagestyle{empty}
\end{titlepage}
\tableofcontents
\newpage
\section{Introduction}
This document describes software functional and nonfunctional requirements for the PhysioMIST model integration interface. This document will be used by the project team to implement and verify the system.
\subsection{Project Scope and Product Features}
The PhysioMIST model integration interface will allow users to integrate physiological models and produce simulation results. The \emph{Vision and Scope Document for PhysioMIST} provides a detailed description of the project's features and release priorities.
\subsection{References}
\begin{enumerate}
\item \emph{Vision and Scope Document for PhysioMIST}
\item \emph{PhysioMIST.} \url{http://robotics.case.edu/modeling_simulation_biological_systems.html}
\end{enumerate}
\section{Overall Description}
\subsection{Product Perspective}
The PhysioMIST software is a new interface that eliminates the need to manually link different mathematical models when studying human physiology. In its first release, the system will link models on a one-to-one basis and provide integration results through a streamlined user interface. Subsequent releases will include the ability to link models on a many-to-one or one-to-many basis, and also provide a graphical representation of integration results.
\subsection{User Classes and Characteristics}
\begin{description}
\item[Researcher]
The Researcher is the intended user of the PhysioMIST system. She will be working in a field concerning human physiology, and have multiple mathematical models in need of integration. She will choose the models that she wishes to integrate, import them into PhysioMIST, and receive useful results as output.
\end{description}
\subsection{Operating Environment}
The PhysioMIST software is supported only on Microsoft Windows systems. \\
The computer on which PhysioMIST is to be run must have .NET 2.0 runtime files installed. \\
\subsection{Design and Implementation Constraints}
The PhysioMIST software is to be designed in Microsoft Visual Studio 2005 utilizing the .NET 2.0 libraries.
\subsection{User Documentation}
The system shall have a user manual or tutorial to help the new researcher become acquainted with the software.
As the project will be released under an open source license, there will also be a developer's manual, generated with Doxygen.
\subsection{Assumptions and Dependencies}
This project makes the assumption that the existing PhysioMIST codebase it depends on is easily extendable and capable of performing the integration and simulation processes.
\section{System Features}
\subsection{Import Existing Models}
\subsubsection{Description and Priority}
The system will be able to import models that have been previously created in the JSim MML standard.\\
Priority = High.
\subsubsection{Stimulus/Response Sequences}
Stimulus: User locates a JSim MML file he or she wants to import.\\
Response: System converts the file to its preferred format for further use.
\subsubsection{Functional Requirements}
Import.check: Determine if the file is valid in the JSim MML format.\\
Import.parse: Read the contents of the file and parse according to the JSim MML standard.
\subsection{Save Anatomical Information}
\subsubsection{Description and Priority}
The system will save anatomical information associated with model components.\\
Priority = High.
\subsubsection{Stimulus/Response Sequences}
Stimulus: User requests to save anatomical information.\\
Response: Information is saved on user's hard drive.
\subsubsection{Functional Requirements}
Save.Request: Once the user has clicked the save button in the GUI, the system will save the anatomical information for the currently displayed model in a pre-determined location on the user's hard drive.
\subsection{Integrate Model Components on a One-to-One Basis}
\subsubsection{Description and Priority}
The system will provide a graphical interface for users to choose components from two models to integrate on a one-to-one basis.\\
Priority = High.
\subsubsection{Stimulus/Response Sequences}
Stimulus: User inputs two models to the system.\\
Response: System integrates the components of these models and displays the result.
\subsubsection{Functional Requirements}
OnetoOne.Integrate: The system will use the one-to-one algorithm to integrate the two models.
\subsection{Query for Related Model Components}
\subsubsection{Description and Priority}
The system will provide a graphical interface for users to search for related model components while integrating models, based on associated anatomical information.\\
Priority = High.
\subsubsection{Stimulus/Response Sequences}
Stimulus: User selects a model component with associated anatomical information and the type of query to perform.\\
Response: The system performs the query and displays the related model components.
\subsubsection{Functional Requirements}
Query.query: System selects related model components using the anatomical ontology.
Query.results: System displays the selected results.
\subsection{Integrate Model Components on a One-to-Many Basis}
\subsubsection{Description and Priority}
The system will provide a graphical interface for users to choose components from two models to integrate on a one-to-many basis.\\
Priority = Low.
\subsubsection{Stimulus/Response Sequences}
Stimulus: User inputs two models to the system and specifies the manner in which components should be integrated.\\
Response: System integrates the components of these models as specified and displays the result.
\subsubsection{Functional Requirements}
Onetomany.Integrate: The system will use the one-to-many algorithm to integrate the models.
\subsection{Integrate Model Components on a Many-to-One Basis}
\subsubsection{Description and Priority}
The system will provide a graphical interface for users to choose components from two models to integrate on a many-to-one basis.\\
Priority = Low.
\subsubsection{Stimulus/Response Sequences}
Stimulus: User inputs two models to the system and specifies the manner in which components should be integrated.\\
Response: System integrates the components of these models as specified and displays the result.
\subsubsection{Functional Requirements}
ManytoOne.Integrate: The system will use the many-to-one algorithm to integrate the models.
\subsection{Display Simulation Results}
\subsubsection{Description and Priority}
The system will provide a robust representation of the information contained in simulation results.\\
Priority = Low.
\subsubsection{Stimulus/Response Sequences}
Stimulus: User specifies the simulation parameters for a model.\\
Response: Display the results of the simulation graphically and textually.
\subsubsection{Functional Requirements}
Display.graph: The system will graphically show the results of a simulation.\\
Display.text: The system will display the simulation results as text.
\section{External Interface Requirements}
\subsection{User Interface}
The entire purpose of this project is the user interface. In general, it should behave in a manner expected of users of the operating system platform, conforming to a reasonable set of human interface guidelines. Discoverability is key for making sure users understand what operations are available and how they work, and also for keeping users once they have tried the software. Testing will be used to ensure that the various GUI elements perform the intended function.
\subsection{Software Interface}
The user interface will interact with two existing components: the PhysioMIST computational engine and JSim's MML (Mathematical Modeling Language) file format.
If the interaction with the existing PhysioMIST codebase is through a library, then it will also need to have a command-line program, to ease testing, scripting, and verification.
The MML import will be tested to ensure it is compatible with the file format of the existing JSim implementation.
\section{Other Nonfunctional Requirements}
\subsection{Performance Requirements}
The performance of the underlying software which does the comparison between the models is not under the control of this project. However, it ought to be able to report the time remaining in any long operation, thus an accurate progress bar shall be displayed, with an option to cancel if that makes sense. Whenever possible, a long operation shall not render the entire GUI unusable.
The GUI shall remain responsive when displaying and editing any data set of a size that can be effectively processed by the underlying algorithms.
\subsection{Safety and Security Requirements}
Data accountability is paramount in a scientific data processing application. Working under the assumption that the existing codebase correctly models the systems at hand, we aspire to create an interface that never obfuscates or misrepresents the operations being performed. Thus, all GUI commands should possess the ability to export to a plain-text script that the user can inspect to ensure that the input to the data layer will be correct. Test suites will be used to confirm the working order of individual functional units.
\subsection{Software Quality Requirements}
When presented with a corrupt or invalid data file, the software shall not crash but display an error message, possibly attempting to help the user recover the data.
\end{document}