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.

 

Figure 1. Project Requirements

 

There are a number of key aspects to consider as the requirements are defined. Figure 1 shows some of the most important things to consider in the initial part of the requirements definition for the project. Obviously, the product, service or system must be marketable and usable. This is part of what A Guide to the Project Management Body of Knowledge: (Pmbok Guide,4e) describes as the Business Case. The business case is created as a result of market demand, organizational need, customer request, technological advance, legal requirement, ecological impacts and/or a social need (PMBOK, 4th Edition).

Once we have determined that we have marketability and usability requirements, the next step is to ensure that the product, service or system is producible. This includes not only the consideration of whether is possible or feasible, but also if it is producible within the constraints of the project including schedule and budget. Finally, as part of the Verify Scope process, the product, service or system must be verifiable. This will ensure that when the project is complete, we have accepted deliverables.

Figure 2. Additional Considerations

As we look at the full lifecycle of the product, as opposed to the project, Figure 2 shows some additional considerations. Many times the initial delivery of a product or system is one project in a much larger overall program. This product or system may be supported for many years after initial delivery. Once the product is delivered, it must be supportable and maintainable. There can be some very specific requirements regarding reliability. When the product or system has been used up, it must be in some way or another disposable. All of these need to be considered when defining the requirements, regardless of whether they are specifically called out in the contract or not.

Beyond the basic requirements related to the project and product lifecycle, there are going to be specific technical requirements for the product, service or system.

Functional One of the first technical requirements that should be considered will be the functional requirements. The functional requirements are those necessary tasks actions or activities that the product, service or system must do to meet the needs of the customer.

Performance The performance requirements are the extent to which mission or task must be performed and/or executed. These requirements can be measured in relation to quantity, coverage, timeliness, or readiness.

Physical Physical characteristics address environmental and/or operational constraints such size, weight, dimensions, packaging, materials, etc. This can also include specific requirements for a particular engineering discipline such as grounding, power conditioning and EMI/EMC for electrical systems.

Interface There are most likely going to be some logical and physical interactions with other systems and/or users that will result in interface requirements. This can be a very important part of the requirements for an IT product or system.

Specialty Engineering Specialty engineering requirements can be any other life cycle factors or characteristics of the product, service or system that enhance system effectiveness and efficiency in operations and maintenance scenarios. Examples of specialty engineering requirements are those related to human factors, safety and security among others.  

This is not an exhausted list of technical requirements that are possible on any given project. The topics listed are mainly to give a basic overview of what is considered in the technical requirements for a project.

References:

Kossiakoff, Alexander; Sweet, William N.; Seymour, Same; Biemer, Steven M. (2011) Systems Engineering Principles and Practice (Wiley Series in Systems Engineering and Management)

Project Management Institute (PMI) (2009) A Guide to the Project Management Body of Knowledge: (Pmbok Guide,4e)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s