1996
DOI: 10.1002/j.2334-5837.1996.tb02042.x
|View full text |Cite
|
Sign up to set email alerts
|

Twelve Systems Engineering Roles

Abstract: Twelve roles are described which are occasionally or frequently assumed to constitute the practice of systems engineering. Some roles fit naturally as life-cycle roles, others fit the Program Management set of roles, while still others are not normally thought of in either group. Interactions between the roles are discussed, and the systems engineering roles assumed by the papers in the inaugural issue of Systems Engineering, the Journal of INCOSE, are compared to these categories.

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
1
1
1

Citation Types

0
115
0
1

Year Published

1999
1999
2018
2018

Publication Types

Select...
4
4
1

Relationship

3
6

Authors

Journals

citations
Cited by 138 publications
(119 citation statements)
references
References 4 publications
0
115
0
1
Order By: Relevance
“…requirements engineer, systems analyst, software quality assurance engineer (see Table 1) . Sheard [9] identifies twelve roles (see Table 2) of development from system engineering viewpoint while investigating the relationship between the roles and their importance for creating a value. This work not only suggests that the value is asserted in qualitative terms and it should be quantified in further research but it also claims that it should be observed as a requested improvement within a product by better (i) definition of the requirements, (ii) management strategies, (iii) ways for mitigating risks, (see [8] for details).…”
Section: Roles In Traditional Software Developmentmentioning
confidence: 99%
“…requirements engineer, systems analyst, software quality assurance engineer (see Table 1) . Sheard [9] identifies twelve roles (see Table 2) of development from system engineering viewpoint while investigating the relationship between the roles and their importance for creating a value. This work not only suggests that the value is asserted in qualitative terms and it should be quantified in further research but it also claims that it should be observed as a requested improvement within a product by better (i) definition of the requirements, (ii) management strategies, (iii) ways for mitigating risks, (see [8] for details).…”
Section: Roles In Traditional Software Developmentmentioning
confidence: 99%
“…The top-down approach is intended to facilitate the definition and translation of end users' requirements in the appropriate way, through a system approach (Bluyssen, et al, 2010); it takes advantage of reuse and off-the-shelf items that satisfy assigned requirements, in order to lessen development costs and shorten development cycle time (Sage & Armstrong, 2000). (Kossiakoff, et al, 2011); overlap between SE and PM: , (Roe, 1995), (Sheard, 1996), (Ekmark & Nelson, 1997), , , , (Department of Defense, 2011), (Pyster, et al, 2012); and SE and PM, parts of System Engineering Management: (Sharon, et al, 2011). After clarifying the key aspects of SE in projects, this section discusses four leadership paradigms of the relationship between PMer and SEer optimized according to the system characteristics ( Fig.…”
Section: Se Approachesmentioning
confidence: 99%
“…Table 2 compares twelve systems engineering roles that are suggested by Sheard [17] to the roles in our software engineering class. Please note that, the twelfth role, a classified ads systems engineer, refers to job description of a systems engineer posted in the classified ads, which could represent any tasks or unrelated tasks that are not in the first eleven roles.…”
Section: Systems Engineering Rolesmentioning
confidence: 99%