1. No category

Questions for RFP 763-15-0401-BS Namus System Modernization
Comment/Question:
1. Are there any online resources on the rules, regulations, and standards that govern the would-be
NamUs system? If yes, could you please provide the referencing URLs for those resources?
2. Do you have the number of registered users and the peak number of concurrent users of the existing
system?
3. Do you have a target date to get this project started?
4. What is the expected end date for this project?
5. Attachment A. Section 1.1.g, page 1 the RFP states that a unit price per item must be provided.
Does UNTS considers deliverables as items for pricing purpose and expects that pricing should be
provided by deliverables (Attachment E)?
6. Is UNTS planning to perform an acceptance testing before acceptance of the final deliverables?
7. Will UNTS provide details for the current system architecture, hardware, software, interfaces and
database?
8. Will UNTS provide information on current number of users, current average transactions volume and
current peak transaction volume?
9. Database Management – Is it required to house all missing person databases within NamUs.gov?
10. If so, where are they located currently? Are they already in cloud or need to be moved to cloud?
11. How big are these databases?
12. RFP details only the “To Be” functionality. Will UNTS share the variance and overlaps between
“To Be” and “As Is” functionalities to know how much to retain from the old functionality?
13. Attachment E: What is the minimum expected warranty period?
14. In Attachment C, Non-Functional Requirements, Client Access Technology, should we provide
optional pricing for supporting the discretionary list of mobile devices?
15. What is the availability requirement for the new system? Within the capabilities of the Amazon
GovernmentCloud, different levels of availability can be achieved based on system architecture.
16. Do you have an expected SLA for the maintenance and support services following the expiration of
the warranty period?
17. What is the technology stack used for the existing systems?
18. Do you have any specific requirements or preferences on the technology stack and/or frameworks to
be used for the new system?
19. What search technology are you currently using (SQL, Endeca, Lucene, other)?
20. If deemed helpful, are you open to new search platform?
21. The RFP mentions auto-detection for images – do you currently have technology to auto detect
insufficient density, or does this core technology need to be built?
22. Are you able to specify what constitutes insufficient density?
23. What email system is currently used for sending emails to and from the system?
24. Does the system currently support inbound emails? If deemed helpful, would we be able to alter (or
have altered) this system?
25. What mechanisms are notifications sent to users: email, in the application, text messages?
26. Can a single prioritization owner or (Product Owner) be identified given the various domains list in
the RFP? If not, will a committee be provided to make informed decisions on direction and sign-off on
project deliverables?
27. Will access to the committee or single prioritization owner be accessible only through remote means
or will the provider have local DFW based access the ultimate decision makers?
28. Will UNT be able to provide or assist us with the definition of detailed acceptance criteria in which
completion of functional and non-functional requirements will be measured?
29. If you were to describe a vision/mission as it relates to “To Be”
NamUS.org; can you give us a brief synopsis? We want to ensure your vision is met and expectations
exceeded.
30. Our process here at VENDOR Name Deleted” usually includes understanding the end-users and
context before design starts - this is done through ethnography style research - watching people use the
current tools and systems. Ideally we would then take this data and design prototypes to be validated
back with end-users before development starts. This way we’re sure that we're making the right tools
that work as the users expects.
For this RFP “VENDOR Name Deleted” would likely recommend a research engagement to build out this
understanding of end-users. Has there been any prior work on research based personas, usability test,
analytics, etc…? Where would the user data be coming from, and could we include methods to gather
more data in this engagement?
Responses to NamUs RFP Vendor Questions – May 4, 2015
Questions 2, 7, 8, 10, 11, 17, 24, and 25 – See Attachment A
2. Do you have the number of registered users and the peak number of concurrent users of the existing
system?
7. Will UNTS provide details for the current system architecture, hardware, software, interfaces and
database?
8. Will UNTS provide information on current number of users, current average transactions volume and
current peak transaction volume?
10. If so, where are they located currently? Are they already in cloud or need to be moved to cloud?
11. How big are these databases?
17. What is the technology stack used for the existing systems?
24. Does the system currently support inbound emails? If deemed helpful, would we be able to alter (or
have altered) this system?
25. What mechanisms are notifications sent to users: email, in the application, text messages?
3. Do you have a target date to get this project started? As quickly as possible following the bid award.
4. What is the expected end date for this project? 12 months from start for all major deliverables.
6. Is UNTS planning to perform an acceptance testing before acceptance of the final deliverables? Yes.
28. Will UNT be able to provide or assist us with the definition of detailed acceptance criteria in which
completion of functional and non-functional requirements will be measured? Yes.
26. Can a single prioritization owner or (Product Owner) be identified given the various domains list in
the RFP? If not, will a committee be provided to make informed decisions on direction and sign-off on
project deliverables? Yes, there will be a product owner as well as a well-defined group of
stakeholders.
27. Will access to the committee or single prioritization owner be accessible only through remote means
or will the provider have local DFW based access the ultimate decision makers? The product owner and
the majority of the primary stakeholders are in the DFW area.
30. Our process here at VENDOR Name Deleted” usually includes understanding the end-users and
context before design starts - this is done through ethnography style research - watching people use the
current tools and systems. Ideally we would then take this data and design prototypes to be validated
back with end-users before development starts. This way we’re sure that we're making the right tools
that work as the users expects.
For this RFP “VENDOR Name Deleted” would likely recommend a research engagement to build out this
understanding of end-users. Has there been any prior work on research based personas, usability test,
analytics, etc…? Where would the user data be coming from, and could we include methods to gather
more data in this engagement?
An extensive amount of research and discovery was completed prior to the RFP. All the materials,
contacts, and outcomes of discovery will be made available to the vendor following the bid award. If
the vendor feels that a research engagement is needed, we would suggest that they include that in
their bid response.
12. RFP details only the “To Be” functionality. Will UNTS share the variance and overlaps between “To
Be” and “As Is” functionalities to know how much to retain from the old functionality? Yes, an extensive
amount of research and discovery was completed prior to the RFP, and outlines both the “as is”
functionality that needs to be carried forward, as well as the gaps and expected “to be” functionality.
The outcomes of discovery will be made available to the vendor following the bid award.
13. Attachment E: What is the minimum expected warranty period? 90 days
16. Do you have an expected SLA for the maintenance and support services following the expiration of
the warranty period? Will be mutually agreed upon by both parties based on industry standards.
1. Are there any online resources on the rules, regulations, and standards that govern the would-be
NamUs system? If yes, could you please provide the referencing URLs for those resources? Yes, the
standards are identified in the RFP and are publicly available. Additionally, the current NamUs policy
manual and associated user guides for the existing NamUs system are available at
http://www.namus.gov/about.htm.
5. Attachment A. Section 1.1.g, page 1 the RFP states that a unit price per item must be provided. Does
UNTS considers deliverables as items for pricing purpose and expects that pricing should be provided by
deliverables (Attachment E)? Yes, for the minimum deliverables as described in Attachment E. Overall,
we would like the vendor to describe the terms and conditions they are willing to operate under.
9. Database Management – Is it required to house all missing person databases within NamUs.gov? Yes.
14. In Attachment C, Non-Functional Requirements, Client Access Technology, should we provide
optional pricing for supporting the discretionary list of mobile devices? Yes.
15. What is the availability requirement for the new system? Within the capabilities of the Amazon
GovernmentCloud, different levels of availability can be achieved based on system architecture. This
will be determined by OJP and NIJ (not yet set).
18. Do you have any specific requirements or preferences on the technology stack and/or frameworks to
be used for the new system? This should be described by the vendor in their bid response.
19. What search technology are you currently using (SQL, Endeca, Lucene, other)? None.
20. If deemed helpful, are you open to new search platform? Yes.
21. The RFP mentions auto-detection for images – do you currently have technology to auto detect
insufficient density, or does this core technology need to be built? No, that feature that would need to
be added.
22. Are you able to specify what constitutes insufficient density? Yes. Certain biometric images, such
as fingerprint cards, must be uploaded to NamUs in a resolution (density) that is suitable to forensic
examination and comparison. For fingerprint images, that resolution is 500 dots per inch (DPI).
NamUs 2.0 software should incorporate a mechanism to examine the image properties for DPI value,
and trigger notifications back to the party uploading the image when the resolution is less than 500
DPI.
29. If you were to describe a vision/mission as it relates to “To Be”
NamUS.org; can you give us a brief synopsis? We want to ensure your vision is met and expectations
exceeded.
FROM BJ The “to be” functionality will take NamUs technology to the next level in regard to customer
experience, internal staff efficiency and effectiveness, and administrative oversight. Specifically:
•Improving the customer experience with a more user-friendly interface, increased response
time, enhanced search capabilities, customizable search/export tools, etc.
•Increasing the efficiency and effectiveness of NamUs staff by streamlining user registrations
and case publications, providing additional case management tools, etc.
•Adding administrative and statistical reporting tools for improved strategic management of
the program.
The overarching goal is to take disparate databases and form them into one cohesive case
management system in order to more efficiently drive resolution to missing persons and unidentified
persons cases.
Attachment A
“As Is” NamUs Hosting and System Information
The current NamUs system is hosted at Rackspace on 3 physical devices/servers. This includes a Cisco ASA Firewall, a
web server and a database server. In addition to hosting, Rackspace provides Sophos Anti-Virus and full and incremental
backups.
Rackspace Database Server Specs:
Dell PowerEdge 2950 - Dual Socket Dual Core Intel Xeon 5148 LV 2.33GHz (Oracle #820-0013), #Processors: 2, #Cores
per Proc: 2; 4GB RAM; 2 ea RAID 1 73GB SAS 10K RPM Drive, HDD RPM: 10000, GB Hard Drive: 73; 500 GB Included
Bandwidth; 1 IP Address
Rackspace Web Server Specs:
HP DL385 G2 Dual Socket Dual Core AMD Opteron 2214HE 2.2 GHz, #Processors: 2, #Cores per Proc: 2; 8GB RAM; 3 ea
RAID 5 146GB SFF 10K RPM Drive, HDD RPM: 10000, GB Hard Drive; 2000GB Included Bandwidth, 1 IP Address
•
•
•
•
•
The current system uses email as the primary method of notification to users. There is no support for inbound
email, but it would be advantageous to consider that functionality in NamUs 2.0, as well as other methods of
notification (e.g., text messages).
The existing NamUs missing person database has 3,497 active, registered public users and 3,351 active,
registered criminal justice/forensic users.
The existing NamUs unidentified person database has 2,113 active, registered public users and 1,881 active,
registered criminal justice/forensic users.
It is expected that NamUs 2.0, with increased user functionality and ease of use, will significantly increase the
number of registered NamUs users. Therefore, it is expected that NamUs 2.0 will accommodate a significantly
larger number of registered users.
To date, there are 10,269 open missing person cases and 11,127 open unidentified cases in the NamUs
databases, for a total of 21,396 total open, active cases. In addition, over 10,000 cases reported to NamUs have
been resolved and archived since the program’s inception. From 2011 through 2014, the average number new
cases reported to NamUs was 4,838 per year
NamUs System Information:
Ruby Version - ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux]
Rails Version - Rails 2.1.0
Apache Version - Apache/2.2.3 (Last Update Feb. 8 2012)
OS Version - Red Hat Enterprise Linux Server release 5.8 (Tikanga)
PHP Version - PHP 5.1.6 (cli) (built: May 3 2012 17:38:00)
MySQL Version - 5.0.95
Web Server /var/www size - 114GB
MySQL Database size – Missing Persons Prod 600 MB, Unidentified Prod 461 MB, Claimus Prod
149MB
DNS (owned by UNTHSC via Network Solutions):
www.identifyus.org
www.findthemissing.org
www.claimus.org
Loaded PHP Modules:
bz2
curl
dom
gd
hash
libxml
mysql
pcntl
pdo_mysql
pspell
shmop
SPL
sysvsem
wddx
xmlwriter
calendar
date
exif
gettext
iconv
mbstring
mysqli
pcre
pdo_sqlite
Reflection
SimpleXML
standard
sysvshm
xml
xsl
ctype
dbase
ftp
gmp
imap
mime_magic
openssl
PDO
posix
session
sockets
sysvmsg
tokenizer
xmlreader
zlib
Local Ruby Gems:
actionmailer (3.2.3,
2.1.0)
activesupport
(3.2.3, 2.1.0)
daemon_controller
(0.2.6)
geokit (1.5.0)
i18n (0.6.0, 0.4.2)
multi_json (1.3.6)
rack (1.3.2)
railties (3.2.3)
rubygems-bundler
(1.0.2)
sprockets (2.1.3)
actionpack (3.2.3,
2.1.0)
arel (3.0.2)
activemodel (3.2.3)
builder (3.0.0)
activerecord (3.2.3,
2.1.0)
bundler (1.1.4)
activeresource
(3.2.3, 2.1.0)
color (1.4.1)
erubis (2.7.0)
fastercsv (1.4.0)
fastthread (1.0.7)
GData (0.0.4)
hike (1.2.1)
journey (1.0.3)
parseexcel (0.5.2)
rack-cache (1.2)
rake (0.9.2.2)
rubyzip (0.9.8,
0.9.4)
thor (0.14.6)
hoe (3.0.6)
json_pure (1.5.3)
passenger (3.0.8)
rack-ssl (1.3.2)
rdoc (3.12)
rvm (1.11.3.3)
hpricot (0.8.6)
mail (2.4.4)
pdf-writer (1.1.8)
rack-test (0.6.1)
roo (1.2.3)
soap4r (1.5.8)
tilt (1.3.3)
transaction-simple
(1.4.0)
httpclient (2.2.5)
mime-types (1.18)
polyglot (0.3.3)
rails (2.1.0)
rubyforge (2.0.4)
spreadsheet-excel
(0.3.5.1)
treetop (1.4.10)
tzinfo (0.3.33)
will_paginate
(2.2.2)
zipruby (0.3.6)