Intent Specification Intent Specification is used in SpecTRM

  • View
    214

  • Download
    0

Embed Size (px)

Text of Intent Specification Intent Specification is used in SpecTRM

  • Intent SpecificationIntent Specification is used in SpecTRMhttp://www.safeware-eng.com/index.php/products

  • Intent Specification and SpecTRMSpecTRM Tool that can use Intent Specification Specification Tools Requirements MethodologyMade for use with development of safety-critical softwareMade by Safeware EngineeringSpecTRM-RLAnother method that can be used in SpecTRM*

  • Key benefits 1Finding errors early in developmentFix with lowest cost and impact on system designTracing requirements and design rationale throughout system construction and documentationSafety constraints*

  • Key benefits 2Building required system properties into the design from the beginningBuilding bridges between specialistsSystem engineeringSoftware engineeringSafety engineering*

  • Why Intent Specification? 1Normal specification are structured in levels of what and howThis helps to cope with complexityUnanswered questionWhy?Why are decisions made?Why did we do it that way?Why cant it do ?Important with changing requirements*

  • Why Intent Specification? 2Software-related accidents mostly come from problems with requirements A good specification needs to be organized, readable and reviewableImproved set of practices for writing specificationsCan be tailored for needs of the project*

  • Structure of Intent SpecificationNancy Leveson*

  • Levels and decompositionLevel 0: Program Management InformationLevel 1: System-Level Goals, Requirements, and ConstraintsLevel 2: System Design PrinciplesLevel 3: Blackbox BehaviorLevel 4: Physical and Logical DesignLevel 5: Physical ImplementationLevel 6: System OperationsEnvironmentOperatorSystem and componentsVerification and Validation

    *

  • The LevelsEach level is a complete view of the systemEach level is expressed in a different way that motivates the level belowNot necessary to complete one level before starting on the nextWithin a level all aspects of the system are addressed*

  • TraceabilityLink down from higher level shows how something been executedLink up from code show why it was made in this wayLinks between parts at same level that affect each otherExample:Each hazard would link to safety design constraints within the same levelEach safety constraints would link down from level one to level two where decisions comply with safety constraints*

  • Level 0: Program Management InformationProject and safety plans that will guide development of the systemProgram Management PlansProject overviewBudgetingList over personnel and responsibilitiesSystem Safety PlanDescribes safety objectives and how they will be achievedPlans for subsystem safety*

  • Level 1: System-Level Goals, Requirements, and Constraints 1Introduction of system being builtHistorical informationHistorical background or precedentPuts the system in context EnvironmentSystems are not independentDescriptionIllustrative examples of where, when and under what circumstances the system will be used*

  • Level 1: System-Level Goals, Requirements, and Constraints 2AssumptionsSystem relies upon for safe operationWrong assumptions may lead to accidentsConstraints Assumptions needs to be trueSystem goalsReason the system is being built*

  • Level 1: System-Level Goals, Requirements, and Constraints 3High-Level RequirementsWhat is the system to do System LimitationsRequirements that cannot be implementedOperator Requirements Hazard AnalysisAssumptions, requirements and constraints for the operator*

  • Level 1: System-Level Goals, Requirements, and Constraints 4Hazard AnalysisGenerate hazard list and logHazard List and AssessmentAll known hazard for systemMore can be found during development and addedDesign and Safety ConstraintsConstraints document things that the system should not doLimits space of possible design for the system*

  • Level 1: System-Level Goals, Requirements, and Constraints 5Non-Safety ConstraintsSafety constraintsMotivated by safety concernsVerification and ValidationPlans and procedures for reviewing the requirements*

  • Level 2: System Design PrinciplesAnswers why for subcomponent requirements at level 3System Design PrinciplesRecord design decisions that meet requirements and enforce constraints of level 1Operator Task Design PrinciplesResponsibilities for operatorsVerification and ValidationInformation about the validation of the design principles for this level*

  • Level 3: Blackbox BehaviorDescribes only the requirements for the behavior of the components as seen from the outsideSystem Blackbox BehaviorModel of subcomponent behaviorUser ModelUser behaviorFind parts of the system that might match poorly with human capabilityVerification and ValidationEnsures that components will operate in ways that satisfy system-level requirements and design decisions*

  • Level 4: Physical and Logical Design 1Describes the physical and logical designs of each subcomponentContain design specification for subcomponent or reference to design specification Hardware Design Specifications Software Design Specifications Physical Interface DesignDescribe human factors*

  • Level 4: Physical and Logical Design 2Training PlanDescribe how to train operatorsOperations PlanDescribe how to use the system is to be operatedVerification and ValidationDesign walkthroughs and results*

  • Level 5: Physical Implementation 1Either information of the physical implementation of the system or references to where such information areSoftware sourcecodeHardware SchematicsHardware Assembly and Installation Instruction*

  • Level 5: Physical Implementation 2Operator Training ManualsInstructions for useTraceability to ensure hazard mitigationOperator (User) ManualsAs Operator Training ManualsVerification and ValidationTest plans and resultsSpecial plans for test safety-critical behavior*

  • Level 6: System OperationsLearn from operational history of systemPattern of accidentsTrack of a systems operational performancePredict future problems For next version or product*

  • Use in buisness-crtical systems? 1Can reduce/drop what intent specification says about SafetyHazardsEasier to change SW without unforeseen errorsKnow why a decision was madeKnow what test or simulation needs do be redone and what do not need to be redoneEasier to avoid design errors*

  • Use in buisness-crtical systems? 2Possible to reuse parts of documentation for another project?Can be used with any programming languageCan be used with other methods for developing software?UML, RUP and XP*

  • Finished, questions?

Related documents