What are the key steps to conducting a functional requirements analysis?

Take some time to understand your audience and their personas. Everyone has a different perspective based on their function, position, experience, and personal sentiment. This will help you navigating the conflicting requirements into a more holistic approach that serves most people (yeah by the way, you will never fulfill everyone's dream).

Flexibility to expand and adopt newer and advanced aspects which may result expansion of capabilities and or to become a SIS- system in a system

To add, functional requirements analysis should take both business and technical needs of the customer and also needs of all other relevant stakeholders with the goal of providing a quality product that meets the user needs. In high performance organizations, a great deal of emphasis is put on understanding requirements in order to increase the success of the product realization efforts. Systems engineering, of which functional requirements analysis is a subset, ensures that the voice of customer is heard and carried throughout the product life cycle enhancing project deliverables.

Hire a good functional requirements analyst! Hire a good functional requirements analyst! Hire a good functional requirements analyst!

The first step is to understand what is meant by functional requirements analysis. This is not a process defined in either ISO 15288 or the INCOSE Systems Engineering Handbook. Historically, and principally in software development, it has been understood to mean the analysis and definition of the functions that the system under development has to perform. This is distinct from the functions that the stakeholders want to carry out. It also risks omitting any consideration of constraints and other non-functional requirements. (I have often noticed that the biggest section in so-called Functional Requirements Specifications is that on Non-Functional Requirements.)

Don't miss the most important stakeholder(s) - the "customer" and "user" of the system. In case of large or complex systems, while the customer and the user may be the same, often they would be completely different entities. For example, for logistics fleet of vans, trucks, ships or planes, big companies are the customers who pay for the systems but individuals or teams that drive, sail or fly them are the users. The same is true for industrial robots, construction machinery, electrical power systems etc.

One thing that we may forgot here is to include manufacturing/production stakeholders. They will have needs of testing, assembling, and delivering the final system, at least for a product. Identification of those needs can lead to planification/architecture/technology decisions in the project.

Identifying the potentially relevant stakeholders is uniquely difficult and requires experience to hone. Without being the expert in all areas, it requires imagination and practice to identify and seek out those who are experts and could potentially be a stakeholder.

The scope should be used as your starting point to identify the key stakeholders of the system(s), who may be Subject Matter Experts, Users, etc.

Also needed is the perspective and expectations of any stakeholders customers. The “ultimate” user is likely not a stakeholder. The expected classification levels and proprietary information needs clarification and concurrence.

Don't limit end capability to the initial set of requirements you come up with - emergent properties and attributes can enhance the end product.

Important to schedule in the right amount of time/resource for requirements elicitation as stakeholder availability may vary!

The requirements must include any customer unique operational interfaces. There likely will be essential vs nice to have unique capabilities that can not be unconstrained but prioritized into the contract. Follow-on prioritization will help a better “buy in” across the customer set.

It's important to recognize the need to specify tolerances for all analog parameters that cannot be implemented or verified to have any EXACT value. If there are requirements involving such parameters, and compliance with those requirements is to be verified by test, then to prove compliance, the readings on the test equipment must be INSIDE tolerance by at least as much as the errors in the test equipment.

The cost of maintenance and operations must be considered in the design. Replacing an engine in flight as the designers optimized OPSCON, might not be suitable for various depot level operations. Sustainability in a development lab will not be the same as space flight radiation hardening.

Its best practice to document the way in which requirements are specified such as the language and syntax used in a requirements management plan or similar.

Depending on how complex the project and system is, you may want to consider using a requirements management tool to enable better management of requirements and traceability.

This is super important. Key points to note. 1. Managing requirements is an iterative process as the system needs the ability to continuously change with time. Define a clear cadence for requirements review. It can be quarterly, annually, bi-annually etc. based on the business needs. 2. Invest in proper issue tracking tools and processes to ensure field performance data is accurately gathered and that the lessons are incorporated in requirement analysis. 3. Anticipate and track all external factors like regulatory changes and technological improvements, which can influence the requirements going forward.

Too bad so few companies actually do this. I was asked to write test plan and test procedures for a very important flight test program and I asked where the requirements were. I was told there aren’t any because they could not afford to develop the requirements. They said they were going to give me high level use cases and I told them that they would then get a high level test plan and test procedure. They said that was acceptable. No time for lab testing, they decided to test during the actual flight test. Months after the documents were delivered PE was frantic because there was no detail. I asked him where was I supposed to get the detail. No answer. Of course the program is a disaster but they keep trying. Good luck with that mess.

Conducting a functional requirements analysis is important because it serves as the foundation for successful project execution. It ensures that all stakeholders have a clear and shared understanding of what the system or product is supposed to achieve. This clarity minimizes misunderstandings, reduces the risk of costly changes later in the project, and guides the development and testing processes. It also provides a basis for validation and verification efforts, helping to ensure that the final product meets stakeholder expectations and performs its intended functions effectively and efficiently. Ultimately, a well-executed requirements analysis contributes to project success, cost-efficiency, and customer satisfaction.