Requirements specification: A structured document that sets out the services the system is expected to provide Should be precise so that it can act as a contract between the system procurer and software developer and thus needs to be understandable by procurers and developers Describes what the system will do but not how it will do it(objectives but not how objectives will be achie Design specification An abstract description of the software that serves as a basis for (or describes its detailed design and implementation Describes how the requirements will be achieved Primary readers will be software designers and implementers ra ther than users or management The goals and constraints specified in requirements document should be trace able to the design specification(and from there to the code
✂✁☎✄✝✆✟✞✡✠☛✁✌☞✍✁✏✎✒✑✔✓✂✓✖✕✗✁☎✘☎✞✚✙✛✘✢✜✣✑☛✞✥✤✦✎★✧ ✩✫✪✭✬✯✮✱✰✯✲✖✳✴✮✵✲✖✰✵✶✴✷✂✷✖✸✹✳✺✲✖✻✼✶✺✽✾✮✿✮✵❀☛❁❂✮❃✬✵✶❄✮✱✬❅✸❆✲❇✮✿✮✱❀✔✶❈✬✵✶✴✰✯❉✹❊❋✳✴✶✺✬✿✮✵❀✖✶●✬✡❍❇✬✡✮✱✶✴✻ ❊■✬✿✶❄❏❇❑▲✶✺✳❄✮✱✶✺✷▼✮✵✸ ❑✖✰✯✸◆❉❇❊■✷✖✶P❖ ✩▼◗❇❀✔✸❆✲✖❘❋✷❚❙▲✶✟❑✖✰✵✶✴✳✺❊■✬✵✶✛✬✵✸❯✮✱❀☛❁❱✮❲❊■✮❳✳✺❁P✽❈❁❂✳✴✮✝❁P✬❲❁★✳✺✸P✽❨✮✵✰✱❁P✳❄✮✝❙❩✶❄✮✚❬✒✶✴✶✺✽❈✮✵❀✖✶✟✬✯❍✹✬✯✮✵✶✺✻❭❑✖✰✯✸❇✳✴✲✖✰✵✶✴✰ ❁P✽✔✷❈✬✵✸❂❪❫✮✚❬❴❁P✰✯✶✗✷✖✶❄❉❆✶✴❘❋✸❆❑▲✶✺✰❵❁P✽✖✷❈✮✵❀✹✲✔✬❵✽✖✶✴✶✺✷✖✬✝✮✱✸✿❙▲✶✗✲✔✽✖✷✖✶✺✰✯✬✯✮✱❁P✽✖✷☛❁P❙✔❘❋✶✗❙✾❍❛❑✖✰✯✸❇✳✴✲✖✰✵✶✴✰✵✬❜❁❂✽✖✷ ✷✖✶❄❉❆✶✴❘❋✸❆❑▲✶✺✰✯✬✺❖ ✩❞❝❜✶✴✬✵✳✺✰✯❊❋❙▲✶✺✬✛❡✣❢✔❣P❤✐✮✱❀✔✶❥✬✡❍✹✬✯✮✱✶✴✻❦❬❲❊❋❘❋❘❧✷✖✸❯❙✖✲✔✮♠✽✖✸P✮❜❢☛♥❱❡♦❊■✮❳❬❲❊❋❘■❘✐✷✖✸✼❊■✮q♣r✸❆❙✹s✯✶✺✳❄✮✱❊t❉❆✶✺✬✝❙✖✲✔✮✝✽✖✸❂✮ ❀✖✸◆❬✉✸❆❙✹s✯✶✺✳❄✮✱❊t❉❆✶✺✬❲❬❲❊❋❘■❘❧❙▲✶❥❁P✳✈❀✖❊❋✶❄❉❆✶✴✷①✇❄❖ ②✉✁☎✓✖✞✥③✦✎④✓✔✕✗✁☎✘☎✞✥✙✛✘✢✜✣✑✖✞✥✤✒✎★✧ ✩✫✪♠✽⑤❁❂❙✖✬✯✮✵✰✱❁P✳❄✮♠✷✔✶✺✬✵✳✴✰✵❊■❑✔✮✱❊■✸❆✽⑥✸P❪✌✮✱❀✖✶✟✬✯✸P❪❫✮✚❬❴❁❂✰✵✶✟✮✱❀☛❁❱✮❲✬✵✶✺✰✡❉❆✶✴✬❜❁P✬❲❁★❙☛❁P✬✯❊❋✬❴❪r✸❆✰✟♣⑦✸❆✰❳✷✖✶✴✬✵✳✴✰✵❊❋❙▲✶✺✬✱✇ ❊t✮✱✬❳✷✖✶❄✮✈❁P❊■❘❋✶✺✷⑥✷✔✶✺✬✵❊■⑧❆✽⑤❁P✽✖✷❛❊❋✻✼❑✖❘❋✶✴✻❃✶✴✽❨✮✱❁❂✮✱❊■✸❆✽✐❖ ✩❞❝❜✶✴✬✵✳✺✰✯❊❋❙▲✶✺✬❜❢☛♥❱❡⑨✮✱❀✖✶✛✰✵✶✴⑩❨✲✖❊❋✰✯✶✺✻✼✶✺✽✾✮✱✬❳❬❲❊❋❘■❘❧❙▲✶❥❁P✳✈❀✖❊❋✶❄❉❆✶✴✷✐❖ ✩❞❶❷✰✵❊■✻✿❁❂✰✯❍❃✰✵✶❸❁❂✷✖✶✺✰✯✬❲❬❲❊■❘❋❘❩❙❩✶✟✬✯✸P❪❫✮✚❬❴❁❂✰✵✶❥✷✖✶✺✬✯❊❋⑧❆✽✖✶✴✰✵✬✝❁P✽✖✷❚❊■✻❃❑✖❘■✶✺✻✼✶✺✽✾✮✱✶✴✰✵✬❴✰✵❁❂✮✱❀✔✶✺✰❴✮✱❀✖❁P✽⑤✲✔✬✵✶✺✰✯✬ ✸❆✰❳✻❃❁P✽☛❁❂⑧❆✶✺✻✼✶✺✽✾✮❸❖ ✩✫❹❳❀✖✶✛⑧❆✸❆❁P❘❋✬❲❁P✽✔✷⑤✳✴✸❆✽✖✬✯✮✵✰✱❁P❊■✽✾✮✱✬❲✬✵❑▲✶✺✳✴❊■❺☛✶✴✷⑤❊■✽❛✰✯✶✺⑩❨✲✖❊■✰✵✶✺✻✼✶✺✽✾✮✵✬♠✷✖✸✹✳✺✲✔✻❃✶✴✽❨✮✝✬✯❀✖✸❆✲✖❘■✷❛❙▲✶✟✮✱✰✵❁P✳✺✶❼❻ ❁P❙✔❘❋✶❜✮✱✸★✮✵❀✖✶✛✷✖✶✺✬✯❊❋⑧❆✽❛✬✵❑▲✶✺✳✴❊■❺☛✳✺❁❂✮✱❊■✸❆✽❽♣❾❁P✽✖✷⑥❪r✰✯✸❆✻❿✮✱❀✔✶✺✰✵✶✟✮✵✸❯✮✵❀✖✶✛✳✺✸✹✷✖✶◆✇❼❖ ➀
Contents of requirements document Introduction: Describes the need for the system and places it in context briefly describing its functions and presenting a rationale for the software. De- scribes how the system fits into the overall business or strategic objectives of the organization commissioning the software System Model: Sets out the system model showing the relationships betwer the system components and the system and its environment. An abstract data model should also be described if appropriate to the type of system Ystem Evolution: The fundamental assumptions on which the system is based and anticipated changes due to hardare evolution, changing user needs Goals (sometimes called Functional Requirements): The services provided for the user. This includes timing and accuracy requirements Constraints: Constraints on how the goals can be achieved (restrictions on the behavior of the software and the freedom of the designer) These are restrictions on allowa ble designs or the ways the goals can be achieved e.g., safety constraints, hardware, programming languages, and standards that must be followed. They also include quality requirements, such as maintain- a bility, availability, etc Priorities: This section basically specifie es now tI adeoffs will be made if all of the goals and constraints cannot be completely achieved in the design--some may be more important than others. Guides tradeoffs among design decisions Interfaces to the environment: Input or output interfaces and relevant sumptions about environmental components with which the software will b interacting Glossary: Definitions of technical terms used in the document Indexes: Various types of indexes may be provided
➁✤✒✎✒✑✔✁✏✎✒✑✔✓▼✤➃➂❛✠☛✁☎✄✝✆✟✞✥✠☛✁✏☞✍✁✌✎✒✑✖✓✂➄✟✤❲✘☎✆✟☞✍✁✏✎✒✑✐✧ ✩✫➅✴➆❩➇◆➈➊➉✢➋✌➌✏➍P➇◆➎⑦➉▲➆➐➏➑❝❜✶✺✬✵✳✴✰✵❊■❙❩✶✴✬❅✮✱❀✖✶●✽✔✶✺✶✺✷✂❪r✸❆✰❃✮✱❀✖✶➒✬✡❍❇✬✡✮✱✶✴✻ ❁P✽✖✷✂❑✖❘❋❁P✳✺✶✴✬❅❊■✮✿❊❋✽✂✳✴✸❆✽✾✮✱✶❄❏✹✮✺➓ ❙✖✰✯❊❋✶❄➔✖❍⑥✷✖✶✴✬✵✳✺✰✯❊❋❙✖❊■✽✖⑧❯❊■✮✵✬❲❪r✲✔✽✖✳✴✮✵❊❋✸❆✽✖✬❲❁❂✽✖✷⑤❑✔✰✵✶✺✬✯✶✺✽✾✮✱❊■✽✖⑧❅❁★✰✵❁❂✮✱❊■✸❆✽☛❁P❘■✶❵❪r✸❆✰❴✮✱❀✔✶❥✬✯✸P❪❫✮✚❬✒❁P✰✵✶❂❖❴❝❜✶❄❻ ✬✯✳✺✰✵❊■❙❩✶✴✬q❀✔✸➊❬→✮✵❀✖✶✼✬✯❍✹✬✯✮✵✶✺✻④❺✖✮✱✬❥❊❋✽✾✮✱✸❚✮✱❀✔✶❃✸◆❉❆✶✴✰✱❁P❘■❘➐❙✖✲✖✬✵❊■✽✖✶✺✬✯✬✗✸❆✰❥✬✯✮✵✰✱❁❂✮✵✶✺⑧❆❊■✳❯✸❆❙✹s✯✶✺✳❄✮✱❊t❉❆✶✺✬q✸P❪ ✮✵❀✖✶✛✸❆✰✵⑧✾❁❂✽✖❊❋➣✺❁❂✮✱❊■✸❆✽❅✳✺✸P✻❃✻✼❊❋✬✯✬✵❊❋✸P✽✖❊❋✽✖⑧❥✮✱❀✖✶✛✬✯✸P❪❫✮✚❬❴❁❂✰✵✶P❖ ✩↕↔❩➙☎➛✴➇◆➜✹➝ ➞➟➉✢➋✌➜✹➠✥➏♠◗❇✶✴✮✵✬♠✸❆✲❇✮✝✮✵❀✖✶❥✬✯❍✹✬✯✮✵✶✺✻❭✻❃✸✹✷✖✶✴❘✢✬✵❀✖✸◆❬❲❊❋✽✔⑧❃✮✱❀✔✶❥✰✯✶✺❘❋❁❂✮✱❊■✸❆✽✖✬✵❀✔❊❋❑✖✬❳❙▲✶✴✮✚❬✦✶✺✽ ✮✵❀✖✶✟✬✯❍✹✬✯✮✵✶✺✻❦✳✴✸❆✻❃❑▲✸❆✽✖✶✴✽✾✮✱✬❲❁P✽✖✷⑥✮✵❀✖✶✟✬✯❍✹✬✯✮✵✶✺✻❭❁P✽✔✷❛❊t✮✱✬❴✶✴✽✾❉❇❊■✰✵✸❆✽✔✻❃✶✴✽❨✮✺❖➐✪❵✽❛❁P❙✖✬✡✮✱✰✱❁❂✳✴✮❲✷☛❁❂✮✱❁ ✻✼✸❇✷✔✶✺❘✐✬✯❀✖✸❆✲✖❘■✷⑤❁❂❘❋✬✵✸❯❙▲✶✛✷✖✶✺✬✯✳✺✰✵❊■❙❩✶✴✷⑤❊t❪✏❁P❑✖❑✖✰✯✸❆❑✖✰✵❊❋❁❂✮✱✶❜✮✵✸★✮✱❀✖✶✟✮✚❍✹❑❩✶❥✸P❪✏✬✯❍✹✬✯✮✵✶✺✻❛❖ ✩↕↔❩➙☎➛✴➇◆➜✹➝ ➡❵➢▲➉▲➠❾➌✢➇➊➎r➉▲➆➃➏♦❹❳❀✖✶❈❪r✲✖✽✔✷☛❁P✻✼✶✺✽✾✮✈❁P❘❵❁P✬✵✬✯✲✖✻✼❑✔✮✱❊■✸❆✽✖✬✿✸P✽❞❬❲❀✖❊❋✳✈❀▼✮✵❀✖✶❈✬✡❍✹✬✯✮✱✶✴✻ ❊■✬ ❙☛❁❂✬✵✶✺✷♦❁P✽✔✷❽❁❂✽❨✮✵❊❋✳✴❊❋❑☛❁❂✮✵✶✺✷●✳✈❀✖❁P✽✖⑧❆✶✴✬❥✷✔✲✖✶➤✮✱✸❚❀☛❁P✰✯✷☛❁P✰✯✶➤✶✴❉P✸❆❘❋✲✔✮✵❊❋✸❆✽❧➓✐✳✈❀☛❁P✽✖⑧P❊❋✽✖⑧⑥✲✖✬✯✶✺✰✟✽✖✶✴✶✺✷✖✬✴➓ ✶❄✮✱✳P❖ ✩↕➥❅➉▲➦✖➠❾➛❃♣⑦✬✯✸❆✻❃✶❄✮✱❊■✻❃✶✴✬❴✳❸❁P❘■❘❋✶✴✷⑤➧☎➌✌➆✏➍P➇◆➎⑦➉▲➆☎➦☛➠✒➨❅➜✹➩✐➌✌➎⑦➈➊➜✹➝➫➜✹➆❩➇➊➛❸✇❄➭➯❹❳❀✖✶❥✬✵✶✴✰✯❉✹❊❋✳✴✶✺✬✝❑✖✰✵✸◆❉✹❊❋✷✔✶✺✷ ❪r✸❆✰❴✮✵❀✖✶✛✲✖✬✵✶✴✰✺❖➐❹❳❀✖❊■✬✝❊■✽✖✳✺❘■✲✖✷✖✶✴✬❲✮✵❊❋✻✼❊❋✽✖⑧✗❁P✽✖✷⑤❁P✳✺✳✴✲✖✰✱❁❂✳✴❍❚✰✵✶✴⑩❨✲✖❊❋✰✯✶✺✻✼✶✺✽✾✮✱✬✴❖ ✩↕➲q➉▲➆✏➛❄➇◆➈➊➦☛➎❾➆▲➇➊➛P➏❛➳✒✸❆✽✖✬✡✮✱✰✵❁P❊❋✽✾✮✱✬★✸P✽➵❀✖✸◆❬➸✮✵❀✖✶❅⑧❆✸❆❁P❘❋✬q✳❸❁P✽➺❙▲✶⑥❁P✳✈❀✖❊■✶✴❉P✶✺✷➻♣⑦✰✯✶✺✬✯✮✵✰✵❊■✳✴✮✱❊■✸❆✽✖✬q✸❆✽ ✮✵❀✖✶✛❙❩✶✴❀☛❁❸❉❇❊■✸❆✰❳✸P❪✌✮✱❀✖✶✛✬✯✸P❪❫✮✚❬❴❁❂✰✵✶q❁P✽✖✷❚✮✱❀✖✶✟❪r✰✵✶✴✶✺✷✖✸P✻➼✸P❪✌✮✱❀✖✶✛✷✖✶✴✬✵❊❋⑧P✽✖✶✺✰✱✇❄❖ ❹❳❀✖✶✴✬✵✶✒❁P✰✵✶➐✰✵✶✴✬✯✮✵✰✵❊❋✳❄✮✱❊■✸❆✽✖✬✢✸❆✽q❁P❘❋❘■✸◆❬❴❁P❙✔❘❋✶➯✷✖✶✴✬✵❊■⑧❆✽✖✬✌✸❆✰✢✮✱❀✖✶❷❬✒❁◆❍✹✬✌✮✱❀✖✶➐⑧❆✸✾❁❂❘❋✬✢✳❸❁❂✽q❙▲✶✒❁❂✳✈❀✖❊❋✶❄❉❆✶✺✷❧➓ ✶❂❖➽⑧✖❖t➓①✬✱❁❂❪r✶❄✮✚❍❚✳✺✸❆✽✔✬✯✮✱✰✵❁P❊❋✽✾✮✵✬✺➓①❀☛❁P✰✯✷✔❬❴❁❂✰✵✶P➓①❑✖✰✯✸❆⑧❆✰✵❁P✻❃✻✼❊❋✽✔⑧★❘➾❁P✽✖⑧P✲☛❁P⑧❆✶✴✬✺➓①❁P✽✖✷❛✬✯✮✱❁P✽✖✷☛❁❂✰✵✷✖✬❲✮✱❀☛❁❱✮ ✻➤✲✔✬✯✮★❙▲✶✿❪r✸❆❘■❘❋✸◆❬✒✶✴✷✐❖❈❹❳❀✔✶✴❍➺❁❂❘❋✬✵✸❈❊❋✽✖✳✴❘❋✲✖✷✖✶❃⑩❨✲☛❁P❘❋❊t✮✚❍♦✰✵✶✺⑩❨✲✖❊■✰✵✶✴✻❃✶✴✽❨✮✵✬✺➓➐✬✵✲✔✳✈❀✫❁❂✬➤✻✿❁❂❊❋✽✾✮✈❁P❊■✽❇❻ ❁P❙✔❊❋❘❋❊t✮✚❍❆➓❇❁❸❉P❁❂❊❋❘➾❁❂❙✖❊❋❘■❊■✮✚❍❆➓❨✶❄✮✱✳P❖ ✩✫➚❥➈❱➎⑦➉①➈❱➎r➇◆➎⑦➜✹➛P➏❴❹❳❀✔❊❋✬✝✬✵✶✺✳❄✮✱❊■✸❆✽❈❙☛❁❂✬✵❊❋✳✺❁P❘❋❘t❍❅✬✯❑❩✶✴✳✺❊■❺✖✶✺✬❵❀✔✸➊❬✉✮✱✰✱❁❂✷✖✶✺✸P➪❩✬♠❬❲❊■❘❋❘✐❙▲✶❥✻✿❁P✷✔✶q❊t❪❷❁P❘■❘✐✸P❪ ✮✵❀✖✶❃⑧P✸✾❁P❘❋✬❥❁P✽✔✷➫✳✺✸P✽✖✬✯✮✵✰✱❁P❊■✽❨✮✵✬q✳✺❁P✽✖✽✖✸❂✮➤❙▲✶❃✳✴✸❆✻❃❑✔❘❋✶✴✮✵✶✺❘t❍⑨❁P✳✈❀✖❊■✶✴❉❆✶✴✷➵❊❋✽⑨✮✱❀✔✶❃✷✖✶✴✬✵❊■⑧❆✽✹➶↕✬✯✸❆✻✼✶ ✻❃❁❸❍❅❙▲✶❥✻✼✸❆✰✯✶✟❊❋✻✼❑❩✸❆✰✡✮✈❁P✽✾✮❴✮✵❀☛❁P✽❚✸P✮✵❀✖✶✺✰✯✬✺❖✦➹✛✲✔❊❋✷✖✶✴✬❲✮✵✰✱❁P✷✔✶✺✸P➪❩✬✝❁P✻❃✸P✽✖⑧★✷✖✶✺✬✯❊❋⑧❆✽❚✷✖✶✴✳✺❊■✬✵❊❋✸P✽✖✬✺❖ ✩✫➅✴➆❩➇◆➜❨➈➊➘➴➦☛➍❆➜✹➛✫➇◆➉➷➇◆➬✌➜➮➜✹➆❩➢☎➎r➈➊➉❩➆✌➝➫➜✹➆❩➇✾➏❞➱✚✽✖❑✖✲✔✮❛✸❆✰❚✸❆✲✔✮✵❑✖✲✔✮❛❊❋✽✾✮✵✶✺✰✯❪⑦❁❂✳✺✶✺✬❛❁P✽✔✷➻✰✯✶✺❘❋✶❄❉❂❁P✽✾✮ ❁P✬✯✬✵✲✖✻✼❑✔✮✵❊❋✸❆✽✖✬♠❁P❙▲✸❆✲✔✮✝✶✺✽✾❉✹❊❋✰✯✸❆✽✖✻✼✶✺✽✾✮✈❁❂❘✌✳✴✸❆✻✼❑❩✸❆✽✔✶✺✽✾✮✱✬✝❬❲❊■✮✱❀❚❬❲❀✖❊■✳✈❀❈✮✱❀✖✶❥✬✵✸❂❪❫✮✚❬❴❁P✰✯✶q❬❲❊■❘❋❘✢❙▲✶ ❊■✽❨✮✵✶✺✰✵❁P✳✴✮✵❊❋✽✖⑧✖❖ ✩↕➥⑥➠⑦➉▲➛❸➛✺➦✔➈➊➙➯➏❳❝❜✶✴❺☛✽✔❊■✮✱❊■✸❆✽✖✬❳✸P❪✌✮✱✶✴✳✈❀✖✽✖❊■✳❸❁P❘✐✮✵✶✺✰✵✻✼✬❲✲✖✬✵✶✴✷⑤❊■✽⑥✮✱❀✖✶✛✷✖✸✹✳✺✲✖✻✼✶✺✽✾✮✺❖ ✩✫➅✴➆✏➋☎➜✾✃✢➜✹➛P➏❴❐➃❁P✰✯❊❋✸❆✲✖✬❴✮✚❍✹❑▲✶✺✬✝✸P❪✏❊❋✽✖✷✖✶❼❏❇✶✺✬✝✻✿❁❸❍❅❙▲✶✛❑✖✰✵✸◆❉✹❊❋✷✔✶✺✷✐❖ ❒
Attributes of a good requirements do cument Reada ble and understandable by customers, users, and designers Specifies only external system behavior(black box) Structured to be easy to change Specifies both goals and constraints able to serve as a reference tool for system maintainers Contains only testa ble requirements An untestable requirement: The system should be easy to use by experi enced controllers and should be organized in such a way that user errors are minimized a testable requirement: Experienced controllers should be a ble to use all of the system functions after a total of two hours training. After this training the average number of errors made by experienced users should not exceed two per day. Consistent, complete, unambiguous, and realistic Specifies acceptable responses to undesired events Specifies incremental subsets if desired or minimum and maximum functionality Specifies the changes anticipated in the future (in the environment or in the software
❮✑✹✑✖✠①✞✡❰✟✆♠✑✔✁✌✓❞✤✦➂❚✜→③➃✤✝✤❲➄Ï✠☛✁☎✄✝✆✟✞✡✠☛✁✌☞✍✁✌✎❴✑✔✓▼➄✟✤❲✘☎✆✟☞✍✁✏✎✒✑✐✧ ✩❞Ð❲✶❸❁P✷✖❁P❙✖❘❋✶✛❁❂✽✖✷⑤✲✔✽✖✷✖✶✺✰✯✬✯✮✱❁P✽✖✷☛❁P❙✔❘❋✶✛❙✾❍⑥✳✺✲✖✬✡✮✱✸❆✻✼✶✺✰✯✬✺➓①✲✖✬✯✶✺✰✵✬✴➓▲❁P✽✖✷❛✷✖✶✺✬✯❊❋⑧❆✽✖✶✴✰✵✬✴❖ ✩▼◗❇❑▲✶✺✳✴❊■❺☛✶✴✬❲✸❆✽✖❘■❍✿✶❄❏✹✮✱✶✴✰✵✽☛❁❂❘✌✬✡❍✹✬✯✮✱✶✴✻❭❙❩✶✴❀☛❁❸❉❇❊■✸❆✰❥♣⑦❙✔❘➾❁P✳✈Ñ❅❙▲✸❸❏✖✇❄❖ ✩▼◗✹✮✵✰✵✲✖✳❄✮✱✲✖✰✯✶✺✷❛✮✱✸❯❙❩✶✛✶✺❁P✬✯❍❅✮✵✸❯✳✈❀☛❁P✽✖⑧❆✶❂❖ ✩▼◗❇❑▲✶✺✳✴❊■❺☛✶✴✬❲❙❩✸P✮✵❀⑤⑧P✸✾❁P❘❋✬❴❁P✽✖✷❛✳✺✸❆✽✖✬✡✮✱✰✵❁P❊❋✽✾✮✱✬✴❖ ✩✫✪♠❙✖❘❋✶❜✮✵✸✼✬✯✶✺✰✡❉❆✶➤❁❂✬♠❁★✰✯✶✴❪r✶✺✰✯✶✺✽✖✳✴✶❥✮✵✸❇✸P❘❧❪r✸❆✰❳✬✯❍✹✬✡✮✱✶✺✻❦✻❃❁P❊■✽❨✮✱❁P❊❋✽✔✶✺✰✵✬✴❖ ✩▼➳✒✸❆✽✾✮✱❁P❊❋✽✖✬❲✸❆✽✔❘■❍✿✮✵✶✺✬✡✮✈❁P❙✖❘■✶✟✰✵✶✴⑩✹✲✔❊❋✰✵✶✴✻❃✶✴✽✾✮✱✬✺❖ Ò❵Ó➺Ô✹Ó Ô✹Û Ó ❤✚Õ✈Ö❄❤➴❣✾×✺Ø❋Õ❯Ù✱Õ✵Ú Ù✱Õ❄Ü✿Õ ❤➴Ý✛❹❳❀✖✶❃✬✡❍✹✬✯✮✱✶✴✻④✬✵❀✖✸❆✲✔❘❋✷⑨❙❩✶❯✶✺❁P✬✯❍➒✮✵✸❛✲✔✬✵✶✼❙❨❍●✶❄❏❇❑❩✶✴✰✵❊Þ❻ ✶✴✽✖✳✺✶✴✷➫✳✴✸❆✽✾✮✱✰✵✸P❘❋❘❋✶✴✰✵✬❵❁P✽✖✷⑨✬✵❀✖✸P✲✖❘❋✷⑨❙▲✶★✸❆✰✵⑧✾❁❂✽✖❊❋➣✴✶✺✷➒❊❋✽➒✬✯✲✖✳✈❀❽❁⑥❬✒❁❸❍❈✮✵❀☛❁❂✮✛✲✖✬✯✶✺✰✛✶✺✰✯✰✵✸❆✰✯✬ ❁❂✰✵✶✛✻❃❊■✽✖❊❋✻✼❊❋➣✴✶✺✷✐❖ Ò Ô✹Û Ó ❤✚Õ✈Ö❄❤➴❣✾×✺Ø❋Õ❲Ù✱Õ✵Ú Ù✱Õ❄Ü✿Õ ❤➴Ý➯ß✣❏❇❑❩✶✴✰✵❊■✶✺✽✖✳✴✶✺✷✼✳✺✸❆✽✾✮✱✰✯✸❆❘❋❘■✶✺✰✯✬➯✬✵❀✖✸P✲✖❘❋✷❯❙▲✶❳❁P❙✖❘■✶✒✮✱✸✟✲✖✬✯✶✝❁P❘❋❘✹✸P❪ ✮✵❀✖✶✒✬✡❍✹✬✯✮✱✶✴✻à❪r✲✖✽✔✳✴✮✱❊■✸❆✽✖✬✏❁❂❪❫✮✱✶✴✰➯❁❲✮✱✸P✮✱❁P❘❨✸P❪✖✮✚❬✦✸❜❀✖✸❆✲✖✰✯✬✏✮✵✰✱❁P❊■✽✖❊❋✽✖⑧✔❖✌✪✝❪❫✮✱✶✴✰✏✮✱❀✔❊❋✬☎✮✱✰✱❁❂❊❋✽✖❊■✽✖⑧✖➓ ✮✵❀✖✶♠❁◆❉P✶✺✰✵❁P⑧❆✶❲✽❨✲✖✻➤❙▲✶✺✰➃✸P❪❧✶✴✰✵✰✯✸❆✰✵✬➐✻❃❁P✷✖✶❳❙✾❍❯✶❄❏❇❑▲✶✺✰✵❊■✶✺✽✖✳✴✶✺✷❃✲✖✬✵✶✴✰✵✬✒✬✯❀✖✸❆✲✖❘■✷❯✽✖✸P✮➃✶❄❏❇✳✺✶✴✶✺✷ ✮✚❬✦✸✿❑▲✶✺✰❳✷✖❁◆❍P❖ ✩▼➳✒✸❆✽✔✬✵❊❋✬✡✮✱✶✴✽❨✮✺➓①✳✺✸❆✻✼❑✖❘❋✶❄✮✱✶❂➓✖✲✖✽☛❁P✻✗❙✖❊❋⑧❆✲✔✸❆✲✖✬✺➓✖❁P✽✖✷❚✰✵✶✺❁P❘❋❊■✬✯✮✱❊■✳P❖ ✩▼◗❇❑▲✶✺✳✴❊■❺☛✶✴✬✝❁P✳✺✳✴✶✺❑✔✮✱❁P❙✖❘❋✶✛✰✯✶✺✬✵❑▲✸❆✽✖✬✯✶✺✬✝✮✱✸❯✲✖✽✖✷✖✶✴✬✵❊■✰✵✶✺✷❛✶✴❉P✶✺✽✾✮✱✬✴❖ ✩▼◗❇❑▲✶✺✳✴❊■❺☛✶✴✬✏❊■✽✖✳✺✰✯✶✺✻✼✶✺✽✾✮✈❁❂❘✾✬✵✲✖❙✖✬✯✶✴✮✵✬➯❊■❪❇✷✖✶✺✬✯❊❋✰✯✶✺✷✗✸P✰✌✻✼❊❋✽✔❊❋✻➤✲✖✻➻❁P✽✖✷q✻✿❁➊❏✔❊■✻➤✲✖✻á❪r✲✖✽✖✳✴✮✵❊❋✸❆✽✖❁P❘❋❊t✮✚❍❆❖ ✩▼◗❇❑▲✶✺✳✴❊■❺☛✶✴✬➤✮✱❀✖✶⑥✳✈❀✖❁P✽✖⑧❆✶✴✬❃❁❂✽❨✮✵❊❋✳✴❊❋❑☛❁❂✮✵✶✺✷➵❊■✽➵✮✱❀✖✶❅❪r✲❇✮✱✲✖✰✯✶♦♣⑦❊❋✽❽✮✱❀✖✶⑥✶✴✽❨❉✹❊■✰✵✸❆✽✖✻✼✶✺✽✾✮❯✸❆✰✗❊❋✽➵✮✱❀✔✶ ✬✯✸P❪❫✮✚❬❴❁❂✰✵✶◆✇❼❖ â
Ensuring a Successful Product Right product Product Right Appropriate and llocated Successful Producibility Production r Validated Requirements Requirements Constraints Certification Requirements Verification Accidents Physical and Incidents Functional def Airline Market Driven Detailed Industry Requirements Lessons Analyze and Design Learned Validate Boer Requirements FHA Resolution infrastructure Prelimin FMEA Safety Reliability In-service Requirements Experience Maintainability Groundside and atc
Producibility Constraints Production Requirements In-service Experience Resolution Issue Lessons Learned Accidents Incidents and Technology Changes Market Driven Requirements Airline Industry Trends Requirements Customer Public Perceptions Regulatory Requirements Political World Airports and Groundside Requirements Airspace and ATC Requirements Infrastructure Requirements Boeing Ensuring a Successful Product Right Product Appropriate and Validated Requirements ã Allocated Requirements FHA Trees Fault FMEA Preliminary Validate Analyze and Compliance Requirements Testing Verification Certification Product Successful Design Detailed Safety Reliability Availability Maintainability Supportability Analyses Physical and Preliminary Functional Def. Product Right
Types of Specifications Informal Free form natural language Ambiguity and lack of organization can lead to incompleteness, inconsistency, and misunderstandings Formatted Standardized syntax(e.g, UML Basic consistency and completeness checkS Imprecise semantics implies other sources of error may still be present Copyright Nancy Leveson, Sept1999
Types of Specifications Informal Free form, natural language Ambiguity and lack of organization can lead to incompleteness, inconsistency, and misunderstandings Formatted Standardized syntax (e.g., UML) Basic consistency and completeness checks Imprecise semantics implies other sources of error may still be present. c Copyright Nancy Leveson, Sept. 1999 ä
Intent Specifications Part-Whole Refinement Verification Environment Operator System Validation Syste Purpose System Design Principles Intent Blackbox Behavior Des Representation Physical Representation Operations Each level supports a different type of reasoning about system Mappings between levels provide relational info necessary to reason across hierarchical levels
Intent Specifications Part-Whole Blackbox Behavior Physical Representation Principles System Design Purpose System Design Representation Environment Operator System Verification Validation Refinement Operations Intent Each level supports a different type of reasoning about system. Mappings between levels provide relational info necessary to reason across hierarchical levels. å
ypes of specifications(2 Formal Syntax and semantics rigorously defined Precise form, perhaps mathematica Eliminate imprecision and ambiguity Provide basis for mathematically verifying equivalence between specification and implementation May be hard to read without training Semantic distance too great? Copyright Nancy Leveson, Sept 1999
Types of Specifications (2) Formal Syntax and semantics rigorously defined. Precise form, perhaps mathematical. Eliminate imprecision and ambiguity. Provide basis for mathematically verifying equivalence between specification and implementation. May be hard to read without training. Semantic distance too great? c Copyright Nancy Leveson, Sept. 1999 æ
INPUT SPACE OUTPUT SPACE F O F()=O A program is a mathematical object A programming language is a mathematical language Therefore, we can prove properties about the program e.g. does it do what it is supposed to do does it not do anything harmful Building a model like engineers do, but need discrete rather than continuous mathematics eson, Sept. 1999
INPUT SPACE OUTPUT SPACE I F O F(I) = O A program is a mathematical object A programming language is a mathematical language. Therefore, we can prove properties about the program. e.g. does it do what it is supposed to do does it not do anything harmful Building a model like engineers do, but need discrete rather than continuous mathematics. Copyright Nancy Leveson, Sept. 1999 c ç
Formal Specifications Goal: Describe external behavior without describing or constraining internal design(implementation) Formal method has 2 parts Logical theory: means by which reason about specs properties, and programs First-order predicate calculus(quantification over variables Second-order predicate calculus(quantification over relations Temporal logic 2. Structuring theory: defines elements being reasoned about Copyright Nancy Leveson, Sept 1999
Formal Specifications Goal: Describe external behavior without describing or constraining internal design (implementation). Formal method has 2 parts: 1. Logical theory: means by which reason about specs, properties, and programs. First-order predicate calculus (quantification over variables) Second-order predicate calculus (quantification over relations) Temporal logic 2. Structuring theory: defines elements being reasoned about c Copyright Nancy Leveson, Sept. 1999 è
Structuring Theory Descriptive specifications State desired properties in a purely declarative way Input-output assertions Algebraic specifications(set of axioms) 2. Operational Specification: Describe desired behavior by providing a model of system Abstract Model(in terms of previously defined mathematical objects, e.g., sets and sequences operations, e.g., functions and mappings State machine(states and transitions between states) Copyright Nancy Leveson, Sept. 1999
Structuring Theory 1. Descriptive Specifications: State desired properties in a purely declarative way. Input-output assertions Algebraic specifications (set of axioms) 2. Operational Specification: Describe desired behavior by providing a model of system. Abstract Model (in terms of previously defined mathematical objects, e.g., sets and sequences operations, e.g., functions and mappings) State machine (states and transitions between states) Copyright Nancy Leveson, Sept. 1999 c ➀◆é