Systems Engineering Process – Requirements Part 3

In my previous blogs Requirements Part 1 and Part 2, I discussed how the requirements fit into the overall project and the specific language that is used in  the requirements process. This time we are going to look at the technical aspects of the requirements process. The requirements process is a part of the overall systems engineering process. These technical requirements flow down to the engineers, designers, programmers, suppliers and subcontractors. Problems managing these requirements will most definitely contribute significantly to project failures.  This includes not only managing the requirements, but also in the definition of the requirements themselves. Defining the requirements includes two major functions; defining the problem and defining the solution.

Defining the problem is the task of translating the needs of the sponsor into the requirements for the product, service or system. Defining the solution is the task of specifying the components that will meet those needs by becoming accepted deliverables.

Continue reading “Systems Engineering Process – Requirements Part 3”

Systems Engineering Process – Requirements Part 2

 Figure 1. Interpretations of Requirements

In Part 1 of the Systems Engineering Process – Requirements Part 1 blog, I discussed how the requirements process fits into the overall project and how the requirements ultimately impact the success or failure of the project. If we look at the standard IEEE definition for Requirement, we can determine the specific meaning of the word in the context of Systems Engineering.

Requirements Definition (IEEE-STD-1220-1998)

Continue reading “Systems Engineering Process – Requirements Part 2”

Systems Engineering Process – Requirements Part 1

In a previous blog on Systems Engineering Principles and Practices, I discussed the need for planning analysis and requirements definition. The requirements are the specific who, what, where and when for the product, service or system. With a clear understanding of the systems engineering requirements process, we can demonstrate how this process fits in with our current projects.  A Guide to the Project Management Body of Knowledge: (Pmbok Guide,4e) contains the standards for Project Management and it states that every project is broken down into the five Project Management Process Groups as seen in Figure 1.

Figure 1. PMBOK Project Management Process Groups

After reviewing how each of these processes fits into the overall project, we can start to understand where the requirements process fits into the project. As we will demonstrate later, the work on the project cannot begin until the requirements have been defined. The Requirements process is included in the planning for the project and are therefore included in the Planning Process Group.

Continue reading “Systems Engineering Process – Requirements Part 1”

Process Improvement – Systems Engineering Principles and Practices

Why Do We Need a Process?

What is it about the word process that makes some very creative and talented engineers, scientists, artists and others cringe? The fact is that even if you are not following a clear documented process, you are still following some sort of process, or steps, to achieve results. Webster defines a process as a natural progressively continuing operation or development marked by a series of gradual changes that succeed one another in a relatively fixed way and lead toward a particular result (Merriam-Webster). If there is already a set of steps in place that lead to results, what is the purpose in documenting and analyzing these steps may be the next logical question. Continue reading “Process Improvement – Systems Engineering Principles and Practices”