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