IEEE

Methodology for developing Use Cases for large systems

WARNING: Date published: UNKNOWN
Attachment(s)
FileSize (KB)MIME typeLanguage
Use Cases for Large Systems uc.pdf206.64application/pdfEnglishDOWNLOAD!

Step 1: Define the system boundary

"A journey of a thousand miles begins with a single step" - Though it may be
tempting to jump in and start modeling the use cases right off, it is very important to
make the appropriate preparations and decisions before you begin.
The first thing to do is establish an early vision of the system (which will be updated
later as we gain more understanding of the system). This is an important step since the
vision captures the essence of the requirements (the fundamental "why's and what's" ... read more

More Fun than A Barrel of Monkeys

Attachment(s)
FileSize (KB)MIME typeLanguage
More Fun Incose.pdf368.96application/pdfEnglishDOWNLOAD!

The sections on Risk Management and on Metrics are particularly good. But they are quite exhaustive, some might say heavy-handed, so you need to skim over to section 5 which starts to talk about tailoring the SE processes to the needs of the project and the effort available. I hesitate to suggest that the Handbook be made bigger, but it could do with more detail here! ... read more

President’s Corner

Attachment(s)
FileSize (KB)MIME typeLanguage
President's Coner Incose.pdf635.28application/pdfEnglishDOWNLOAD!

Over the last two or three years, there have been a small
number of papers published in the INCOSE literature on
the topic of ‘System of Systems’. All sorts of questions
have been raised about the management of interfaces,
the partitioning of risk between customer and prime
contractor, and the sharing of risk (and trade against
sharing of profit) between partners in prime contracting
consortia, or between nationalities and workshare in a
single company.

I ask myself here – what constitutes
‘good’ systems engineering in this context, and who is ... read more

Fame At Last!

Attachment(s)
FileSize (KB)MIME typeLanguage
Fame At Last.pdf755.9application/pdfEnglishDOWNLOAD!

Magnificent Maldon ? Classic Colchester, Wonderful Whitham, or Traditional Tiptree -where the jam comes from! Doesn't have the same ring does it but there is plenty to do especially in the middle of May. The hotel itself is set in 320 acres and combines extensive leisure, health, beauty, and sporting activities. However if you wish to make a weekend out of it as well as an educational experience there are many opportunities in the area. Interact with the elephants in Colchester Zoo, steam over to the East Anglian Railway museum, enjoy the blooms at Hyde Hall the nearby RHS garden. ... read more

Fame At Last!

Attachment(s)
FileSize (KB)MIME typeLanguage
Fame At Last.pdf755.9application/pdfEnglishDOWNLOAD!

Magnificent Maldon ? Classic Colchester, Wonderful Whitham, or Traditional Tiptree -where the jam comes from! Doesn't have the same ring does it but there is plenty to do especially in the middle of May. The hotel itself is set in 320 acres and combines extensive leisure, health, beauty, and sporting activities. However if you wish to make a weekend out of it as well as an educational experience there are many opportunities in the area. Interact with the elephants in Colchester Zoo, steam over to the East Anglian Railway museum, enjoy the blooms at Hyde Hall the nearby RHS garden. ... read more

Systems Engineering Advancement Research Initiative

Attachment(s)
FileSize (KB)MIME typeLanguage
SEAri-Research-Bulletin-v2n1.pdf557.37application/pdfEnglishDOWNLOAD!

Engineering Systems

As the operational environment of engineering systems
has become increasingly characterized by disturbances
which asymmetrically degrade performance, so too has
the need for system engineering methodologies that
assure system success in the presence of hostile
environments. Fulfillment of this need is further
complicated by the emergence of networked systems
that, while often geographically distributed, are
interdependent and often exhibit nonlinear failure
modes. Examples of impulse events triggering
catastrophic losses include the tragic events and ... read more

The Role of Requirements Traceability in System Development

Attachment(s)
FileSize (KB)MIME typeLanguage
TraceabilitySep02.pdf196.85application/pdfEnglishDOWNLOAD!

Historical safety data has demonstrated that projects often miss or do not address requirements and/or the impact of change, and that small changes to a system can create significant safety and reliability problems. This has caused some regulatory agencies to mandate that traceability be an integral part of the development process.

For example, the latest U.S. Food and Drug Administration (FDA) guidance for traceability in medical ... read more

Bidirectional Requirements Traceability

WARNING: Date published: UNKNOWN
Attachment(s)
FileSize (KB)MIME typeLanguage
Bidirectional Requirements Traceability.pdf66.17application/pdfEnglishDOWNLOAD!

Backwards traceability helps ensure that the evolving product remains on the correct track with regards to the original and/or evolving requirements (that we are building the product right). The objective is to ensure that we are not expanding the scope of the project by adding design elements, code, tests or other work products that are not called out in the requirements (i.e., “gold plating”). ... read more

[External] IEEE Std 990-1987 - IEEE Recommended Practice for Ada as a Program Design Language

EXTERNAL: this content refers to a remote source that is external to this web site.
ARCHIVAL: this content has been flagged as archival or historical.
Download from
Defines standard
Status (as a standards document)
archived
Abstract

The report provides recommendations reflecting the state of the art and alternative approaches to good practice for characteristics of program design languages (PDLs) based on the syntax and semantics of Ada. The recommended practice addresses the characteristics of an Ada PDL and not the use of an Ada PDL. While it is widely recognized that graphic representations may enhance the design activity, there is no clear consensus concerning graphic representations. As such, this document is principally concerned with aspects of textual representations.

[External] IEEE Std 982.1-1988 - IEEE Standard Dictionary of Measures to Produce Reliable Software

EXTERNAL: this content refers to a remote source that is external to this web site.
Download from
Defines standard
Status (as a standards document)
archived
Abstract

The standard provides a set of measures indicative of software reliability that can be applied to the software product as well as to the development and support processes. There is a need for measures than can be applied early in the development process that may be indicators of the reliability of the delivered product. The standard provides a common, consistent definition of a set of measures that may meet those needs. The document contains four sections. Section 1: Scope, establishes the goals and boundaries of the standard. Section 2: Definitions, serves as a central location for key terms used throughout the body of the document. Section 3: Functional Classification of Measures, provides a taxonomy with respect to measure objectives. Section 4: Measures for Reliable Software, presents the measures ordered in general by complexity.

[External] IEEE Std 830-1998 - IEEE Recommended Practice for Software Requirements Specifications

EXTERNAL: this content refers to a remote source that is external to this web site.
Download from
Defines standard
Status (as a standards document)
active

[External] IEEE Std 829-2008 - IEEE Standard for Software and System Test Documentation

EXTERNAL: this content refers to a remote source that is external to this web site.
Download from
Defines standard
Status (as a standards document)
active
Abstract

Test processes determine whether the development products of a given activity conform to the requirements of that activity and whether the system and/or software satisfies its intended use and user needs. Testing process tasks are specified for different integrity levels. These process tasks determine the appropriate breadth and depth of test documentation. The documentation elements for each type of test documentation can then be selected. The scope of testing encompasses software-based systems, computer software, hardware, and their interfaces. This standard applies to software-based systems being developed, maintained, or reused (legacy, commercial off-the-shelf, Non-Developmental Items). The term "software" also includes firmware, microcode, and documentation. Test processes can include inspection, analysis, demonstration, verification, and validation of software and software-based system products.

[External] IEEE Std 828-2005 - IEEE Standard for Software Configuration Management Plans

EXTERNAL: this content refers to a remote source that is external to this web site.
Download from
Defines standard
Status (as a standards document)
active
Abstract

The minimum required contents of a Software Configuration Management (SCM) Plan are established via this standard. This standard applies to the entire life cycle of critical software (e.g., where failure would impact safety or cause large financial or social losses). It also applies to noncritical software and to software already developed. The application of this standard is not restricted to any form, class, or type of software.

[External] IEEE Std 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology

EXTERNAL: this content refers to a remote source that is external to this web site.
Download from
Defines standard
Status (as a standards document)
active
Abstract

Describes the IEEE Std 610.12-1990, IEEE standard glossary of software engineering terminology, which identifies terms currently in use in the field of software engineering. Standard definitions for those terms are established.

Syndicate content