Requirements Requirements Specification A structured document that sets

Requirements

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. Needs to be understandable by both. • Describes what the system will do but not how it will do it (objectives but not how objectives will be achieved).

Design Specification • An abstract description of the system that serves as a basis for (describes) detailed design and implementation. • Describes how the requirements will be achieved. • Primary readers will be system implementers rather than users or management. • Goals and constraints specified in requirements document should be traceable to the design specification (and from there to the code).

Some Contents of Requirements Documents • Introduction: Describes the need for the system and places it in context, briefly describing its external functions (objective) and presenting a rationale for its existence. Describes how the system fits into the overall business or strategic objectives of the organization commissioning the system. • System Goals: Informal statement of specific goals to be achieved by the system. • System Constraints: Constraints on how the goals can be achieved (restrictions on behavior of the system and freedom of designer), e. g. , safety, hardware, programming languages, standards that must be followed. Includes quality requirements such as maintanability, availability, etc. • Interfaces to the environment: System boundary, inputs, outputs

Some Contents of Requirements Documents (2) • Functional Requirements: “Shall statements. ” The services provided for the user. Includes timing and accuracy requirements. • Priorities: Guides tradeoffs and design decisions if all requirements and constraints cannot be completely achieved. • System Models: Shows the relationships between the system components and the system and its environment. • System Evolution: Fundamental assumptions about anticipated changes due to hardware evolution, changing user needs, etc. • System Models: System-level models of black-box (design-free) behavior of system. May include multiple views of system behavior. • Glossary: Definitions of technical terms used in the document. • Others?

Attributes of a Good Requirements Document • Readable and understandable by customers, users, stakeholders and developers (designers) • Specifies only external (black box) system behavior • Structured to be easy to change • Specifies both goals and constraints • Able to serve as a reference for system maintainers • Includes assumptions and rationale for contents when appropriate • Consistent, complete, unambiguous, realistic, and testable • Specifies acceptable responses to undesired events • Specifies what should not do as well as what should do • Specifies incremental subsets if desired or minimum and maximum functionality • Specifies changes anticipated in the future (both for environment and system)

Requirements Must be Testable An untestable requirement: The system shall be easy to use by experience controllers and shall be organized in such a way that user errors are minimized. A testable requirement: Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

Developing Good Requirements Very Difficult

Types of Specifications (Requirements and Design) • Informal – Free form, natural language – Ambiguity and lack of organization can lead to incompleteness, inconsistency, and misunderstanding • Formatted – Standardized syntax – Basic consistency and completeness checks (although limited) – Imprecise semantics implies other sources of error may be present • Formal – Syntax and semantics rigorously defined – Precise form, perhaps mathematical – Eliminates imprecision and ambiguity, but may be hard to read without extensive training – Potentially provides basis for mathematically verifying equivalence between specification and implementation – Semantic distance too great?

Argument for Formal Specifications • A program (software) is a mathematical object • A programming language is a mathematical language • Therefore, we can prove properties about the program – Such as 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

Input-Output Assertions (Pre and Post Conditions) Where [Logical “AND”] [Logical “OR”] F(i) [For all i that are a member of the set {. . }, F(i) is true]

Abstract Model Specifications • Build an abstract model of required software behavior using mathematically defined (perhaps using axioms) types (e. g. , sets, relations) • Define operations by showing effects of that operation on the model • Specification includes: – Model – Invariant properties of that model – For each operation: name parameters return values – Pre and pot conditions on the operations

Example: Z (pronounced Zed) • Z specifications are made up of “schemas” • A schema is a named, relatively short piece of specification with two parts: – Above the line: the definition of the data entities – Below the line: the definition of the invariants that hold on those data entities

Z: Defining the Abstract Model

Z: Defining Operations

Z: Proving Properties

Finite State Machines (Automata) • A mathematical model of computation • An abstract machine that can be in exactly one of a finite number of states at any given time. • Changes from state to state (called a transition) in response to inputs. • Define the FSM by listing states, initial state, and inputs that trigger each transition.

Example of a State Machine Model

Another Example State Machine

Intent Specifications • Human-centered specification – Integrates concepts in • Human factors • System engineering/systems theory • Cognitive psychology (how experts solve problems) – Goal is for specs to support human problem solving • Information needed easy to find • Enhance communication and expert review • Document assumptions, design rationale • Traceability to support – V&V – Change and upgrade process • Do not enforce a specific process

Different Roles Require Different Views of System Why

Example of Potential Contents

Level 1 (Customer View) Examples

Functional Goals and Requirements

Level 1 Safety Constraints and Requirements

Level 1 Safety Constraints and Requirements (2)

Level 3 Interface Between System Engineering and Component Engineering • Allocate functionality to components • Place where formal specifications (model) might be useful but must be readable and reviewable: Minimize semantic distance Minimal: blackbox behavior only (transfer function) Easy to learn Unambiguous and simple semantics Visualization tools (executable, can act as prototype, animation) Complete (can specify everything need to specify) Analyzable (formal, mathematical foundation using propositional logic in disjoint normal form), e. g. tools to check completeness, consistency, nondeterminism – Includes human operator procedures and analysis – – – –

Spec. TRM-RL • Combined requirements specification and modeling language • A state machine (formal logic) with a domain-specific notation on top of it – Includes a task modeling language – Can add other notations and visualizations of state machines • Enforces or includes most of our completeness criteria My students insisted that formal specifications (pre and post conditions) were usable so I let them try it. That failed so then I took over.

Overall Visual Graphic of System

Spec. TRM-RL Model of HETE Attitude Control System

Example of “Formal” Description of Logic

Additional Non-Formal but Necessary Information

Types of Analysis Possible on Spec. TRM-RL Specs • Model execution, animation, and visualization (can act as a executable prototype) • Completeness • Hazard Analysis • Human Task Analysis • Test coverage analysis and test case generation • Automatic code generation

Object vs. Control Specifications • For human processing, specification format should match problem structure (semantic distance) Control-Oriented Start by defining functions needed Object-Oriented Start by defining objects involved and operations on those objects Control specification: indicates (1) how software/system behaves when an event or control signal is sensed and (2) which processes are invoked as a consequence of occurrence of the event. Sometimes use state machines and a state transition diagram.

Situation Today • Computer science has convinced everyone that only objectoriented specs are useful or “good. ” • Advantages of having one specification language for everything: – Learning problems reduced – Tool developers make much larger profits and have more potential customers – Decision making about what language to use is eliminated • Disadvantages: – Has led to optimization on object-oriented problems but big problems in control-oriented programs – Inhibits problem-solving abilities of users for different type of problems (“semantic distance” maximized almost to point of being impossible) – MBSE potential limited (e. g. , limited types of analysis possible) – Have standardized with one old specification language and any progress, even in object-oriented languages, has stopped

Readings and Thoughts • Lawrence, Wiegers, Ebert: The Top Risks of Requirements Engineering • Leishman and Cook, Requirements Risks Can Drown Software Projects • Wing, A Specifier's Introduction to Formal Methods (This one may be tough reading for some of you -- you can skim it if you are feeling overwhelmed by the discrete math) • Leveson, Intent Specifications

Takeaways • Requirements act as a contract between procurer and developer. Needs to be understandable by both. • Different people (roles) need different views (models) of a system – Not just refinements of same model – MBSE provides only one model to do everything – Models must be consistent and traceable between them. • Specification of underlying assumptions and rationale for decisions must be documented and in way information can be easily located when needed. Need to document “why” somehow. • Semantic distance (“intuitive”) affects understanding. • Specification format and contents affect ability to solve problems • Use models and specification languages that match problem to be solved (type of system being designed)