Phase 1 System Requirement Specification - The Square Kilometre ...

SKA Requirements Landscape - 1SPDO• Information leading to formal Requirements are obtained from:– Needs of ‘Technology Agnostic’ Astronomers• DRM– Needs of ‘Technology Conscious’ Astronomers• DRM, Strategies & Philosophies– Inputs of Experienced Observational Astronomers• Operations Plan, Strategies & Philosophies– Inputs from SKA related pioneering projects• Strategies & Philosophies– The Statutory/Regulatory environment• Strategies & Philosophies– The physical environment• Environmental Specification– Standards– Inputs of Experienced System, Integration, Infrastructure, Verification,Management, Quality, Reliability .... Engineers• ‘Plans’– Inputs of Technology Evangelists– Inputs of Consulting Technologists• Some of these latter stakeholders can also supply solutions!

SKA Requirements Landscape - 2SPDO• The nature of the community means thatrequirements engineering is particularly difficult in theearly phases– The preponderance of ‘soft’ requirements– The widespread belief that Requirements Engineering isinflexible– The magnitude of the work to achieve consensus• The first expression of most requirements (the ‘protorequirement’) usually needs clarification andrefinement• Proto requirements sometimes give rise to conflicts• Even complete, correctly expressed, non conflictingproto requirements need scrutiny regardingnecessity, heritage, credibility, implicitpessimism/optimism, abstruseness, ...

Requirements since CoDRSPDO• Descoped Science Requirements– Reduce the number of science DRMcomponents– Negotiate the performance and functionalityrequired for those DRM components• Ongoing• Extensibility to Phase 2– Some such requirements have been identified• Dish figure and feed accommodation• Ongoing– Extensibility requirements are likely to be on thecritical path

HLD and SyRSSPDO• The High Level Description is a comprehensive discussion of theprincipal technologies and technical schemes within an exemplaryframework• The HLD is not a design, which would be inappropriate before therequirements capture and architectural tradeoff phases are complete– It is a “look-ahead” and helps to concentrate the mind on gettingRequirements right– It is not strictly traceable from the SyRS• The System Requirements Specification is the nexus for all incominghigh level requirements and the root of all System Engineering activity• The SyRS is in an early stage of development and contains:– Considerable white space in the non-science requirements sections– Some unstable science requirements– Limited traceability and verification• The SyRS development is a major and continuous task– It is necessary to carry it out formally and correctly, as it becomes thesource work for many trade studies, scoping exercises, budgetarymeasures, etc– Change Control is now mandatory, although Baselining does not take placeuntil just before SRR

Design Reference MissionSPDO• Principal Science Requirements Document for SKA 1– Somewhat modelled on NASA requirements process (hence ‘Mission’)– Describes ‘DRM components’ derived from Science Case Key ScienceProjects• Version 1.4 contains 49 formal requirements based on 5 DRMcomponents plus extensibility considerations• This Review is based on Version 1.3– Not fully reflected in Phase 1 descriptions• 50 MHz vs 70 MHz lower frequency reach– 1.4 exists• 1.4 has significant changes– Emphasises the need for configuration control• Comments to SyRS (and by implication DRM) show that considerableclarification is required– Tolerances, trade spaces, scalars that are actually vectors/functions, etc• The status is to be expected at this stage, but there is much work to bedone

DRM 1.4 changesSPDO• A requirement for A eff /T sys of 2000 (1000) over 50-240MHz for the Aperture Arrays (from Memo 125)– Change from 70 to 50 MHz acknowledged and subject toanalysis (see TN)• Maximum baseline of 50 km (200) for AAs(although 200 remains justified for other reasons?)• AA station diameter of 35m (30m) and a total numberof >140 (>160)• Dish polarisation purity of 40dB now applies over theaccessible sky (rather than just zenith)• Cadence of pulsar timing observations is nowspecified

Sources of RequirementsSPDO• Design Reference Mission v1.3• SKA Science Working Group,“The Square Kilometre ArrayDesign Reference Mission: SKAmidand SKA-lo”, report, v.1.0– For extensibility considerations• SKA Strategies and PhilosophiesWP2-005.010.030-TR-001– Principles– Priorities• SKA Site Climate Data– Not a requirements source, but willbe used to create top level physicalenvironmental requirements• ‘The Radio FrequencyInterference Environment AtCandidate SKA Sites’ WP3-010.020.000-R-002– Not a requirements source, but willbe used to create top level RFIenvironment requirements• Site Selection Criteria– Considered complied with, andretired, upon Site Selection• Operations– ConOps– Use cases– Availability expectations• Applicable national statutoryinstruments– Health & Safety legislation• Construction, operation,decommissioning– Utility regulations• Power, water, PSTN, data carriage– Environmental legislation• Construction, operation,decommissioning– Socio-political legislation• Rural development policy– Culture & Heritage legislation• Conservation, access rights– Energy policy• Carbon emissions– Security policy• Criminal, political– International trade policies

Roadmap to the SRRSPDO• Detailed review, refinement andnegotiation of the SKA 1 DRM• Develop Use Cases for each ofthe chapters of the SKA 1 DRM tounderstand and extract thetechnical requirements• Gather, refine and analyse thesystem requirements• Development and refinement ofthe science and supportOperations concepts• Derive environmental andregulatory requirements andconstraints• Continue to document therequirements and constraints inthe SKA 1 System RequirementSpecification under ChangeControl• Making them available to Domains on aplanned basis• Establish a lower level DocumentTree• Establish a preliminary VerificationPlan– This includes introducing specialbudgetary control requirements• Conduct Domain Concept DesignReviews• Consider the outputs of theDomain CoDRs at theObservatory level.– This will include models of aspectssuch as cost, performance, power,reliability etc.• Establish further Observatory levelcost models to assist convergenceon an outline full lifecycle cost• Develop the SKA 1 architecturaldesign document

QuestionsSPDO

Role of StandardsSPDO• A very large number of Standards can apply to SKAactivities, from development to decommissioning• Standards will be implicit in statutory obligations– Perhaps including unfamiliar (non-ISO) ones• Standards help us in the Verification task• The intelligent use of Standards helps control costs• It is common in large science projects to reference, ormake applicable, Standards when there is little or nocognizance• Elective whole cloth adoption of Standards must bedone with some care and with appropriate investmentof resources