Software Engineering

system test
Development costs are only the tip of the iceberg.

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.

as a basis for (or describes) detailed design and implementation

Describes how the requirements will be achieved.
Primary readers will be software designers and 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.

Environment
Glossary

system and places it in context, briefly describing its functions

and presenting a rationale for the software. Describes how the system fits into the overall business or strategic objectives of the organization commissioning the software.
System Model
System Evolution
Functional Requirements
Constraints
Priorities
Interfaces to the Environment
Glossary

between the system components and the system and its environment.

An abstract data model should also be described if appropriate to the type of system.
System Evolution
Functional Requirements
Constraints
Priorities
Interfaces to the Environment
Glossary

which the system is based and anticipated changes due to

hardware evolution, changing user needs, etc.
Functional Requirements
Constraints
Priorities
Interfaces to the Environment
Glossary

provided for the user. This includes timing and accuracy requirements.
Constraints
Priorities
Interfaces

to the Environment
Glossary

how the goals can be achieved (restrictions on behavior of

software and freedom of designer), e.g., safety, hardware, programming languages, standards that must be followed. Includes quality requirements such as maintainability, availability, etc.
Priorities
Interfaces to the Environment
Glossary

and design decisions if all requirements and constraints cannot be

completely achieved.
Interfaces to the Environment
Glossary

Environment: Input or output interfaces and relevant assumptions about environmental

components with which the software will be interacting.
Glossary

Environment
Glossary: Definitions of technical terms used in the document

customers, users, and designers.
Specifies only external system behavior (black

box)
Structured to be easy to change.
Specifies both goals and constraints.
Able to serves as a reference for system maintainers.
Consistent, complete, unambiguous, realistic, and testable
Specified acceptable responses to undesired events.
Specifies what should not do as well as what should do.
Specified incremental subsets if desried or minimum and maximum functionality
Specifies changes anticipated in the future (for both environment and software)

be easy to use by experienced 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.

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.
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?

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 model
For each operation:
name
parameters
return values
Pre and post conditions on the operations

in which interacts
Assumptions about environment
EA−1: Altitude information is available from

intruders with minimum precision of 100 feet
EA−2: All aircraft will have legal identification numbers
Level 1: Operator
Pilot Responsibilities and Tasks
Operator requirements
OP−5: TCAS advisories shall be executed in such a way as to minimize the aircraft’s deviation from it’s ATC clearance
Human−Machine Interface Requirements
HMI−3: A red visual alert shall be provided in the primary field of view for each pilot for resolution advisories.

its structure
Capture domain knowledge (reusable architectures)
Provides traceability from high−level requirements

to detailed design and code.
Blackbox models at Level 3
Executable and analyzable e.g., completeness, robustness, mode confusion, hazard analysis, test case generation, code generation
Specification acts as an executable prototype
Can interface with system simulation
Visualization tools
Interface to contractors

classroom 5-214
or
e-mail: eart@ukr.net