- 1. Requirements Management
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Conquering the 5 Biggest Challenges of Requirements Management
- 6 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- 1 Functional requirements examples and templates
- 2 How to write system requirement specification (SRS) documents
- 3 Adopting the EARS Notation to Improve Requirements Engineering
- 4 Jama Connect Advisor™
- 5 Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
- 6 How to Write an Effective Product Requirements Document (PRD)
- 7 Functional vs. Non-Functional Requirements
- 8 What Are Non-Functional Requirements and How Do They Impact Product Development?
- 9 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 10 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- 4. Requirements Traceability
- 1 What is Traceability?
- 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 4 How to Create and Use a Requirements Traceability Matrix
- 5 Traceability Matrix 101: Why It’s Not the Ultimate Solution for Managing Requirements
- 6 Live Traceability vs. After-the-Fact Traceability
- 7 How to Overcome Organizational Barriers to Live Requirements Traceability
- 8 Requirements Traceability, What Are You Missing?
- 9 Four Best Practices for Requirements Traceability
- 10 Requirements Traceability: Links in the Chain
- 11 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- 1 Understanding ISO Standards
- 2 ISO 26262 and Recent Updates: Ensuring Functional Safety in the Automotive Industry
- 3 What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 4 A Guide to Automotive Safety Integrity Levels (ASIL)
- 5 What is DevSecOps? A Guide to Building Secure Software
- 6 Compliance Management
- 7 What is FMEA? Failure Modes and Effects Analysis
- 8 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know
- 9 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 8. Project Management
- 9. Measuring Requirements
- 10. Systems Engineering
What is Systems Engineering?
Systems Engineering is an engineering field that takes an interdisciplinary approach to product development. Systems engineers analyze the collection of pieces to make sure when working together, they achieve the intended objectives or purpose of the product. For example, in automotive development, a propulsion system or braking system will involve mechanical engineers, electrical engineers, and a host of other specialized engineering disciplines. A systems engineer will focus on making each of the individual systems work together into an integrated whole that performs as expected across the lifecycle of the product.
In this chapter, we discuss:
- The fundamentals of systems engineering
- The role of a systems engineer
- Systems engineering process
- The “V” Model of systems engineering
What are the fundamentals of systems engineering?
In product development, systems engineering is the interdisciplinary field that focuses on designing, integrating, and managing the systems that work together to form a more complex system. Systems engineering is based around systems thinking principles, and the goal of a systems engineer is to help a product team produce an engineered system that performs a useful function as defined by the requirements written at the beginning of the project. The final product should be one where the individual systems work together in a cohesive whole that meet the requirements of the product.
What is a system?
A system is a collection of different elements that produce results that individual elements cannot produce. Elements or parts can be wide-ranging and include people, hardware, software, facilities, policies, and documents. These elements interact with each other according to a set of rules that produce a unified whole with a purpose expressed by its functioning. An example of a system is the human auditory system; the system includes individual parts in the form of bones and tissue that interact in a way to produce sound waves, which are transferred to nerves that lead to the brain, which interprets the sounds and formulates a response. If any single part in the auditory system fails or experiences disruption, the entire system can fail to perform its function.
What is systems thinking?
Systems thinking is a way of thinking that looks at the overall function of a complex system rather than breaking it down into smaller parts. For example, systems thinking would consider an automobile a complex system that consists of smaller, specialized elements. While an electrical engineer might only be concerned with the electrical system of the automobile, someone looking at the entire complex system would consider how the electrical system would impact other systems in the automobile — and how those other systems might impact the electrical system. If one piece of the electrical system fails, for instance, how would that failure cascade to other systems to impact the operability of the automobile? Systems thinking will take a “big picture” approach to the overall product.
What is the role of a systems engineer?
A systems engineer is tasked with looking at the entire integrated system and evaluating it against its desired outcomes. In that role, the systems engineer must know a little bit about everything and have an ability to see the “big picture.” While specialists can focus on their specific disciplines, the systems engineer must evaluate the complex system as a whole against the initial requirements and desired outcomes.
Systems engineers have multi-faceted roles to play but primarily assist with:
- Design compatibility
- Definition of requirements
- Management of projects
- Cost analysis
- Possible maintenance needs
- Ease of operations
- Future systems upgrades
- Communication among engineers, managers, suppliers, and customers in regards to the system’s operations
How can systems engineers help improve traceability?
For many systems engineers, balancing the needs of the individual systems and their engineers against the system as a whole results in addressing problems after the fact, holding unwanted meetings, and trying to persuade others to change behavior. Many organizations may not adequately focus on requirements and traceability, resulting in a lack of data that would allow a systems engineer to better evaluate the product.
To avoid constantly chasing problems and start streamlining processes, systems engineers can use three best practices:
- Baseline the current traceability performance: Traceability spans the product development process, and product team members understand the value of data management, especially as concerns meeting industry requirements. By establishing a baseline of traceability performance, the entire team will be able to see existing risks and potential savings and improvements. In addition, a baseline can give a foundation for a plan of action to move toward Live Traceability.
- Build the business case for Live Traceability: With a baseline in hand, systems engineers can offer a case for moving to Live Traceability based on data. The data can establish the ROI, productivity improvements, and risk reduction of moving from static traceability to Live Traceability.
- Create quick wins: Once the advantages of Live Traceability are established, the systems engineer can set up continuous syncing between requirements and task management programs, thus automating traceability from requirements to user stories. This simple shift can help demonstrate the value of shifting from after-the-fact traceability to Live Traceability.
RELATED ARTICLE: Ensure Product Quality with These Review Process Best Practices
What is the Systems Engineering Process?
The systems engineering process can take a top-down approach, bottoms up, or middle out depending on the system being developed. The process encompasses all creative, manual, and technical activities necessary to define the ultimate outcomes and see that the development process results in a product that meets objectives.
The process typically has four basic steps:
- Task definition/analysis/conceptual: In this step, the systems engineer works with stakeholders to understand their needs and constraints. This stage could be considered a creative or idea stage where brainstorming takes place and market analysis and end user desires are included.
- Design/requirements: In this phase, individual engineers and team members analyze the needs in step 1 and translate them into requirements that describe how the system needs to work. The systems engineer evaluates the systems as a whole and offers feedback to improve integration and overall design.
- Create traceability: Although we’re listing traceability here as the third step, traceability is actually created throughout the lifecycle of development and is not a discrete activity taking place during one phase. Throughout the lifecycle of development, the team works together to design individual systems that will integrate into one cohesive whole. The systems engineer helps manage traceability and integration of the individual systems.
- Implementation/market launch: When everyone has executed their roles properly, the final product is manufactured or launched with the assurance that it will operate as expected in a complex system throughout its anticipated life cycle.
The “V” Diagram of Systems Engineering
Developed in the 1980s, the “V” Diagram of Systems Engineering is a way of specifying the specific series of steps that make up a systems engineering approach. While it was originally employed in a pre-Agile environment, it still has relevance to product development today and can enable faster, less risky product development.
The “V” diagram allows system engineers multiple viewpoints and opportunities to evaluate systems as they integrate with each other. This approach starts with the desired outcomes and objectives and then deconstructs them into individual systems and system components for the purpose of design. Once the requirements and design details are established, individual systems can be tested and evaluated, then integrated into the overall piece for testing and verification. As the systems are integrated and become closer to the final complex system, teams have multiple opportunities to validate and verify concepts, requirements, and design.
For the systems engineer, the “V” Model can give a clear roadmap that allows the breakdown of the complex system into smaller parts and then the reintegration and reassembly of the pieces into a cohesive whole. With systems broken down to individual components, traceability, requirements management, and testing and validation become more manageable. In addition, as the pieces are reintegrated into the whole system, the “V” Model allows for an iterative process that gives a clearer view into potential risks and helps troubleshoot problems.
Systems engineering is a discipline that’s vital to the success of a complex system. By including systems engineers in all stages of product development and requirements management, teams can reduce risks, improve time to market, and produce better products that more adequately meet end user requirements.
In This Webinar, Learn More About Systems Engineering in Jama Connect
Systems Engineering is an engineering field that takes an interdisciplinary approach to product development. Systems Engineers analyze the collection of pieces to make sure when working together, they achieve the intended objectives or purpose of the product.