EĞİTİMİN AMACI
Bu iki buçuk günlük eğitim, gereksinimlerin nasıl toplanacağı, yazılacağı, doğrulanacağı ve organize edileceğine ilişkin bir dizi önerilen uygulamayı sunmaktadır. Çeşitli yaklaşımlardan en iyi fikirleri bir araya getirmeye, bunları tutarlı bir bütün halinde düzenlemeye ve faydalarını netleştiren somut örneklerle açıklamaya çalışır. Sunumlar, FAA Gereksinim Mühendisliği El Kitabından (DOT/FAA/AR-08/32) bazı bilgiler kullanır, ancak yalnızca bu el kitabıyla sınırlı değildir.
Gereksinim mühendisliği ile ilgili literatür çok geniştir ve uygulamalar belirli bir endüstride bile büyük farklılıklar gösterir. Bu nedenle El Kitabı, gerçek zamanlı, gömülü sistemler alanına ve özellikle aviyonik endüstrisine yöneliktir. Bu sistemlerde yazılımın hızla artan önemi nedeniyle, sistemden yazılım gereksinimlerine geçişi kolaylaştıran uygulamaları vurgulamaktadır.
Ana düzeyde önerilen uygulamalar, kabaca bir program üzerinde gerçekleştirilecekleri sırayla sunulmuştur, ancak bu sıraya tam olarak uyulması gerekliliği yoktur.
Çoğu süreçte olduğu gibi, gereksinimler iyileştirildikçe farklı etkinlikler arasında önemli yinelemelerin olması beklenir. El Kitabı, ayrıntılı bir süreç belirlemeye çalışmak yerine, bir gereksinim belirtiminde hangi bilgilere ihtiyaç duyulduğunu belirlemeye ve bu bilgilerin nasıl toplanıp düzenlenebileceğine ilişkin öneriler sunmaya odaklanır.
EĞİTİMİN KAPSAMI
FAA El Kitabı, gerçek zamanlı gömülü sistemler alanını ve özellikle aviyonik endüstrisini ele almaktadır. Temel kavramların ayrı ayrı uygulanabileceği ancak bir bütün olarak uygulandığında birbirini güçlendirdiği bir dizi önerilen uygulama tanımlar. Bu uygulamalar, geliştiricilerin bir sistemin ilk, üst düzey genel bakışından, davranışının ve performans gereksinimlerinin ayrıntılı bir açıklamasına ilerlemesine olanak tanır. Aviyonik sistemlerde yazılımın artan önemi nedeniyle, bu uygulamalar sistem gereksinimlerinden yazılım gereksinimlerine geçişi kolaylaştıran teknikleri öne çıkarmaktadır.
Kavramları açıklığa kavuşturmak için El Kitabı boyunca somut örnekler kullanılmıştır, ancak aynı hedeflere ulaşmak için kullanılabilecek başka birçok format vardır. Bu uygulamaları kullanmak isteyen çoğu kuruluşun, bunları mevcut süreçleri ve araçlarıyla entegre etmek için belki de önemli ölçüde değiştirmek istemesi beklenmektedir.
Eğitim, gerçek zamanlı gömülü sistemler alanına ve özellikle aviyonik endüstrisine yöneliktir. Temel kavramların ayrı ayrı uygulanabileceği ancak bir bütün olarak uygulandığında birbirini güçlendirdiği bir dizi önerilen uygulama tanımlar. Bu uygulamalar, geliştiricilerin bir sistemin ilk, üst düzey genel bakışından, davranışının ve performans gereksinimlerinin ayrıntılı bir açıklamasına ilerlemesine olanak tanır. Aviyonik sistemlerde yazılımın artan önemi nedeniyle, bu uygulamalar sistem gereksinimlerinden yazılım gereksinimlerine geçişi kolaylaştıran teknikleri öne çıkarmaktadır.
EĞİTİMİN DETAYLI İÇERİĞİ
2.5 günlük eğitim boyunca aşağıda sıralanmış olan konular ele alınmaktadır:
- INTRODUCTION
- Purpose
- Background
- RECOMMENDED PRACTICES
- Developing the System Overview
- Develop System Overview Early
- Provide System Synopsis
- Identify System Contexts
- Use Context Diagrams
- Describe External Entities
- Capture Preliminary System Goals
- Maintain System Goal Information
- Identify the System Boundary
- Identify the System Boundary Early
- Choose Environmental Variables
- Choose Controlled Variables
- Choose Monitored Variables
- Ensure Environmental Variables are Sufficiently Abstract
- Avoid Presentation Details in Environmental Variables
- Define All Physical Interfaces
- Develop the Operational Concepts
- Document Sunny Day System Behavior
- Include How the System is Used in its Operating Environment
- Employ the Use Case Goal as its Title
- Trace Each Use Case to System Goals
- Identify Primary Actor, Preconditions, and Postconditions
- Ensure Each Use Case Describes a Dialogue
- Link Use Case Steps to System Functions
- Consolidate Repeated Actions Into a Single Use Case
- Describe Exceptional Situations as Exception Cases
- Describe Alternate Ways to Satisfy Postconditions as Alternate Courses
- Use Names of External Entities or Environmental Variables
- Avoid Operator Interface Details
- Update the System Boundary
- Assemble a Preliminary Set of System Functions
- Identify the Environmental Assumptions
- Define the Type, Range, Precision, and Units
- Provide Rationale for the Assumptions
- Organize Assumptions Constraining a Single Entity
- Organize Assumptions Constraining Several Entities
- Define a Status Attribute for Each Monitored Variable
- Summary
- Develop the Functional Architecture
- Organize System Functions Into Related Groups
- Use Data Flow Diagrams to Depict System Functions
- Minimize Dependencies Between Functions
- Define Internal Variables
- Nest Functions and Data Dependencies for Large
- Developing the System Overview
Specifications
- Provide High-Level Requirements That are Really High Level
- Do Not Incorporate Rationale Into the Requirements
- Revise the Architecture to Meet Implementation Constraints
- Modify the Architecture to Meet Implementation
Constraints
- Keep Final System Architecture Close to Ideal Functional Architecture
- Revise the System Overview
- Revise the Operational Concepts
- Develop Exception Cases
- Link Exception Cases to Use Cases
- Revise the System Boundary
- Document Changes to Environmental Assumptions
- Revise Dependency Diagrams
- Revise High-Level Requirements
- Identify the System Modes
- Identify Major System Modes
- Define How System Transitions Between Modes
- Introduce Modes for Externally Visible Discontinuities
- Develop the Detailed Behavior and Performance Requirements
- Specify the Behavior of Each Controlled Variable
- Specify the Requirement as a Condition and an Assigned Value
- Ensure That Detailed Requirements are Complete
- Ensure That Detailed Requirements are Consistent
- Ensure That Detailed Requirements are not Duplicated
- Organize the Requirements
- Define Acceptable Latency for Each Controlled Variable
- Define Acceptable Tolerance for Each Controlled Variable
- Do Not Define Latency and Tolerance for Internal Variables
- Alternative Ways to Specify Requirements
- Define the Software Requirements
- Specify the Input Variables
- Specify the Accuracy of Each Input Variable
- Specify the Latency of Each Input Variable
- Specify IN’ for Each Monitored Variable
- Specify the Status of Each Monitored Variable
- Flag Design Decisions as Derived Requirements
- Specify the Output Variables
- Specify the Latency of Each Output Variable
- Specify the Accuracy of Each Output Variable
- Specify OUT’ for Each Controlled Variable
- Confirm Overall Latency and Accuracy
- Allocate System Requirements to Subsystems
- Identify Subsystem Functions
- Duplicate Overlapping System to Subsystem Functions
- Develop a System Overview for Each Subsystem
- Identify the Subsystem Monitored and Controlled Variables
- Create New Monitored and Controlled Variables
- Specify the Subsystem Operational Concepts
- Identify Subsystem Environmental Assumptions Shared With ParentSystem
- Identify Environmental Assumptions of the New Monitored andControlled Variables
- Complete the Subsystem Requirements Specification
- Ensure Latencies and Tolerances are Consistent
- Provide Rationale
- Provide Rationale to Explain why a Requirement Exists
- Avoid Specifying Requirements in the Rationale
- Provide Rationale When the Reason a Requirement is not Obvious
- Provide Rationale for Environmental Assumptions
- Provide Rationale for Values and Ranges
- Keep Rationale Short and Relevant
- Capture Rationale as Soon as Possible
- SUMMARY 4. REFERENCES APPENDICES
A—Isolette Thermostat Example
B—Flight Control System Example
C—Flight Guidance System Example
D—Autopilot Example