FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS FOR EXHIBITION .

2y ago
222 Views
65 Downloads
249.26 KB
22 Pages
Last View : 1m ago
Last Download : 2m ago
Upload by : Averie Goad
Transcription

FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS FOREXHIBITION DIGITAL EXPERIENCESDefinitions for terms and acronyms appearing in this document: Android: mobile device operating system developed by GoogleAPI(s): Application programming interfaceApp(s): Applications or Mobile App, depending on context. From Wikipedia: a selfcontained program or piece of software designed to fulfill a particular purpose; anapplication, especially as downloaded by a user to a mobile device.CIS: Collections Information SystemCMS: Content Management SystemCOPPA: Children's Online Privacy Protection ActCOTR: Contracting Officer’s Technical Representative (also known as COR, ContractingOfficer’s Representative)DAMS: Digital Asset Management SystemEDAN: Enterprise Digital Asset NetworkiOS: Apple mobile operating system used with Apple products such as the iPad, iPhone,etc.NASM: National Air and Space MuseumOCIO: Smithsonian Office of the Chief Information OfficerProducts: refers to all final deliverables in the statement of work.QA: Quality Assurance.SI: Smithsonian InstitutionSOW: Statement of Work/Scope of WorkSSID: Service Set Identifier. The name of a wireless local area network (WLAN)TMS: The Museum System (Gallery Systems software)UI: User Interface.UX/User Experience: quality user experience motivates people to use the product(s) toachieve their goals as well as NASM objectives.WSD: Smithsonian Web Services DivisionSERVICES PROVIDED BY CONTRACTORS DEVELOPING IN-GALLERY DIGITAL EXPERIENCES:In-Gallery digital experiences may include the following: Computer-based Interactives Digital walls or displays inside the gallery Kiosks, video displays, etc. Immersive experiences (simulators, etc.)The following digital experiences are NOT developed as part of exhibition and in-gallery projectswithout prior coordination and written agreement with the Digital Experiences Department: WebsitesMobile experiences (apps or web-based)Social Media engagementDigital displays outside the exhibition gallery (in main museum spaces)

Knowledge and Skills required: User-Experience Design (esp interactive/immersive experience design) Design Thinking and Visitor Evaluation UX for broad array of museum audiences in large space with short attention spans Visual Interface Design best practices for a variety of interfaces and interactiveexperiences (walls/tables, multi-touch, digital/physical display integration) Information Architecture Content Management System Design (Drupal) Data Management, including Personally Identifiable Information (Privacy, COPPA) Section 508 Accessibility requirements Data Transfer Protocols (JSON, APIs) Hardware specification, configuration, and testing Codebase management and version control Digital asset management (maintain all content and visual assets during project) Smithsonian software standards (Drupal, Adobe Air, HTML5, CSS, Windows) Other applicable federal regulations and guidelinesServices and deliverables for in-gallery experiences: Smithsonian Technical Review Board – Complete Smithsonian standard review processincluding initial project overview, network requirements, privacy review, securityscanning and final testing/approval prior to launch. Conceptual Design – Facilitate conceptual design process with Museum staff andproduce a written narrative of the interactive visitor experience for each discreteinteractive including target audience, learning objectives, experience narrative, andrequired assets. Visitor Testing Plan – Identify visitor testing needs and produce a written plan for testingconcepts with visitors and refining approach prior to implementation, including testinginstruments and consideration of visitor privacy. Conduct visitor testing. Implementation Plan – Specify technical and functional requirements. Produce a writtenplan for implementation including technical specifications, data management, content,and phased implementation schedule with NASM review and approval stages. Maintenance Plan – a written plan for long-term maintenance of technical components,content, visitor information, design elements, and data management. Post-launch evaluation – testing after launch during 6-mo maintenance to ensureperformance expectations are met and fix any bugs.#1TypeAccessRequirementContractor shall design foraccessibility through: Use of highly accessible colorpalette, fonts, and user-interfacedesign elements. Text alternatives/ transcriptionsfor video and audio. CaptioningSI CommentsContractor shall make good faithefforts to meet accessibilitystandards set forth in Section 508of the Rehabilitation Act (Section1194.22)

on video. Clear descriptive language forimages, titles, buttons,navigation, etc. Text shall employ adequatecontrast and size for readability.Smithsonian Institution logo andcopyright, privacy, and terms of useas defined by Smithsonian shallappear within Products.All Products shall be designed forsimplicity and ease of use. AllProducts must load and renderquickly for user.2Access3Access4AccessContractor will design forcontinuous availability of 9UserExperience10UserExperience11UserExperienceAll audio and video shall displaywith user-controlledcaptioning/transcription.Shall follow a consistent style andgraphics standard across allProducts.Kiosk visual interface must supporta minimum 1920 x 1080 targetscreen resolution.Visual interface will be designed andhardware selected to display objectphotography at high-definitionstandard or better.Shall have a consistent userexperience and employ universaldesign best practices across allProducts.All Products shall be simple,intuitive, easy to use, offering aquick and user-friendly way toaccess information, utilize allfeatures, or personalize/sharecontent.All audio and video shall displaywith player controls (play, pause,Appropriate placements perNASM guidelines.Performance optimization &speed testing shall be part of testplans. High-quality imagecompression, backgroundloading, tiling, caching,streaming content, small initialcontainer file sizes, and otherfast-loading techniques shall beemployed to ensure fastdownload/loading of Products.For interactives that requireremote resources or dataconnections, contractor shall planfor uninterrupted operations inthe event of loss of connectivity.Accessible to deaf and lowhearing visitors.Consistent design elementsacross museum interactives perNASM guidelines.Larger resolutions may bedefined by custom experience.Visual assets will be HD to 4Kquality.Consistent/seamless userexperience across all products.Interface shall not overwhelmusers and shall minimize barriersto participation.

agement1516ContentManagement –AnalyticsSocial ume, fwd, rev, length)Products shall leverage existing,central dataset/databases. AllProducts shall utilize the Museum’sCollections Information System forobject-related content unlessotherwise approved by NASM.Products shall not access TMSdirectly, but rather extract from astandalone copy of the dataset(s)required to fully enable the Productsand ensure optimal rendering andload times.Contractor shall provide a SI hosted,browser-based, custom contentmanagement system (CMS) forNASM staff to edit, update and/ormoderate all content that will not bemanaged via existing NASM/SICMS.CMS shall allow NASM staff toeasily update, edit, delete orcustomize content at any time.Contractor will implement analyticson all products for easy review ofevaluation metrics by NASM staff.Any products that include sharingcapabilities via social media and/oremail shall be consistent with otherinteractives throughout the Museumand follow applicable NASMguidelines and design standards.Products that utilize e-mail mustmeet visitor privacy guidelines,target audiences 14 and older, andfollow applicable NASM guidelinesand design standards.All content collection and socialsharing features will incorporateprivacy protection features, secureauthentication using approved APIs,and display privacy notice to users.Contractor shall configure andimplement analytics tracking on allproducts.All content shall display error-free,e.g., without conflicts, overlapping,or other performance errors.Players/audio shall stop when usersleave content view.Content shall primarily be storedand maintained in TMS, DAMS,NASM web databases, or otherexisting Smithsonian systems toreduce duplication and ensurecontent can be maintained usingexisting workflows. Somecontent may require leveragingother applications and/or creationof a new custom database/CMSper mutual agreement withNASM.Social sharing must work asexpected with appropriate imagesand metadata passed to socialnetworks.NASM e-mail templates andprivacy process must be used.Note that SI and COPPA privacyrequirements can often dictatefunctional design.Utilize Google Analytics profile.

21Metadata22Plugins/APIs23Uptime &AutomatedRestartAll visual assets shall appear withappropriate credits, sources, andID#sContractor shall obtain approvalfrom SI for the use of any 3rd partysoftware or APIs.All products must function asexpected and consistently for 10hours per day, 364 days per year.Automated restart process andtroubleshooting process must beenabled.Metadata requirements (fields) tobe provided by NASMShould be used judiciously.Exhibition interactives will bepowered down each day.Specifications for powerdown/restart shall be included indocumentation (See nonfunctional requirements).C.3.3 NON-FUNCTIONAL es4Documentation5DocumentationRequirementWork produced under this contract shallconform to the Smithsonian’sTechnology Reference Model (TRM),SD-940-01.Content to be hosted outside exhibitionspace must be hosted on SI’s centrallysupported web infrastructure andconform to the technology standards ofthat infrastructure.Contractor shall provide an upgrade planfor all elements. Plan must describe howthe Products can be ported to upgradedplatforms in future, and which elementsare likely to be reusable or not in thelong term.The contractor shall provide designdocumentation and source files. Final Style Guide (colors, fonts, etc.) Experience map, flowcharts,wireframes, comps Original raw design filesContractor will provide technicaldocumentation. Technologies used, namingconventions, informationmanagement standards, accessibility/ usability practices, searchprotocols/indexes, analytics,database tables, and any otherfunctional considerations.SI CommentsSee infrastructurerequirementsSmithsonian must haveoriginal source files anddocumentation sufficient toreplicate or extend Productsin the future.Smithsonian must havetechnical documentationsufficient to diagnoseproblems and make changesin the future.

sting/QARequirementContractor will provide userdocumentation User documentation, how to useCMS to make content updates andmodifications. This documentshould be targeted to staffmaintaining content who do nothave a technical background Administrator documentation, howto add/edit users, adjust settings, ormodify CMS.Contractor shall provide some contentscripting (writing) for supplementarycontent.Contractor shall conduct final QA of allcontent (text, visual assets) for allProducts, ensuring final version ofcontent approved by NASM is in Goldproduct.The product shall be tested during,before and after deployment to verifythat it functions as intended and that allrequirements are met.Master Test Plan (with discrete testplans for each individual Product)To include: How testing will be used to ensurethat the delivered product meets SI’srequirements and functions asdesigned What will be tested How testing will be performed Pass / fail criteria Test deliverables (e.g. test report,including discrepancies identifiedduring testing). Test scripts (procedures) Test environment (Initial testing willbe performed by the Contractor attheir facilities with a final reportsubmitted to the Smithsonian. Thesame Master Test Plan will later beused to conduct acceptance testing atthe Smithsonian facilities.)SI CommentsSmithsonian staff must beable to easily updateProducts and manage theCMS over time.NASM shall provide editedscript content (text andvisual assets). Contractorshall provide all othercontent with NASMguidance and approval.NASM will provide editedscript and approval.Mutually agreed testing anddeployment scheduleThe intent of this documentis to describe and provide atest framework and set oftest steps that can be reexecuted to validatefunctionality and/or afterchanges are made and by SI,at it’s option, for acceptancepurposes.The Master Test Plan shouldinclude separate test plansthat can be executedindependently for mobileexperience, website, MediaWall and interactive kiosks.

equirementContractor shall provide a Mobile TestPlan and conduct iterative onsite testingof mobile user-experience, with aparticular focus on: location-awareness data download/playback connectivity over Smithsonian WiFi provided free to visitors(currently SI-Visitor)The contractor shall provide test resultsshowing successful testing of all criticalfunctionality and user-experience for allProducts. As a condition of Productacceptance, final Test Plan(s) withall elements successfully tested (passrating) must be submitted one monthprior to final product readinessreview by Smithsonian TechnicalReview Board.Prior to acceptance, the parties shallstress load test the Products inaccordance with the performancerequirements set forth herein. Based onthe results of such testing, and prior toproduction deployment, Contractor shallalter the Products to comply with thestandards set forth herein. Contractorshall provide test results showingsuccessful testing of all criticalfunctionalities and outliningdiscrepancies identified during testing.SI CommentsThis testing must beinitiated early indevelopment to ensure timeto address any issues.Iterative test reports andfinal Master Test reports,including discrepanciesidentified during testing

#14TypeSecurity TestingRequirementPrior to acceptance, the Products shall beplaced in a test environment where theycan be subject to a series of web securitytests under the direction of theSmithsonian OCIO. The Products willbe scanned for vulnerabilities by theSmithsonian, and must pass securitytesting prior to acceptance. All high andmedium vulnerabilities will need to beaddressed, fixed, or mitigated to thesatisfaction of the Smithsonian prior toproduction launch. Contractor shouldmake a Contractor-hosted developmentsite available to the Smithsonian forpremigration security testing. After asuccessful Master Test of the Products,Contractor will install the final Productson the Smithsonian Web environment inthe Smithsonian’s Data Center. TheSmithsonian will then conduct securitytesting, which shall include but not belimited to the top ten vulnerabilitiesidentified on the OWASP site. Anyproblems will be reported to theContractor for resolution. Acceptancetesting re-executing the Master Test Planwill be performed by the Contractor andwitnessed by the Smithsonian utilizingSmithsonian infrastructure andconducted in Smithsonian facilities.Acceptance testing will not begin untilthe Products have successfully passedthe security testing. The toolSmithsonian currently uses is CenzicHailstorm, though other tools mayalso be used in consultation withSmithsonian. Time for scanning andremediation must be accounted for in theproposed Project schedule.SI CommentsWhere user authentication ispart of a Product, anadditional authenticationreview by OCIO is requiredto determine the appropriateauthentication method.

#15TypeDocumentation16Documentation17Source Files18Source Code19Code ReviewRequirementThe contractor shall provide a systemconfiguration document. As a condition of acceptance of theProducts, Contractor shall provide asystem configuration report writtenfor the target audience ofadministrator(s) for each digitalelement (mobile, website,Wall/Kiosks). The report shouldprovide detailed information on howeach Product is installed andconfigured on their respectiveplatforms, including all requiredserver or platforms settings,database connection methods / API /or other connection strings, and anyinitialization file(s) or other criticalfiles.The contractor shall provide userdocumentation.The contractor shall provide all sourcefiles including high-resolution (nonderivative) master-image files and allsoftware code to SI.All code shall be annotated according tosoftware engineering best practices.During development of the Products, theContractor shall make the source codefor sections of the Products available byprivate repository through GitHub or asimilar service. The Smithsonian willconduct regular reviews of the code and,as necessary, will provide feedback oncorrective actions to be taken by theContractor. All code must becommented appropriately to aid inreview.SI CommentsShould any Product bemoved to different hostingenvironment or file locationin the current environment,it should be possible for aSmithsonian administrator,who is not familiar with theProduct, to reference thisdocument and have all theinformation necessary to getit up and running quickly.Detailed instructions for SIstaff on how to access, add,delete, or modify contentand/or otherwise modify thesite(s). This documentshould be targeted to theunit site owner and it shouldbe assumed that staffmaintaining the content donot have a technicalbackground

#20TypeMobile AppRequirementContractor shall design iOS App,Android App to adhere to applicablestandards for mobile devices (tablet andsmartphone platforms), including but notlimited to: Apple’s standards for iOS apps: 1)iTunes human interface guidelinesand 2) app store review guidelines Google Play guidelinesSI Comments21Mobile AppNASM will providemetadata.22IntegrationContractor will handle all requirements,testing, and associated procedures forApp store submissions. All submissionswill be made under Smithsonian’saccount/name.Contractor is responsible for allintegration and associated testing/qualityassurance of all Products, including butnot limited to: Data / API / Connectivity / Databaseintegration and testing. Hardware / software configuration,installation, integration, and testing. Uptime testing and diagnostics.23AccessibilityReasonable effort shall be made toaccommodate users with visual, hearing,or mobility impairments, and otherdisabilities.Good faith effort should bemade to meet all otheraccessibility standards setforth in Section 508 of theRehabilitation Act (§1194.22) and the W3Cpriority 1, 2, and 3checkpoints for web contentaccessibility.Smithsonian must approveany exceptions to Section508 and W3C standardsprior to development.Data integration will involveconsultation with NASMstaff, discovery of systems,and recommendations ondata storage/retrievalmethods.

#24TypeTrainingRequirementContractor will conduct training forMuseum staff and subcontractors onoperation, modification, testing, andmaintenance of all Products.25Evaluation &User-TestingContractor shall provide an iterativeuser-experience test plan for allProducts.Test plan must include usability of allelements essential to meeting the userexperience goals of the Products.SI CommentsSeparate training sessions ofapproximately 1 hour eachfor: Digital mediaoperations, contentmaintenance. Content expert CMStraining. Exhibits Tech staffkiosk/Wallhardwareinstallation andhardware/softwaremaintenance.This may be folded into theMaster Test Plan, but mustaddress user-experience,rather than purely technicalelements. Plan shall includeat least three user testingstages prior to Gold deliveryand one post-launch testingsession. See schedule.

#26TypeEvaluation &User-TestingRequirementContractor will cond

functional requirements). C.3.3 NON-FUNCTIONAL REQUIREMENTS. # Type Requirement SI Comments 1 Policy Compliance Work produced under this contract sha ll conform to the Smithsonian’s Technology Reference Model (TRM), SD-940-01. 2 Hosting Content to be hosted outside exhibition space must be hosted on SI’s centrally .

Related Documents:

What are Non-functional Requirements? Functional vs. Non-Functional – Functional requirements describe what the system should do functions that can be captured in use cases behaviours that can be analyzed by drawing sequence diagrams, statecharts, etc. and probably trace to individual chunks of a program – Non-functional .

Automated Quality Assurance of Non-Functional Requirements for Testability Abderahman Rashwan A Software Requirements Specification (SRS) document contains all the require-ments to describe a software system to be developed. These requirements are typically separated into Functional Requirements (FRs), which describe the fea- tures of the system under development and Non-Functional .

The purpose of this functional and non-functional requirements specification is to provide documentation to prospective solution vendors on the requirements to satisfy internal business processes to implement and operate a Client Information, Volunteer and Human Resources Management multi-tenant web based solution.

3. Functional Requirements This section lists the functional requirements. Functional requirements describes the possible effects of a software system, in other words, what the system must accomplish. Other kinds of requirements (such as interface requirements,

technical requirements and constraints as ‘non-functional requirements’, abbreviated as ‘NFR’, and ‘project requirements and constraints’ abbreviated as ‘PRC’. In the late 1970’s when functional size measurement was first invented, few NFR were

non-functional requirements can be directly mapped to the execution platform, not only during the deployment phase, but also along the whole design process. Our proposed approach in this paper extends DEVA an-notations with new high-level values that correspond to non-functional requirements. An underlying application-dependent

Numeric Functional Programming Functional Data Structures Outline 1 Stuff We Covered Last Time Data Types Multi-precision Verification Array Operations Automatic Differentiation Functional Metaprogramming with Templates 2 Numeric Functional Programming Advanced Functional Programming with Templates Functional Data Structures Sparse Data Structures

1 Advanced Engineering Mathematics C. Ray Wylie, Louis C. Barrett McGraw-Hill Book Co 6th Edition, 1995 2 Introductory Methods of Numerical Analysis S. S. Sastry Prentice Hall of India 4th Edition 2010 3 Higher Engineering Mathematics B.V. Ramana McGraw-Hill 11 th Edition,2010 4 A Text Book of Engineering Mathematics N. P. Bali and Manish Goyal Laxmi Publications 2014 5 Advanced Engineering .