=Paper=
{{Paper
|id=Vol-2010/paper4
|storemode=property
|title=Integrated Requirements Baseline Management For Complex Software Systems
|pdfUrl=https://ceur-ws.org/Vol-2010/paper4.pdf
|volume=Vol-2010
|authors=Sergio Funtò
|dblpUrl=https://dblp.org/rec/conf/ciise/Funto17
}}
==Integrated Requirements Baseline Management For Complex Software Systems==
https://ceur-ws.org/Vol-2010/paper4.pdf
Integrated Requirements Baseline Management for
Complex Software System
Description of Methods and Tools for improving the Software Modules Design processes for
complex Systems in a Project Management and System Engineering Integrated Environment
Sergio Funtò
Engineering Ingegneria Informatica S.p.A.
Via S. Martino della Battaglia 56 Rome, Italy
sergio.funto@eng.it
Copyright © held by the author.
Abstract—This paper reports on experiences from managing the • the methods and tools used in regards to the Project
requirements baseline in regards to Complex Software System. The Management (PM) and System Engineering (SM) integrated
requirements management of these starts from the architectural activities to support the design process phases.
structure of the whole system by defining the high-level
functionalities. The complex systems are architecturally organized in The next Section II describes the background of the work, and
separate modules and each of them gives support to the development introduces the Military Standard 498 (MIL-STD-498), the Waterfall
of one or more functionalities of the whole systems. The flow down Model and the referred integration mechanism in regards to PM-SE
of the whole system requirements towards the requirements of each activities.
module and the monitoring of the related traceability are the core
activities within the baseline management. Moreover, the Section III introduces the operative scenario used as reference to
development plan of a complex system foreseen more than one describe the proposed requirements baseline methods and tools as
deliveries each one characterized by new features and functionalities reported in Section IV.
compared to the previous one. Each system version is defined by the
set of the corresponding modules. This scenario requires a project
development environment where Project Management (PM) and II. BACKGROUND
System Engineering (SM) activities are strictly connected and
integrated. The presented approach takes into account the system A. What is a Complex Software Systems
development life cycle identified by quality standard adopted for the The definition of a CSS is strictly related to the identification of
software development and documentation. Adopted methods, tools the properties of a Complex System and to the features of a Software
and artifacts are presented in order to describe the proposed processes System.
taking into account PM and SE activities integration mechanisms
episodic and pervasive. 1) The Complex Systems
A Complex System is composed of many components which may
Keywords—Requirements Management Processes, Scope interact with each other. In many cases it is useful to represent such a
Management, Project Management and System Engineering system as a network where the nodes represent the components and
Integration the links their interactions. The behavior of a Complex Systems is
intrinsically difficult to model due to the dependencies, relationships,
or interactions between their parts or between a given system and its
I. INTRODUCTION
environment. Systems that are complex have distinct properties that
This paper presents experiences from defining and managing the arise from these relationships, such as: non-
requirements baseline related to Complex Software System (CSS). linearity, emergence, spontaneous order, adaptation, and feedback
loops, among others. Because such systems appear in a wide variety
Starting from the general definition of a Complex System, are of fields, the commonalities among them have become the topic of
introduced the main concepts and elements to be taken into account their own independent area of research.
in order to describe the proposed methods and tools.
2) Properties of a Complex Systems
In this regards, a specific focus is dedicated to identify: Abstracting from the quotations related to Complex Systems and
drawing on the culture of complexity science as expressed through a
• the design process/model adopted as references for the system wide range of popular as well as academic sources, the following list
development process; of properties can be associated with the idea of a complex system [1]:
• the artifacts and documents used to describes the adopted • Nonlinearity - is often considered to be essential for complexity.
software development life-cycle; A system is linear if one can add any two solutions to the
equations that describe it and obtain another, and multiply any
solution by any factor and obtain another. Nonlinearity means as specification, test results, end-user documentation, maintenance
that this superposition principle does not apply; records, etc.
• Feedback - is an important necessary condition for complex The use of the term software system is at times related to the
dynamical systems. A part of a system receives feedback when application of systems theory approaches in the context of software
the way its neighbors interact with it at a later time depends on engineering. A software system consists of several separate computer
how it interacts with them at an earlier time; programs and associated configuration files, documentation, etc., that
operate together [2]. The concept is used in the study of large and
• Spontaneous order - given the above it is clear that a complex software, because it focuses on the major components of
fundamental idea in complex systems research is that of order in software and their interactions. It is also related to the field
a system’s behavior that arises from the aggregate of a very of software architecture.
large number of uncoordinated interactions between elements;
B. The Software System Design Process
• Robustness and lack of central control - the order in complex
systems is said to be robust because, being distributed and not Once introduced the definition and the characteristics/properties
centrally produced, it is stable under perturbations of the system. of the CSS, the next step is to identify the adopted system design
A centrally controlled system on the other hand is vulnerable to process.
the malfunction of a few key components;
1) The Waterfall Model
• Emergence - is a notoriously murky notion with a long history in The Waterfall Model can be described through a sequential (non-
the philosophy of science. People talking about complexity iterative) design process, used in software development for large
science often associate it with the limitations of reductionism. A systems, in which progress is seen as flowing steadily downwards
strong, perhaps the strongest, notion of emergence is that (like a waterfall) through the phases of conception,
emergent objects, properties or processes exhibit something initiation, analysis, design, construction, testing, production,
called ’downwards causation’; implementation and maintenance.
• Hierarchical organization - In complex systems there are often In the original waterfall model [3], the following phases are
many levels of organization that can be thought of as forming a followed in order: System and software requirements: captured in
hierarchy of system and sub-system. Emergence occurs because a product requirements document; Analysis: resulting
order that arises from interactions among parts at a lower level is in models, schema, and business rules; Design: resulting in
robust; the software architecture; Coding: the development, proving,
and integration of software; Testing: the systematic discovery
• Numerosity - the kind of hierarchical organization that emerges and debugging of defects; Operations:
and gives rise to all the features listed above, only exists if the the installation, migration, support, and maintenance of complete
system consists of a large number of parts, and usually, only if systems.
they are engaged in many interactions;
• Remarks - The above discussion makes it clear that the
definition of complexity and complex systems is not
straightforward and is potentially philosophically interesting.
The notions of order and organization introduced above and the
idea of feedback are suggestive of an information-theoretic
approach to complexity, since complex systems can be often
helpfully be construed as maintaining their order and
hierarchical organization by the exchange of information among
their parts.
3) The features of the Software Systems
A Software System is characterized by inter
communicating components based on software forming part of
a computer system (a combination of hardware and software). It
consists of a number of separate programs, configuration files, which
are used to set up these programs, system documentation, which
describes the structure of the system, and user documentation, which Figure II-1: The Waterfall phases [3]
explains how to use the system.
The United States Department of Defense (DOD) captured this
The term Software System should be distinguished from the terms approach in the DOD-STD-2167A, their standards for working with
‘computer program’ and ‘software’. The term computer program software development contractors, which stated that "the contractor
generally refers to a set of instructions (source, or object code) that shall implement a software development cycle that includes the
perform a specific task. However, a software system generally refers following six phases: Preliminary Design, Detailed Design, Coding
to a more encompassing concept with many more components such and Unit Testing, Integration, and Testing. The DOD-STD-2167A is
the precursor of the MIL-STD-498 introduced hereafter.
C. The Software System Description existing systems or procedures, and the ways it will be used. The
Following the identification of the adopted system design OCD is used to obtain consensus among the acquirer, developer,
process, another core step is the specification of the artifacts and support, and user agencies on the operational concept of a
documents used to describes the adopted software development life- proposed system;
cycle.
• System/Subsystem Specification (SSS): specifies the
requirements for a system or subsystem and the methods to be
1) The Military Standard 498
used to ensure that each requirement has been met.
The Military-Standard-498 (MIL-STD-498) is a United
Requirements pertaining to the system or subsystem’s external
States military standard whose purpose was to establish uniform
interfaces may be presented in the SSS or in one or more
requirements for software development and documentation. It
Interface Requirements Specifications (IRSs) referenced from
replaced the DOD-STD-2167A, DOD-STD-7935A, and DOD-STD-
the SSS;
1703. It was meant as an interim standard, to be in effect for about
two years until a commercial standard was developed.
• System/Subsystem Design Description (SSDD): describes the
sytem- or subsystem-wide design and architectural design of a
Unlike previous efforts the MIL-STD-498 was the first attempt at
a truly comprehensive description of the systems development life- system or subsystem. The SSDD may be supplemented by
cycle. It was the baseline that all of the ISO, IEEE, and related efforts Interface Design Descriptions (IDDs) and Database Design
Descriptions (DBDDs);
after it replaced. It also contains much of the material that the
subsequent professionalization of project management covered in the
Project Management Body of Knowledge (PMBOK) [7]. • Interface Requirements Specification (IRS): specifies the
requirements imposed on one or more systems, subsystems,
Hardware Configuration Items (HWCIs), Computer Software
2) MIL-STD-498 Data Idem Descriptions
Configuration Items (CSCIs), manual operations, or other
The MIL-STD-498 standard specifies [4] the development and
system components to achieve one or more interfaces among
documentation in terms of 22 Data Item Descriptions (DIDs) from
these entities. An IRS can cover any number of interfaces.
which an effort will select to conduct the system development and
support efforts. Each DID generically describes the required content
of a data item, a file or document that describes the system or some D. PM and SE Integrated Environment
aspect of the system life-cycle. These documents could take many The design and development of a CSS, taking into accounts the
forms, from source code, to installation scripts, to various electronic elements introduced before, takes advantage from a working
and paper reports, and the contracting party (e.g., the government) is environment where Project Management (PM) and System
encouraged to specify acceptable formats. Any data item description Engineering (SE) activity are strictly integrated.
is tailored for a specific contract, meaning sections not desired for a
particular effort are identified as not to be provided as part of All aspects of integration are about individuals and how they
identifying the Contract Data Requirements List (CDRL) of what coordinate the application of their collective knowledge, expertise
items are to be produced and delivered by a contractor. Exactly which and capabilities to deliver results. Effective integration efforts are
DIDs and what parts of the DIDs are required for a particular system accomplished through the application of processes, practices and
depends on the nature of the project and how parts of it are being tools that help to enable important abilities [5]:
produced by contract(s).
• enable communication and common understanding on key
objectives,
• provide framework for defining specific work activities,
• document approaches for coordinating and tracking work effort;
• establish expectation of each person’s contribution;
• identify critical point where focalized the work effort;
• facilitate problem identification and resolution;
• apply generally accepted approaches that have demonstrate
effective results under similar circumstances in the past;
Figure II-2: MIL-STD-498 DID [4]
• support and accelerate the accomplishment of specific work
3) Data Idem Description related to System Specification activities.
The MIL-STD-498 DIDs covers all the phases of a software
system development life-cycle. In regards to system design and Some processes, practices and tools are designed for individual
requirements specification, the involved DIDs are listed hereafter: use while others may be structured fro group activities. Both uses
have appropriate application within complex program.
• Operational Concept Description (OCD): describes a proposed
system in terms of the user needs it will fulfill, its relationship to The process, practices and tools can be organized by the timeline
of their impact on integration: episodic or pervasive [5]. Episodic
integration emerges as the need requires. Pervasive integration tends paid to requirements and when integration is crucial. The WBS
to be synchronous with the daily work of the program or its serves as the key framework for organizing the program and the
component project. system engineering effort as well as for estimating and
allocating cost, schedule and performance requirements;
1) Episodic Integration Mechanism
Episodic integration mechanisms are applied occasionally to • Work Design Process: work design process as configuration
specific activities or at specific intervals within a program/project: management can help to increase communication and
collaboration across the program. Another work design process
• Program Gate Reviews: require that all program aspects (cost, is standardized work that foreseen rigorous design
schedule, performance, risks, requirements, testing) be presented standardization supports platform reusability. The work
in their current state of maturity individual gates in order to: processes are deliberately designed so that integration is a
receive approval to proceed to the next project gate (Go), repeat natural outcome of the work itself;
the review after addressing specific concerns (recycle) or
terminate the project (No Go); • Requirements Management: it forces conversation between
program/project manager and systems engineers. Effective
• Joint Planning: There are a variety of tools, templates and requirements management practices helps to align the work so
software application that organizations can use to support that customer receive ideal solution and desired program/project
scoping and planning activities. Moreover, there are a number of benefits and value is realized for the business. Requirements
planning related practices that help to integrate PM and SE. management often start at the concept level as a high level view
These include: program kick-off workshops (that brings together associated with investment or business opportunities. The
all key stakeholder including engineers, project managers and project manager and the chief system engineer build on the hight
factory teams) and model based program planning (artifacts level view by eliciting, documenting, and validating high level
describing the program/project including product breakdown requirements from customer and stakeholders. The project may
structure, work breakdown structure, system engineering process further cascade elements of the high level requirements for more
models); detailed development;
• Dedicated Team Meeting Space: The creation and use of • Risk Management: Effective risk management ensure that the
dedicated team meeting space and stand-up meeting is a proven sponsoring organization realized its desired benefits. Ideally risk
process in a variety of domains; management processes should be fully integrated into all
program/project activities (management, technical, design,
• Pulsed Product Integration and Iterative Development: (PPIID) development, procurement, planning;
it is sometime described as the ‘daily build’ of product
components into more complex component or into complete • Technical Performance Measurements: is an analysis and
products. Iterative development comprises the use of short control technique that is used to anticipate the probable
cycles to create and deliver product increments. performance of a selected technical parameter, record the actual
performance observed of the selected parameter and assist the
2) Pervasive Integration Mechanism manager in decision making through comparison of planned
versus actual performance;
There are process, practices and tools integral to program design
and development. They are continuous in nature and thus are • Governance: is a structured mechanism through which
‘pervasive’. The application of pervasive integration mechanism can individuals with oversight responsibility and authority provide
help program teams realize such potential benefits for their guidance and decision making for important organizational
organization: activities. The governance serves the following key functions
[6]: Oversight, Control, Integration and Decision Making.
• Standard, Methodologies and Assessment: A methodology is a
documented approach for integrating interacting or
III. THE OPERATIVE ENVIRONMENT SCENARIO
interdependent practices, techniques, procedures, and rules to
determine how best to plan, develop, control and deliver a The previous Section II has introduced the main elements that
defined objective. A standard, on the other hand, reflects broadly characterized the proposed system requirements baseline
accepted principles of what represents good practices or management. This section specifies the environment scenario related
common guidelines. As the methodology is implemented, to the target program/project.
executive leaders and user must evaluate (assess) the specific
practices and the extent to which the company is adhering to its
A. The Complex Software System Decomposition
methodology;
According to the Software Design DIDs identified by the MIL-
• Integrated Product and Process Development: (IPPD) also STD-498, a first description of the Complex System is given in the
known as ‘simultaneous engineering’ or ‘design build’, uses OCD (see Section II.C.2). Taking into account the Pulsed Product
multidisciplinary co-located teams in design to jointly derive Integration and Iterative Development (PPIID) and the Integrated
requirements and schedules with equal emphasis on product and Product and Process Development (IPPD) integration mechanism
process development. The teams often use requirement (see Section II.D.2), the first requirements breakdown consist in the
breakdown structure (RBS) and work breakdown structure decomposition of the complex system OCD in three different OCD in
(WBS) to facilitate their scoping and planning activities. RBS regards to complex system: Hardware: user needs related to
are used where complex system dictate significant attention be hardware elements; Software: user needs related to software
functionalities; and Interfaces: requirements related to the external Note: The Software Engineering activities are reported in the
interfaces to be managed. corresponding DIDs: Software Requirements Specification (SRS),
Software Design Description (SDD), Interface Data Description
(IDD).
Figure III-1: Complex System Decomposition
Taking into account only the Software component the further
breakdown of the related OCD (applying PPIID and IPPD) is given
by the definition of the OCDs related to the single software modules
that compose the this component of the complex system.
B. The Software System Description
Figure III-3: System Software adopted life-cycle
Each software module from the design point of view is fully
defined by (see Section II.2) by the following artifacts (documents
and models): System/Subsystem Specification (SSS),
System/Subsystem Design Description (SSDD) and Interface
Requirements Specification (IRS).
Figure III-2: Software System Module Design
Specifically the IRS related to each software module is part of the
breakdown of the CID related to the CSS Interfaces. In other terms
the CID relates to the interface of the global system are Figure III-4: Software System life-cycle activities
“implemented” through the IRS of each module of the software
component of the system itself. Additional input to the System Engineering comes from the
System Validation and Verification activities where, for example,
This requirements organization takes into account the failures in the system behavior are related to anomalies or errors in
Requirements Management integration mechanism (see Section the system specification and design (see next Section III.D for further
II.D.2). details).
Moreover, also within Software Requirements baseline
C. The Design Process management uses MIL-STD-498 documents managed in the
As stated in the Section II.B.1, the Waterfall model approach was Software Engineering activities (see [4]).
captured in the MIL-STD-498. The related DIDs have an immediate
correspondence in the adopted system software life-cycle (see Figure
III-3) identified within the model in regards to the Work Design D. System Versions approach
Process integration mechanism (see Section II.D.2). Starting from the complexity of the system and the related
functionalities and taking into account the suggestions of the
Specifically, the system requirements baseline management is integration mechanism (see section II.D), the approach foreseen more
focused on the System Engineering activities (see Figure III-4) than one system delivery according to (contractual) milestone each
related to: user requirements Analysis (described in the CID), System one corresponding to functional increments of the system according
Requirements Analysis (defined in the SSS/IRS) and System Design to the following schema:
(detailed in the SSDD).
• the Milestone Mk foreseen (at Tk) the delivery of the version Vk
of the system according to the documents: SSSk, SSDDk, IRSk;
• after the Mk, the activities related to the delivery of the • reviewing all change requests;
milestone Mk+1 are started in order to deliver the version Vk+1
at Tk+1. This is related to the corresponding evolution (k k+1) • approving changes and managing changes deliverables, project
of the systems design and specification (SSS, SSDD and IRS). technical documents and project plans;
This versions approach schema taken into account in the RBS and • communicating their disposition.
in the WBS of the project (see Pervasive Integration Mechanism,
Section II.D.2). It reviews all requests for changes or modification to project
documents, deliverables, baselines and project management plan.
Within the k k+1 evolution, in addition to the activities related Moreover, it approves or rejects the changes. The key benefit of this
to the design and specification of the functional increments of the process is that it allows the documented changes within the project to
system, are taken into account the following input, including be considered in an integrated fashion while reducing project risk,
outcomes from System Verification and Validation activities: which often arises from changes made without consideration to the
overall project objectives and/or plans.
• failures coming from the final customer highlighted during the
system verification activities on the Vk version;
• not blocking remarks on the Vk version coming from the system
validation team;
• evolution of the user needs (e.g new operating rules, blaws,
STANAG,..).
1) Impact on Software System life-cycle
Figure IV-1: Integrated Change Control – Inputs, Tools and
As reported in the previous Section III.C, the adopted Software Techniques and Outputs [7]
System life-cycle corresponds to a sequential process. At the same
time, the System Versions approach foresees activities iterations each Changes may be requested by any stakeholder involved in the
one corresponding to a specific version. project. They should be recorded in written form and entered into the
change management and/or configuration management system.
This results in sequence of design phases corresponding to the Change requests are subject to the process specified in the change
System Versions where a specific phase takes inputs from the control and configuration control system. Those change request
previous one and gives input to the next one. The activities foreseen process may require information on estimated time impacts and
for each phase are the same (according to Waterfall model): estimated cost impacts.
1) Change Control Board
Every documented change request need to be either approved or
rejected by a responsible individual (project or program manager).
The integrated change control process includes a Change Control
Board (CCB) which is a formally chartered group responsible for
reviewing, evaluating, approving, delaying or rejecting changes and
for recording and communicating such decisions. Approved change
Figure III-5: System Versions design phases requests can require new or revised cost estimates, activity
sequences, schedule dates, resource requirements and analysis of risk
IV. REQUIREMENTS BASELINE MANAGEMENT response alternatives. Customer/sponsor approval may be required
Starting from the Operative Environment Scenario identified in for certain changes after the CCB approval, unless they are part of the
Section III and taking into account the PM-SE integration CCB.
mechanisms specified in Section II.D, this section reports the
methods and tools related to the proposed requirements management 2) Configuration Control
activities. Configuration Control is focused on the specification of both the
deliverable and the process, while change control is focused on
The management of the requirements baseline in regards to identifying, documenting and approving or rejecting changes to the
complex software is focused on the concept of the changes project documents, deliverables and baselines.
management embedded on the system versions approach (see Section
III.D). Within the Vk Vk+1 evolution of the system, the Some of the configuration management activities included in the
corresponding functional increment is specified by the upgrade of the integrated change control are configuration:
Requirements Baseline (RB): RBk RBk+1. This requirements
evolution is regulated by a set of change requests managed through • identification: identification and selection of a configuration
an integrated change control. item to provide the basis for which the product configuration is
defined and verified, products and documents are labeled,
changes requests are managed and accountability is maintained;
A. Integrated Change Control
Perform Integrated Change Control [7] is the process of:
• status accounting: information is recorded and reported as to C. Approving the CRD
when appropriate data about the configuration item should be Each Change Request on the Vk version of the module Mx,
provided; described by the corresponding CRD, in order to be approved for
application to the Vk+1 version, must to be reviewed by the involved
• verification and audit: ensure the composition of a project’s individuals (specified in the CRD itself) within a CCB:
configuration item is correct and that corresponding changes are
registered assessed, approved, tracked and correctly
implemented.
B. Change Request Description
According to previous Section III.D and Section IV.A, the change
requests are documented through an artifacts named Change Request
Description (CRD).
Figure IV-3: Approving CRD through CCB
An important input to the CCB, in addition to the CRD to be
reviewed, is the time and cost impact evaluation for each change
request in regards to the implementation of the changes on the
version Vk+1 of the affected system module. These evaluations must
to take into account system engineering and system verification and
validation activities (see Section III.C).
The main outcomes of the CCB are the approved Change
Figure IV-2: CRD Management Requests that became Change Request Order (CRO) applicable to the
Vk+1 version.
Each Change Request on the Vk version of the system (see
Section III.D) is related to: a function increment requested for the
Vk+1 version, failures coming from the customer on the Vk version,
non-blocking remarks on the Vk version, other needs.
Each CRD is labeled with an Identifier (CRD_ID) defined
according to the configuration control and report the following
information:
• the authors of the CRD;
• the figures in the project team responsible for the acceptance of
the CRD;
• the module of the system affected (see Section III.A);
Figure IV-4: Software baseline evolution according CRO
• the deliverables, documents and artifacts affected by the changes
(if approved); Each CRO must to be applied to the system description
documents (see Section II.C.3) in order to define the new software
• identification of the items affected by the change in regards to baseline, as defined in the CCBs, to be applied by the software
design documents (see Section II.C.3) and artifacts (e.g. engineering activities.
models);
D. System Failure Description
• detail description of the reasons related to the change;
The Change Request mechanism is applied also to the
• detailed description of the proposed changes (requirements, management of the System Failure (SF) highlighted during the
models, drawings). system verification and validation phase of the specific version (Vk)
on one module (Mx).
Similar to the change request, the system failures are documented
through a System Failure Description (SFD). Each SFD is labeled
with an Identifier (SFD_ID) defined according to the configuration
control and reports at list: the authors, the module of the affected Engineering (SE) activity are strictly integrated. All aspects of
system (see Section III.A), identification of the functionalities integration are about individuals and how they coordinate the
affected by the failure, detailed description of the failure including application of their collective knowledge, expertise and capabilities
the operative condition and references to supporting artifacts. to deliver results. Effective integration efforts are accomplished
through the application of processes, practices and tools These can be
organized by the timeline of their impact on integration: episodic or
pervasive. Episodic integration emerges as the need requires.
Pervasive integration tends to be synchronous with the daily work of
the program or its component project.
Starting from a first description of the CSS (given in the
Operational Concept Description OCD) is introduced the proposed
environment scenario related to the target, taking into account the
Pulsed Product Integration and Iterative Development (PPIID) and
the Integrated Product and Process Development (IPPD) integration
mechanism. The output of this process is the identification of the
software modules that compose the software component of the CSS.
The proposed System Version approach (based on the
suggestions of the integration mechanism) foreseen more than one
system delivery according to (contractual) milestones each one
corresponding to functional increments of the system. This results in
Figure IV-5: System Failure vs Change Request sequence of design phases corresponding to the System Versions
where a specific phase takes inputs from the previous one and gives
input to the next one.
Each system failure may be related to:
The management of the requirements baseline in regards to CSS
1. an anomaly of the system specifications or design that affect the is focused on the concept of the changes management embedded on
SSS/SSDD or IRS (see Section II.C.3). the system versions approach. Within each System Version evolution,
the corresponding functional increment is specified by the
2. an anomaly of the software specifications/design or corresponding upgrade of the Requirements Baseline. This
implementation. requirements evolution is regulated by a set of change requests
managed through an integrated change control.
In the first case, starting from the SFD is produced a change
request (documented by a CRD that specifies the recommended
corrective action [7]) to be reviewed/approved in a CCB. The VI. REFERENCES
corresponding CRO specifies the implemented corrective action. 1. James Ladyman, James Lambert (Department of Philosophy,
University of Bristol, U.K), Karoline Wiesner (Department of
In the second case, a Software Problem Report (SPR) is defined Mathematics and Centre for Complexity Sciences, University of
in order to trace the recommended defect repair that will be Bristol, U.K.) - “What is a Complex System” (2012).
implemented in the Vk+1 version of the affect module of the system.
2. Sommerville, Ian - "What is software?". Software Engineering,
8th ed. (2007).
V. CONCLUSION
The paper presents experiences from defining and managing the 3. Winston Royce - "Managing the Development of Large
requirements baseline related to Complex Software System (CSS). Software Systems", Proceedings of IEEE WESCON (1970).
The definition of a CSS is strictly related to the identification of 4. Joint Logistics Commanders and Joint Policy Coordinating
the properties of a Complex System and to the features of a Software Group on Computer Resources Management - “Military
System. A complex system is composed of many components which Standard 498 (MIL-STD-498) Overview and Tailoring
may interact with each other. A software system is based on inter Guidebook” (1994);
communicating components based on software forming part of
a computer system (a combination of hardware and software). 5. Eric Rebentish, PMI, INCOSE – “Integrating Program
Management and System Engineering. Methods, Tools and
Starting from the identification of the features of a CSS, it is Organizational Systems for Improving Performance”, Wiley
identified the adopted system design process, the Waterfall Model, (2017);
and the artifacts and documents used to describes the software
development life-cycle. In this regards, it is introduced the MIL- 6. PMI – “Governance of Portfolio, Program and Projects: A
STD-498 Data Item Descriptions (DIDs) that covers all the identified Practice Guide” (2016);
phases giving a focus on the DIDs involved in the system design and
requirements specification. 7. PMI – “A guide to the Project Management Body of
Knowledge” Fifth Edition (2013);
The design and development of a CSS takes advantage from the
working environment where Project Management (PM) and System